This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------ =_NextPart_000_01BD996D.40BEBC2E
Content-Type: text/plain
Please review the attached summary of Larry's proposal for a new IPP
scheme. I added some clarifications and a particular scenario for scheme
interpretation. This summary is a brief version that was culled from my
notes, and Larry's subsequent comments to me.
The brevity of this summary is maintained due to the possible inclusion
and modification should the WG (or IESG) decide some additional text is
required for IPP-specific "secure" schemes. For this reason, please
treat this proposal as a first draft.
Randy
<<maspro.txt>>
------ =_NextPart_000_01BD996D.40BEBC2E
Content-Type: text/plain;
name="maspro.txt"
Content-Disposition: attachment;
filename="maspro.txt"
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)
------ =_NextPart_000_01BD996D.40BEBC2E--