----------
> From: Keith Moore <moore at cs.utk.edu>
> To: Tom Hastings <hastings at cp10.es.xerox.com>
> Cc: Keith Moore <moore at cs.utk.edu>; ipp at pwg.org; moore at cs.utk.edu> Subject: IPP> Re: On clarifying the proposal for a new IPP scheme
> Date: Monday, July 06, 1998 4:26 PM
>> > 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.)
The corporate HTTP proxy was the number one reason identified. Alot of
corporations using application gateways for firewalls (like proxies) will
not have a special app gateway for IPP. Therefore, the case outlined above
is probably the most widely deployed proxy scenario. Again, this is the
case where HTTP traffic (and like it or not, IPP is HTTP traffic) is always
gatewayed through an HTTP proxy and no generic firewall product (like
Checkpoint, etc.) is in use. If a site uses HTTP proxies and SOCKS style
approaches for isolation, this technique is basically "the" way to do this.
>> > -------------------------------------------------------
> > 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.)
I agree. This scenario was put in for *informational* reasons, and
specifically to address a particular WG member's concerns. Whether this
scenario would be included in our final spec is "up for grabs", it probably
shouldn't be normative text if it is included.
>>> > 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.
I believe that is implied by the text.
>> 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.
>
Sounds ok I guess.
>> 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.
It depends on what kind of IPP object you're talking about.. We have
printer-object and job-objects. We can probably get away with using MUST in
the case of printer-objects, but for job-objects, it's probably not the
case but we'll see. I agree that within IPP protocol elements we SHOULD
attempt to use "ipp" URLs when it makes sense.
Randy
>> Keith