Subject: Re: IPP> Proposal for new IPP scheme

From: Robert Herriot <[email-masked]>
Date: Tue, 16 Jun 1998 16:39:59 -0700

This looked like a reasonable proposal until I got to the very last line:

        3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)

The whole proposal is one of keeping ipp as a convenience notation and 
making ipp not appear on the wire. So why should a server ever have to 
accept #3 above?

Bob Herriot

At 02:25 PM 6/16/98 , Turner, Randy wrote:
>       
>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>> 
>
>
>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)
>