If, on the other hand, he is actually suggesting a new kind
of aliasing mechanism (as you've pointed out below), then I,
too, have some doubts as to whether firewalls, proxies and
web servers would handle that; or, more importantly, whether
the vendors would *want* to address that capability in their
products.
Also, I don't think Keith was suggesting that IPP not use HTTP,
although I may have misinterpreted his statements.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Carl-Uno Manros wrote:
>
> All,
>
> 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