--=====================_18153122==_.ALT
Content-Type: text/plain; charset="us-ascii"
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"
<html>
<font size=3>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:
><x-tab> </x-tab>
>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
<a href="http://myhost.com:374/myprinter/myqueue" eudora="autourl"><font size=3>http://myhost.com:374/myprinter/myqueue</a><font size=3>
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:
<font size=3>>
>- The IPP client obtains the IPP-schemed URL and converts it to the
> following form:
> "<a href="http://myhost.com:374/myprinter/myqueue" eudora="autourl"><font size=3>http://myhost.com:374/myprinter/myqueue</a><font size=3>"
>>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., <a href="http://myhost.com:374/myprinter/myqueue" eudora="autourl"><font size=3>http://myhost.com:374/myprinter/myqueue</a><font size=3>)
> 3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue)
> </font>
</html>
--=====================_18153122==_.ALT--