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

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 04 Jun 1998 07:35:45 -0700

At 10:58 PM 6/3/98 PDT, Larry Masinter wrote:
>> 
>> For example, take a URL that does not explicitly specify a port: 
>> 
>>        http://my.domain.com/printer1
>> 
>> - If the client is in the act of printing (browser that is printing 
>> or a print only client) the the port to use is the new IPP default port.
>> 
>> - Any other client will use the HTTP default port
>
>This suggestion is completely unworkable. The default port for
>the "http" scheme is 80. It isn't "80 when you use it one way
>and something else when you use it another".
>
>I think you can define a new scheme "ipp" and just define it quite
>simply:
>       ipp://host/path  ===  http://host:ippport/path (used for ipp) 
>
>E.g., if the IPP port is "187" then
>        ipp://printer.xerox.com/doit
>
>would be interpreted _exactly_ as
>
>        http://printer.xerox.com:187/doit
>
>This equivalence can be done in the client, and need not be handled
>by the proxies at all. Since an ipp client has to know about the rest
>of the ipp protocol anyway, requiring the ipp client to do the translation
>is not a burden.
>
>

Larry,

This might be a brilliant idea - if I could only understand what it is that 
you suggest. It seems to me that you are suggesting to introduce "ipp", as
a synonym for "http", which you map in both the server and the client?

If that is correct, does that not mean that you are running "http" over
the wire, and hence through the firewall? The whole discussion as raised
in Keith's feedback has to do with firewalls. Also, we are not discussing
how easy or not it is to change the specs, but what the consequences are 
for implementors.

My understanding is that Keith is trying to dictate that IPP CANNOT USE 
"http" - full stop. Considering that he has been the project advisor, I am 
very disappopinted to see that kind of proposal at this stage in the 
project.

Carl-Uno

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 4 Jun 1998 11:42:00 -0400 (EDT)

[I've taken this back to just the IPP list - it really has no effect
either way on http that I can see]

> The whole discussion as raised

  I'm not sure that I interpreted Keiths comment that way - I believe
that the concern is (and it has been raised by others before this) that
a firewall admin has to look too far into the request to determine that
it is IPP.  It is easy to come up with scenarios in which the admin
would want IPP to be able to penetrate where a POST would not (for
example, I install an IPP printer I trust _inside_ my firewall and then
set the firewall to allow PRINT requests to it from outside, perhaps
only from certain business partners).

I think that continuing to use http: and by default port 80 is fine, but 
using a PRINT method gives the admins what they need; they can now
allow http PRINT to penetrate (or not) based on the method and the
destination server.  The IPP spec would only need to specify that the
PRINT method is equivalent to POST for the purposes of all http usage
rules (cachability, etc - and in any event there are explicit headers
available in http [Vary, Connection, Cache-Control] to control these
things now anyway).  

This is trivial change for any server that wants to be used for IPP.
The current state of proxies and firewalls on the real net is so widely
variable that I think any scheme we can come up with will have problems
with some anyway, and those technologies are evolving so rapidly that
there is ample opportunity for IPP to create an incentive to support
this kind of filtering.

---

From: "Larry Masinter" <[email-masked]>
Date: 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