Subject: Re: IPP> Re: Implications of introducing new scheme and port for existing HTTP servers

From: [email-masked]
Date: Fri, 5 Jun 1998 12:31:37 -0400

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                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

Jay Martin <[email-masked]>
06/05/98 11:27 AM

To:   Carl-Uno Manros <[email-masked]>
cc:   [email-masked] (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:   [email-masked]          --
--  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

---

From: Robert Herriot <[email-masked]>
Date: Fri, 05 Jun 1998 12:05:36 -0700

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

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 6 Jun 1998 00:04:32 PDT

In HTTP/1.1, you don't normally send the URL to the server anyway,
you only send the path. So for the most part, the HTTP servers don't
need to know anything about the URL but the path component of it.
The 'transformation' between ipp://xyz.printer.com/printer1
and http://xyz.printer.com:380/printer1 happens in the client 
(since the client knows about the rest of IPP too, and a client that
doesn't know about ipp has nothing to say to the URL anyway), and
possibly in the bowels of the IPP server which is generating real
URLs for things like jobs and other printers. But the HTTP infrastructure
of proxies, HTTP protocol stacks, etc. need not know anything about
the URLs at all, I don't think.

Larry
--
http://www.parc.xerox.com/masinter