IPP> Re: On clarifying the proposal for a new IPP scheme

IPP> Re: On clarifying the proposal for a new IPP scheme

Keith Moore moore at cs.utk.edu
Mon Jul 6 19:26:33 EDT 1998


>                        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



More information about the Ipp mailing list