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