Keith,
Thanks for your constructive proposal on how to improve the proposal.
This shows more in detail what you believe is the right solution.
I expect that we will discuss this in the upcoming IPP meeting, and be able
to give you feedback later in the week on how the experts in that meeting
view your proposed changes.
Carl-Uno
At 04:26 PM 7/6/98 PDT, Keith Moore wrote:
>> Proposal for an IPP scheme
>>>> 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.
>>change this to:
>>The IPP scheme implies use of the Internet Printing Protocol, which
>is layered on top of the Hypertext Transfer Protocol (HTTP). By
>default, IPP clients connect to IPP servers using TCP port 631.
>>> 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
>>change the above line to:
>>Host: myhost.com
>>"631" should probably not appear, since it's the default port.
>>However servers should accept the port # if it does appear.
>>> 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.
>>>This section needs justification - why should an IPP client talk to an
>HTTP proxy rather than talking directly to the IPP server, unless
>the reason is to circumvent the local site's filtering of outbound
>traffic on port 631? (There may well be a good reason, but offhand I
>can't think of one.)
>>> -------------------------------------------------------
>> 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.
>>(FWIW, This is an implementation issue. As long as the protocol on the wire
>is the same, IETF doesn't care what you have to do to talk to an 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)
>>Servers MUST treat all of above forms as equivalent.
>>Servers MAY provide different services at different domains using
>either full URLs (those that include the domain), or the Host header
>(if one is supplied by the client) to distinguish one domain from another.
>Servers that look at the Host: request header field MUST treat
>"Host: foo.com" and "Host: foo.com:631" as equivalent.
>>>Finally:
>>The use of http: URLs within IPP is only to allow reuse of HTTP libraries,
>(or HTTP proxies). Within IPP protocol elements, ipp: URLs MUST always
>be used for URLs that refer to IPP objects.
>>Keith
>>Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com