Larry,
I get the same understanding as Don from your email. I understand you to say
that a client translates ipp://foo/killtree to http://foo:380/killtree and
sends the operation to the url http://foo:380/killtree. The wire, the
proxies and the destination printer/print-server (at http level) see only
http://foo:380/killtree. The printer-uri IPP attribute is
ipp://foo/killtree, but the request line is "POST /killtree HTTP/1.1"
Bob Herriot
At 09:31 AM 6/5/98 , don@lexmark.com wrote:
>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@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@interlock.lexmark.com>
>06/05/98 11:27 AM
>
>
>To: Carl-Uno Manros <carl%manros.com@interlock.lexmark.com>
>cc: ipp%pwg.org@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@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
>
--=====================_2581091==_.ALT
Content-Type: text/html; charset="us-ascii"
Larry,
--=====================_2581091==_.ALT--
I get the same understanding as Don from your email. I understand you to
say
that a client translates ipp://foo/killtree to
http://foo:380/killtree
and
sends the operation to the url http://foo:380/killtree. The wire, the
proxies and the destination printer/print-server (at http level) see only
http://foo:380/killtree. The printer-uri IPP attribute is
ipp://foo/killtree, but the request line is "POST /killtree HTTP/1.1"
Bob Herriot
At 09:31 AM 6/5/98 , don@lexmark.com wrote:
>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@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@interlock.lexmark.com>
>06/05/98 11:27 AM
>
>
>To: Carl-Uno Manros <carl%manros.com@interlock.lexmark.com>
>cc: ipp%pwg.org@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@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
>