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)
>
--=====================_18153122==_.ALT
Content-Type: text/html; charset="us-ascii"
This looked like a reasonable proposal until I got to the
very last line:
--=====================_18153122==_.ALT--
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)
>