Keith,
Please see this attachment which describes the proposal worked out by Randy
Turner and Larry Masinter. Case 3 in that proposal caused a number of people
to object, pointing out that the previous assumption that ipp: would not be
used over the wire was not true any more. There was also discussion about
which format the IPP Printer generated Job URIs should have. They are hardly
ever seen by and end user and could as well be in http: format. The result
would have been that the client would have had to cover for URIs coming
back in either scheme and always have to be able to convert between them.
The more we discussed this, the more causes we found that the ipp: scheme
was not such a bright idea after all. As for the suggestion to include a
security paramter in the ipp: scheme, this was adviced against also by Randy
and Larry, as it would make the ipp: non-mappable in the http: to ipp:
direction. We believe that the current solution to identify what security is
supported by a printer works well without the need for a parameter in the
scheme.
This is my short answer and explanation right now. I assume that other
members of the WG can give you further arguments, but many have already
started their July 4th celebrations.
Carl-Uno
At 12:46 AM 7/2/98 -0400, you wrote:
>On a careful re-reading the list of resolutions for the IPP
>documents, I was surprised to see that the WG had decided not
>to adopt an "ipp:" URL prefix. (I was out of town last
>week and unable to follow the list as closely as I would
>have liked.)
>>In my earlier poll of IESG there was strong agreement that both
>a separate port and a new URL prefix were needed, though the
>questions were not asked separately We're having a phone
>conference on July 2 (today or tomorrow depending on your
>current time zone), so I'll ask them again just to be sure.
>>Other than the issue with interoperability with http proxies
>(which are easily addressed), I'd like to know what the
>technical problems were with using an "ipp:" prefix. I've
>reviewed most of the list discussion since the teleconference
>that I participated in, and didn't see any good explanation
>of why this would cause problems.
>>Keith
>>-------------- next part --------------
This is a proposal for the registration of a new URL scheme "ipp".
The syntax for the new IPP scheme would be identical to the existing
"http" scheme except for the scheme name itself:
ipp://host[:port]/<IPP-specific-abs-path>
Associated with this new IPP scheme would be an IANA-assigned TCP port
number, which would be the default port number used by clients to
contact IPP servers that are represented by IPP URLs.
For the examples in this proposal the port number 374 is used as the
port number that might be allocated by IANA. NOTE: this port number
selection is for illustrative purposes of this text only.
The IPP scheme implies all of the same protocol semantics as that of
the HTTP scheme, except that, by default, the port number used by clients
to connect to the server is port 374. The semantics for clients
configured for proxy access is different as described below.
When an IPP client obtains an IPP URL, the interpretation of this URL by
the client can take one of three forms, depending on the configuration
and implementation of the client:
------------------------------------------------------
IPP Client Configured with no proxy server -
------------------------------------------------------
When an IPP client (no proxy configured) obtains an IPP-schemed URL such
as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to
port 374 on myhost.com, with the following example headers:
POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:374
Content-type: application/ipp
Transfer-Encoding: chunked
...
------------------------------------------------------
IPP Client Configured for Proxy Service -
------------------------------------------------------
When an IPP client that uses a proxy named "myproxy.com" obtains the URL
"ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to
myproxy.com with the following example headers:
POST http://myhost.com:374/myprinter/myqueue HTTP/1.1
Host: myproxy.com:374
Content-type: application/ipp
Transfer-Encoding: chunked
...
It is likely that existing proxies will not understand IPP URLs,
so the RequestURI should use the HTTP form of the URL.
-------------------------------------------------------
IPP Clients with HTTP-only constraints
-------------------------------------------------------
If a particular IPP client implementation uses a pre-packaged HTTP library
or HTTP class that only supports HTTP-schemed URLs, then the following
operation would be required:
- The IPP client obtains the IPP-schemed URL and converts it to the
following form:
"http://myhost.com:374/myprinter/myqueue"
The client then submits this URL to the pre-packaged HTTP library API.
-------------------------------------------------------
Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers using
a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1 servers
should accept "full" URLs as well, so IPP servers should also be able to
accept requestURIs as specified in #2 and #3 as well.
1. A "abs_path" URL (e.g., /myprinter/myqueue)
2. A full HTTP URL (e.g., http://myhost.com:374/myprinter/myqueue)
3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue)