I would like your reaction to Larry's proposal. It sounds almost too easy to
be true. Can existing http servers and other components, such as firewalls
and proxy servers, handle the kind of aliazing that Larry talks about
without substantial modification? Is this simpler than to introduce a PRINT
method?
Is this really what Keith had in mind when he suggested a new scheme and a
new port?
I will tune out for the next few days to go to Canada and watch Sumo
wrestling - keep up your own wrestling on the DL while I am away :-)
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