IPP Mail Archive: RE: IPP> Re: Implications of introducing new scheme and port

RE: IPP> Re: Implications of introducing new scheme and port

Larry Masinter (masinter@parc.xerox.com)
Thu, 04 Jun 1998 20:51:29 -0700

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