IPP> Re: Implications of introducing new scheme and port

IPP> Re: Implications of introducing new scheme and port

Larry Masinter masinter at parc.xerox.com
Thu Jun 4 23:51:29 EDT 1998


All, I just found Larry's answer to my earlier question on my home mnachine. 
Unfortunately Larry had not copied the IPP DL.  
Herer it is for the rest of you to enjoy.


Carl-Uno



---


> 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?




I'm suggesting introducing "ipp" as a synonym for "http with a different
port, restricted only to accept POST of application/ipp messages".


> 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.


You are running http over the wire. That was the whole point. There's
no value in inventing an HTTP-like protocol; since HTTP is a terrible
protocol, the only value you get is from _complete_ compatibility.


The consequence of using "ipp" as a synonym for "http with a different port"
is that the proxy forwarding remains the same (forwarding is sending ordinary
HTTP methods), but proxy filtering is simply controlled (filter on host
& port, and, if desired, only allow certain message types).


> My understanding is that Keith is trying to dictate that IPP CANNOT USE 
> "http" - full stop. 


No, I don't read that in any of his comments at all. He was suggesting
not calling it 'http' in the URL scheme, and not using the same port
that is reserved for HTTP.


> Considering that he has been the project advisor, I am 
> very disappopinted to see that kind of proposal at this stage in the 
> project.


I think you should look harder his comments. To suggest that IPP _not_
use HTTP at this point would send you back to square one.


I don't think the goal was to scuttle IPP at this point, but rather to make
some simple changes that would make it clear to clients that a
a printer _isn't_ a regular web server, even if IPP uses HTTP. Changing
the URL scheme and using a different default port doesn't change your
protocol, but rather the 'user' interface to it. I think this is a positive
move, can be accomodated easily, and you should do it and get on with it.


Don't make this harder than it has to be.
 
Larry




More information about the Ipp mailing list