IPP Mail Archive: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers

IPP Mail Archive: RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers

RE: IPP> Re: Implications of introducing new scheme and portfor existing HTTP servers

Larry Masinter (masinter@parc.xerox.com)
Thu, 4 Jun 1998 09:00:54 PDT

Actually, I think using a separate PRINT method really is harmful,
in that it will interfere with proxies that know how to forward
POST but don't know how to forward PRINT. While many 'firewalls'
put filtering and forwarding into the same function, really, we should
separate them as functions and analyze the cost/benefits independently.

There are a number of proxies that forward POST and GET and a few other
methods into internal protocols and then forward those internal protocols
out the other side of their cloud back into POST and GET. One of the
advantages of layering IPP on top of HTTP is the ability to leverage
those proxies. Using another method would detract from that, without
much advantage, since the filtering function can use the host and port.
It's a good idea to have a different port for IPP since port filtering
can be accomplished by the simplest of filtering devices -- you can
even filter at the router level.

It's true that there are some products that combine filtering and forwarding
in one application, and can filter on content as easily as filtering
on port, but it weakens the protocol to REQUIRE that filtering be accomplished
by looking at the data or the method.

It makes IPP stronger, thus, to dictate a different default port, and
if you're going to change the default port, it's reasonable to change
the scheme to "ipp", if only to make
ipp://localhost

a simple URL to type.

Larry

--
http://www.parc.xerox.com/masinter