My understanding is that internal to the client and the server, a magic
transformation happens that turns ipp://xyz.printer.com/printer1 into
http://xyz.printer.com:380/printer1. The "wire" would never see anything
but http URLs so the infrastruture would be unaffected. When a client or a
server pulled an IPP URL from inside application/ipp, it would also
translate it into the HTTP format.
In summary:
WIRE -- only sees HTTP stuff
Humans - see only IPP stuff (i.e. my business card says to print to me
at ipp://www.lexmark.com/donsprinter)
Clients and Servers -- provide the "magic" to convert back and forth.
Am I right, Larry? Interesting idea!!
**********************************************
* Don Wright don at lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
Jay Martin <jkm%underscore.com at interlock.lexmark.com>
06/05/98 11:27 AM
To: Carl-Uno Manros <carl%manros.com at interlock.lexmark.com>
cc: ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright)
bcc: Don Wright
Subject: Re: IPP> Re: Implications of introducing new scheme and port
for existing HTTP servers
I interpreted Larry Masinter's proposal as being one in which
clients and servers would talk in terms of ipp://host/printer,
but in practice map this (internally) to http://host:nnn/printer
when conducting the actual wire protocol.
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 at 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