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

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 1 Jun 1998 10:20:01 PDT

Hi,

As most of you know already, the Internet Printing Protocol (IPP) WG has
suggested using HTTP as "transport", with the payload in the form of a MIME
object passed with the POST method.

As part of the onging IESG review process, the Application Area Director
Keith Moore has suggested to distinguish IPP traffic from "normal" HTTP
traffic by: 

1) the introduction of a new scheme called "ipp"
2) the introduction a new default port number for IPP servers.

Before the IPP WG responds to those suggestions, the IPP WG would like to
get some advice from the HTTP WG on the implications of such a change.
In particular, we want some feedback on how easy or difficult it would be
to configure existing web servers to accomodate the suggested changes.

Please note that many printer vendors are not in the business of developing
web servers or HTTP servers and are dependent on getting those compoments
from other vendors.

Please respond back to the IPP DL at:

	[email-masked]

Thanks,

Carl-Uno Manros
Chair of the IETF IPP WG

---

From: [email-masked] (Ted Hardie)
Date: Mon, 1 Jun 1998 10:31:03 -0700

Carl-Uno,
	By "scheme" in the text below, do you mean a
new HTTP method, parallel to GET and POST, or something
else?
		regards,
			Ted Hardie
			NASA NIC

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 1 Jun 1998 10:36:14 PDT

By scheme in this context is meant "ipp" vs. "htpp" or "ftp".

Carl-Uno

>> to configure existing web servers to accomodate the suggested changes.
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: [email-masked]
Date: Mon, 1 Jun 1998 11:53:53 -0700

Regarding item #2,
     
     Use of alternative HTTP ports, other than port 80, effects the ability 
     to move through proxies and firewalls. Using alternative port #'s will 
     require reconfiguration of security infrastructure in order to allow 
     for HTTP connections. 
     
     HP has gone through similar work in the definition and standardization 
     of HTTP port 280 for Web Based Management Purposes ( see IANA port 
     list ). Currently port 280 is IANA approved for usage of HTTP for 
     network management. This works fine for Intranet usage, but issues as 
     described above result when operating in a secure environments.
     
     The other issue is that of configuring HTTP servers and proxies to 
     listen on alternative port #s. While easy to do programatically, not 
     all commercial HTTP servers allow listening on multiple ports 
     concurrently.
     
     Considering these two issues, partitioning of the URI space for IPP on 
     HTTP port 80 or HTTP-S (HTTP/(SSL |TLS)) on port 443 makes better 
     sense.
     
     Peter

______________________________ Reply Separator _________________________________
Subject: IPP> Implications of introducing new scheme and port for e
Author:  Non-HP-manros ([email-masked]) at HP-Roseville,mimegw4
Date:    6/1/98 10:20 AM

Hi,

     

     
     
        [email-masked]
     
Thanks,
     
Carl-Uno Manros
Chair of the IETF IPP WG

---

From: "David W. Morris" <[email-masked]>
Date: Mon, 1 Jun 1998 19:34:06 -0700 (PDT)

I would strongly urge you to NOT introduce a new url scheme. I would
assert that any existing proxy which doesn't reject an unknown scheme
badly broken. At the very minimum, proxies would have to be configured
to accept this new scheme and interpret it as HTTP. A requirement which
will be fraught with failure in the implementation. I'm not aware of any
proxies which would be this simple to adapt so this is speculation of the
lower bound of difficulty generated by using a new scheme.

(I'm also not wild about new HTTP methods as I know of existing proxies
which will reject unknown methods. Don't know of any which will accept
unknown methods. I'm also unaware of any firewall software which examines
the HTTP request method as part of its algorithm but then I'm not a 
firewall expert.)

A new default port may be OK but I believe unnecessary.  In any case, an
installation should be allowed to overload port 80 etc. if desired by
over-riding the default if it isn't 80.

But then I don't buy the basic premis that its necessary to distinguish 
between IPP (or any other HTTP-based content protocol) and HTTP.

Dave Morris

---

From: "Rob Polansky" <[email-masked]>
Date: Tue, 2 Jun 1998 09:05:32 -0400

I know of at least one :-) firewall that not only rejects unknown methods
but also examines the HTTP request method as part of its "algorithm". From a
protocol and security perspective, it appears to be the right thing to do.
If you don't understand the method, how can you properly proxy it? Take the
CONNECT method as an example.

In summary, any proxy that is more than a simple packet passer (supports
CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of
failing to pass IPP if it uses a new scheme and/or a new method. Not that
that's a bad thing... :-)

-Rob Polansky

> -----Original Message-----
> From: David W. Morris [mailto:[email-masked]]
> Sent: Monday, June 01, 1998 10:34 PM
> To: Carl-Uno Manros
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Implications of introducing new scheme and port for
> existing HTTP servers
>