I think the counter-argument is that the company that sets up a firewall
that doesn't pass traffic on port 631 is basically doing that as a matter
of policy. One would hope that firewalls are easily configured to allow
such traffic if the site administrator chooses. At any rate, IPP shouldn't
circumvent that policy.
There are also architectural concerns about what happens if we had several
different services being tunnelled over HTTP for the purpose of getting
around firewalls - firewalls get more complex and harder to configure,
networks get less secure as a result, and security folks start clamping
down even harder on what traffic they will allow. This would make it even
more difficult to deploy new applications than at present.
As I understand SOCKS, it works fine with port 631 - the client asks
to open up a connection to the IPP server at port 631, and the SOCKS
guy on the firewall says yes or no according to site policy.
For what it's worth, these weren't (originally) my concerns - they were
brought up by other IESG members. I'm mentioning them so that the IPP
group will understand that IESG is sensitive to these issues and needs
good reasons for allowing IPP specify how to get through HTTP proxies.
> > > 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.
Being able to accept all three forms doesn't mean that they are treated
as equivalent. That was my point.
> > 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.
The reason I included this is that it seems likely that some clients will
generate "Host: foo.com" and others will generate "Host: foo.com:631".
It would be bad if some servers recognized only one and not the other.
>
> >
> > 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.
I'd like to understand why job-objects cannot use ipp: also.
Keith