IPP> possible compromise?

IPP> possible compromise?

Robert Herriot robert.herriot at Eng.Sun.COM
Tue Jul 14 22:13:30 EDT 1998


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 http://myhost.com:631/myprinter/myqueue 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 http://myhost.com:631/myprinter/myqueue 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/19980714/de7df949/attachment.html


More information about the Ipp mailing list