Subject: IPP> Minutes of 6/10 IPP conference call

From: Roger K Debry <[email-masked]>
Date: Wed, 10 Jun 1998 17:08:31 -0400

When I agreed to take minutes, I did not agree to spell peoples names
corrrectly, remember everything that transpired during the discussion, or  get
it 1100% correct when transposing to paper. Please accept my apologies in
advance for such errors.  With those caveats, here are the minutes of the 6/10
call. I won't feel bad if you have to correct me. Thanks ...

Participating in the call ( mostly in the order joining the call):

Shevan Albright
Daniel Manchella
Keith Moore (area director)
Patrick ?? (area director)
Kris Schaff
Tom Hastings
Jim Walker
Ron Bergman
Harry Lewis
Larry Masinter
Don Wright
Xavier Riley
Ira MacDonald
Carl Kugler
Peter ???
Steve Gebert
Randy Turner
Paul Moore
Scott Issacson

The call began at approximately 11:00am (Mountain Daylight Time) with Carl-Uno
reviewing the agenda. It was agreed that the two major issues to be discussed
were the issue of how to differentiate IPP for filtering purposes, and what to
do about TLS. Carl-Uno asked Keith Moore to being the discussion by giving his
thoughts on the first issue.

In response, Keith Moore said that the goal was to be able to differentiate IPP
from normal HTTP traffic going through firewalls. By tradition new services run
on different port numbers.  Keith's poll of the IESG found general agreement
that IPP should run on a new port number. Larry Masinter reviewed his proposal
for providing a new scheme name for IPP at the client. In this proposal, IPP as
a scheme never appears on the wire.

Randy Turner argued that requiring a new port number for IPP would be a
hardship on some implementations, specifically where a server is not capabale
of listening to multiple ports, ports other than 80.  Paul Moore agreed with
the idea of a default  IPP Port number (as long as could still use port 80),
but thought that using IPP as a shorthand notation was nothing more than an end
user convenience, and really had nothing to do with the protocol.  Keith Moore
expressed the opinion that there was benefit to using IPP.

Carl-Uno then asked for comments on the proposal to define a new HTTP method,
PRINT. Larry Masinter reviewed his recent communication on differences between
filtering proxies and forwarding proxies. His claim is that forwarding proxies
would all break with definition of a new method. Paul Moore disagreed,
indicating that Microsoft's polling of proxy vendors indicated that most
proxies would handle a new method without any problem. Larry said he does not
believe this is the case.  There was some debate about what the out-of box
condition of IPP should be, and what impact our direction would have on this.
Keith Moore too a very strong position that it was up to the System
Adminsitrator to configure things so they worked, our responsibility was to be
sure the System Administrator was not surprised.

The resulting agreement from this debate was that we would focus on the details
of using a new port number and using IPP as a naming scheme, per Larry
Masinter's proposal.  We would not pursue the definition of a new method. Randy
Turner agreed to write up a draft of how this would work. Carl-Uno agreed to
take a work item to contact IANA about an IPP port number.

We then turned to the TLS discussion. Keith Moore indicated that TLS is
currenly hung up wating for documents from the PCIKS group, which are currently
in last call. Keith expects the TLS issue to be resolved soon and to have TLS
progress down the standards track.  Keith said that there is weak agreement in
the IETF on doing security negotiation in-band. The idea of having a reserved
port for TLS is still under discussion. Keith proposed that IPP use a parameter
in the URL to indicate TLS use.  After quite a bit of discussion, Keith agreed
that he would support the use of SHOULD for IPP client support of TLS. However,
he warned that others on the IESG may not approve with that wording. He
suggested that we articulate client instances where TLS may not be appropriate,
e.g. on a Palm Pilot.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: Larry Masinter <[email-masked]>
Date: Wed, 10 Jun 1998 15:00:50 PDT

I checked out three different proxies installed in Xerox, two of 
them different implementations of squid and one implementation of
Netscape-Proxy. 

In each case, I attempted to make a connection to a host
which supported the 'PRINT' method, namely:

http://sandbox.parc.xerox.com/cgi-bin/null

(this web server supports the PRINT method in a particularly
stupid way, but that's besides the point).

With the Netscape server, I got 405 "Method not allowed", but
with the squid servers, I got "400 Cache Detected Error".

Of course, 'POST' works fine for outbound HTTP traffic through
both of these services.

================================================================
PRINT http://sandbox.parc.xerox.com/cgi-bin/null HTTP/1.1
Host: sandbox.parc.xerox.com
Connection: close

HTTP/1.0 405 Method not allowed
Mime-version: 1.0
Proxy-agent: Netscape-Proxy/2.53
Content-type: text/html

<HTML>
<HEAD><TITLE>Method not supported</TITLE></HEAD>
<BODY>
<H1>Method PRINT unknown or not supported</H1>

<P>
<ADDRESS>Proxy server at mc0300ux01.mc.xerox.com on port 8000</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.

Process telnet-www.mc.xerox.com 8000 exited abnormally with code 1
================================================================

PRINT http://sandbox.xerox.com/cgi-bin/null HTTP/1.1
HTTP/1.0 400 Cache Detected Error
Content-type: text/html

<HTML><HEAD><TITLE>ERROR: Invalid HTTP Request</TITLE></HEAD>
<BODY><H1>ERROR</H1>
<H2>Invalid HTTP Request</H2>
<HR>
<PRE>
PRINT http://sandbox.xerox.com/cgi-bin/null HTTP/1.1

</PRE>
<P>

<HR>
<ADDRESS>
Generated by squid/[email-masked]
</ADDRESS></BODY></HTML>

Connection closed by foreign host.

Process telnet-wwwproxy0 8000 exited abnormally with code 1
================================================================