attachment

<html> After reading the email between Keith Moore and various members of the IPP working group, I see much agreement, and some remaining points of disagreement based on Keith's July 12th email "possible compromise?" (enclosed below). I will suggest a slightly different compromise. Keith and the IPP working group are in agreement:     1) Clients send only 'http' schemes in the HTTP Request-Line     2) Servers support the reception only of 'http' schemes in the HTTP Request-Line Keith and the IPP working group are in disagreement about:    1)  the scheme in the value of  IPP attributes, such as "printer-uri".         Keith wants 'ipp'. The IPP working group wants 'http'.    2)  the scheme in external notation for printer URL's. Keith wants 'ipp'.         The IPP working group wants 'http'. The IPP working group wants an 'http' scheme for issue #1 because they believe it is the cleanest design and avoids the mapping issue for clients that never expose a URL to a user. We don't understand the virtue of having an 'ipp' scheme in a block of data that a client must process, but that neither a user nor networking software ever see. The 'http' choice (with its lack of mapping) also allows a print server to use an 'https' scheme in an IPP attribute without any mapping issues.   Although 'https' is not a part of  IPP, most vendors will probably support it for pragmatic reasons. Keith's solution creates a mapping problem for clients while giving no apparent benefit to the client.  If there is a benefit at the client  level, we have been unable to understand what it is. If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal makes the wrong partitioning of 'ipp' and 'http'.  The partitioning should occur between client and user interface and not between the sending and receiving portions of the client. I might support a requirement that users refer to a printer with an 'ipp' scheme (issue #2), even though such a requirement seems to be beyond a protocol standard. But before giving such support, I would like to understand why the IETF wants a scheme to specify the type of service.  I would also like to see an IETF document that describes the intent and goals of this differentiation of schemes, as well as the infrastructure needed to support it.  I would like to know how a protocol designer decides if a new service is different enough to warrant a new scheme. I would like to know if someone has thought about how to avoid the "new area code" problem as each new scheme is introduced. Without a such information, I am left wondering if the requirement of a  new scheme for each new service will turn out to be a good idea. Finally, I wonder how long it would have taken faxes to be deployed if someone had required a special fax number instead of a standard phone number.  Bob Herriot At 04:47 PM 7/12/98 , Keith Moore wrote: >I was thinking about the problem where using ipp: URLs in >the HTTP POST operation potentially makes IPP incompatible >with existing servers, and came up with the following possible >compromise solution.  I'm willing to defend this to IESG if >the IPP group buys into it. > >1. use the http: form of the URL in HTTP protocol elements > >if you're talking to a proxy, do > >POST <a href="http://myhost.com:631/myprinter/myqueue" eudora="autourl">http://myhost.com:631/myprinter/myqueue</a> HTTP/1.1 > >if you're talking to an origin server, you should really do > >POST /myprinter/myqueue HTTP/1.1 >Host: myhost.com:631 > >but origin servers are *also* expected to accept > >POST <a href="http://myhost.com:631/myprinter/myqueue" eudora="autourl">http://myhost.com:631/myprinter/myqueue</a> HTTP/1.1 > >just as in vanilla HTTP 1.1. > >This way, the HTTP layer never has to see ipp: at all. >This should preserve compatibility with HTTP servers >and HTTP client libraries. > >2. use the ipp: form of the URL in IPP protocol elements >that refer to printer objects > >3. define ipp: URLs as a standard external notation for >referring to printers - and the IPP protocol document describes >how to take an ipp: URL and generate the appropriate HTTP/1.1 >POST request.  Printer clients are expected to be able to >do this.  > >That way, the ipp: URL can be used when it's useful to >expose the fact that the named object is a printer. > >The IPP server is free to respond to a GET on the its >printer URL, and return HTML that describes the printer, >how to talk to it, etc.  And users are free to export >this URL as an http: URL if they want to do so and >their printers support it. > >But users and clients should be cautioned to not assume >that the "GET URL" is the same as the "print URL". > >Keith > </html>