Someone, please state what the problems that we found with this proposal and
send them to the mailing list. I'm afraid that we've had good agreement
amongst the IPP WG about not wanting to do the new scheme, but we haven't been
very good at writing them down for others to understand and critique
(and help us solve the problems we see). (Or did I miss a message?)
Until we state clearly what the problems are, we aren't going to get
our standard accepted by the IESG.
Here is what Keith wrote to us in his review of IPP on 5/29 where
he clearly stated that ipp was on the wire (in the example):
At 13:29 05/29/1998 PDT, Keith Moore wrote:
snip...
>The biggest change that I think is needed, is that IPP's use
>of HTTP doesn't allow a firewall to distinguish between IPP
>traffic and ordinary HTTP traffic. Also, IPP's insistence on
>using port 80 could conflict with ordinary use of that port, in
>those cases where the IPP server was not designed to "plug in" to
>the HTTP server. For these reasons, I suggest that a separate
>port be allocated for IPP, and an "ipp" URL defined which defaults
>to the IPP port rather than port 80. An alternative would be to
>have IPP use the PRINT method rather than POST, but to me the
>separate port seems cleaner and more likely to be compatible
>with firewalls. One could still use IPP on port 80, by using
>the port override notation: ipp://hostname:80/etc.
Thanks,
Tom
This is the same proposal that Randy and Larry produced on June 16, 1998
and send to the IPP mailing list. I have only changed the port number
from 374 to the one assigned to IPP as the IPP default port by IANA on June
22, namely, 631. - TNH
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.
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 631. 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 631 on myhost.com, with the following example headers:
POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
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:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:631
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:631/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:631/myprinter/myqueue)
3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue)