Subject: RE: IPP> Re: Implications of introducing new scheme and port

From: Harry Lewis <[email-masked]>
Date: Thu, 4 Jun 1998 12:01:56 -0400

Carl-Uno said:

My understanding is that Keith is trying to dictate that IPP CANNOT USE
"http" - full stop.

My understand is different, and Larry Masinter expresses my interpretation very
well (attached). Are Larry and I the only ones who read it this way? Keith,
please clarify.

Harry Lewis - IBM Printing Systems

[email-masked] on 06/04/98 08:53:15 AM
Please respond to [email-masked]
To: [email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: IPP> Re: Implications of introducing new scheme and port

At 10:58 PM 6/3/98 PDT, Larry Masinter wrote:
>>
>> For example, take a URL that does not explicitly specify a port:
>>
>>        http://my.domain.com/printer1
>>
>> - If the client is in the act of printing (browser that is printing
>> or a print only client) the the port to use is the new IPP default port.
>>
>> - Any other client will use the HTTP default port
>
>This suggestion is completely unworkable. The default port for
>the "http" scheme is 80. It isn't "80 when you use it one way
>and something else when you use it another".
>
>I think you can define a new scheme "ipp" and just define it quite
>simply:
>       ipp://host/path  ===  http://host:ippport/path (used for ipp)
>
>E.g., if the IPP port is "187" then
>        ipp://printer.xerox.com/doit
>
>would be interpreted _exactly_ as
>
>        http://printer.xerox.com:187/doit
>
>This equivalence can be done in the client, and need not be handled
>by the proxies at all. Since an ipp client has to know about the rest
>of the ipp protocol anyway, requiring the ipp client to do the translation
>is not a burden.
>
>

Larry,

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?

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.

My understanding is that Keith is trying to dictate that IPP CANNOT USE
"http" - full stop. Considering that he has been the project advisor, I am
very disappopinted to see that kind of proposal at this stage in the
project.

Carl-Uno

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Jun 1998 15:01:04 -0400

> My understanding is that Keith is trying to dictate that IPP CANNOT USE

No, that's not quite what I meant.

What I am "trying to dictate" is that IPP traffic must be easily
distinguishable from HTTP traffic, so that it can be filtered (or not)
according to a site's security policy.  My suggestion to use a
different default port was an attempt to acheive this, with the fewest
possible changes to the current IPP protocol.

IETF has traditionally used well-known port numbers to distinguish
between different services.  To follow this pattern, IPP should not
use port 80 as a default, because that port is reserved to HTTP.

And in my mind this pretty much implies that a new "ipp" URI prefix is
needed to refer to printers and print jobs so that the port number
doesn't have to be explicitly specified.  This doesn't necessarily
mean that "http" cannot also be used (and doing this might be useful
to tunnel through proxies that understand http: but not ipp:) but
sometimes it's a Bad Idea to have two ways to name the same thing.
(What happens if you make a request to an ipp: object?  Will you get
back references to ipp: objects? or might they use the http: scheme?)

Note that while some changes might be necessary for IPP protocol
elements (using ipp: URLs instead of http: URLs) I would not expect
any changes to the HTTP layer itself.  

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 9 Jun 1998 09:26:51 PDT

Keith,

Thanks for your clarification. Sorry that I have muddied the waters by
interpreting your comment differently.

Carl-Uno

>any changes to the HTTP layer itself.  
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 09 Jun 1998 15:28:26 -0400

I've been thinking about the interaction of an ipp: URL and 
the installed base of proxies that support http: but will not
understand ipp:

Whenever an IPP client is configured to use a proxy, it would probably
make sense to have the client send 
"POST http://foo.bar:XXX/zot HTTP/1.1" to the proxy when attempting
to talk to the ipp object "ipp://foo.bar/zot".

As far as I can tell from a very casual analysis, this is the only
place where it would be necessary to actually send the string "http:"
to refer to a ipp object.  Every other URI that refers to a ipp object
could use "ipp:" instead.

I don't see a problem with doing things this way, as long as it's
clearly documented.  Perhaps it would be wise to add a section called
something like "Tunneling of IPP requests over HTTP proxies" to the
protocol document that specified such details.

Keith