Here is the techical proposal to use a new IPP scheme that we discussed
on the telecon. It does include the IPP scheme being on the wire in HTTP
headers
and in IPP requests and responses within the IPP MIME type. But it also
allows
the HTTP scheme in HTTP headers and in both directions in IPP requests and
responses
within the IPP MIME type.
As stated in the proposal in order to work with existing proxies, the
client would have to change the scheme from ipp to http. We assumed that
that was ok, since the client would also introduce the default port number,
631,
into the URL, so that the outbound gateway system administrator could restrict
or allow traffic on port 631. See the example below. Same for clients
working
through existing HTTP-only libraries.
Do you or the IESG have any technical problems with this complete proposal?
It is a correct description of how a new IPP scheme would work with
clients, proxies, and servers?
There is no point in discussing problems with the new IPP scheme, if we don't
all agree as to what a new IPP scheme really is.
Thanks,
Tom
****************************************************************************
****
Proposal for an IPP scheme
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)
End of Proposal for a new IPP scheme
****************************************************************************
*******
At 21:46 7/1/98 PDT, Keith Moore 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
>
>