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