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