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

From: Josh Cohen <[email-masked]> (by way of Carl-Uno Manros <[email-masked]>)
Date: Mon, 1 Jun 1998 10:56:04 PDT

I think its fine to have a new default dest port 
associated with IPP, but a new URL scheme seems like more
trouble than may be apparent.

For one, even though IPP is a different service than HTTP,
an IPP client *is* speaking HTTP, IMHO.  HTTP is used as
a layer underneath IPP.  So, I think the URL scheme
should continue to be http://..

Using a new URL scheme will certainly break compatibility
with existing proxies.  Proxy server's encountering a new
scheme will fail unless they are modified to understand it.

As I've stated before, I think the best way to differentiate
the service and remain compatible with existing proxy servers
is to use a new method on the request line.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, June 01, 1998 10:31 AM
> To: Carl-Uno Manros; [email-masked]
> Cc: [email-masked]
> Subject: IPP> Re: Implications of introducing new scheme and port for
> existing HTTP servers
> 
> 
> 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
> 
> > 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.
>

---

From: "Xavier D. Riley" <[email-masked]>
Date: Mon, 1 Jun 1998 12:02:22 PDT

I agree with Randy.  My preference order would be the following:
 1) Leave as currently specified
 2) Use new http method(s) instead of POST
 3) Use new "ipp:" scheme instead of http (least desirable and major 
    deployment issues in my opinion)

--Xavier

At 11:02 AM 6/1/98 PDT, you wrote:
>
>
>
>If this gets down to a point where we HAVE to modify our specification,
>then I agree with Josh, it would be much better to differentiate based
>on HTTP method than on URL scheme, (IMHO). (But I think its ok as it
>stands now)
>Randy
>
>	From:	Josh Cohen [SMTP:[email-masked]]
><mailto:[SMTP:[email-masked]]> 
>	Sent:	Monday, June 01, 1998 10:54 AM
>	To:	[email-masked]'
>	Subject:	RE: IPP> Re: Implications of introducing new
>	scheme and port for  existing HTTP servers
>
>I think its fine to have a new default dest port associated with IPP,
>but a new URL scheme seems like more trouble than may be apparent.
>For one, even though IPP is a different service than HTTP, an IPP client
>*is* speaking HTTP, IMHO.  HTTP is used as a layer underneath IPP.  So,
>I think the URL scheme should continue to be http://. <http://.> .
>Using a new URL scheme will certainly break compatibility with existing
>proxies.  Proxy server's encountering a new scheme will fail unless they
>are modified to understand it.
>As I've stated before, I think the best way to differentiate the service
>and remain compatible with existing proxy servers is to use a new method
>on the request line.
>
>		> 
>
>

______________________________________________________________________
Xavier Riley                     
Xerox Corp.                      
Corp. Research & Tech.           Voice: 310-333-8329 / 8*823-8329   
701 S. Aviation Blvd ESAE-231    Fax: 310-333-6618 / 8*823-6618
El Segundo, California 90245     Email: [email-masked]
______________________________________________________________________

---

From: Paul Moore <[email-masked]>
Date: Mon, 1 Jun 1998 14:12:21 -0700

Doesnt changing scheme from 'HTTP' to 'IPP' mean that we should stop using
HTTP wire representation. 

If we are using HTTP we should say so in the URL - i.e. http:.............
What is the point of saying IPP:.... if we are actually sending HTTP. This
seems to be neither one thing or another.

> From:	Scott Isaacson [SMTP:[email-masked]]
> Sent:	Monday, June 01, 1998 1:50 PM
> To:	[email-masked]; [email-masked]; Josh Cohen;
> [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: IPP> Re: Implications of introducing new scheme and port
> for existing HTTP servers
> 
> I agree with Josh that the introduction of a new URL scheme (ala "ipp:")
> would be problematic.  The key here is that IPP has a new "default" port,
> not a new "must-only-use-the-new-port" port.  As he points out, IPP really
> is HTTP.  Form processing with HTTP POST does not require a new "form:"
> URL scheme.
> 
> As I understand it, an httpd server is always listening on one or more
> ports.  The URL for a resource behind that server advertises what the port
> is: either the default port (no port is included in the URL) or some other
> port (the port included in the URL).  Therefore, it is up to the client to
> attempt a connection on the correct port.  You may ask: "If there is a
> default for IPP and a default for HTTP, then how will the client know
> which to use?"   I claim that it will never be ambiguous.  The client will
> always be in the context of making a generic HTTP request or an IPP
> request and it will be very clear which default to use.
> 
> 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
> 
> Scott
> 
> ************************************************************
> Scott A. Isaacson
> Corporate Architect
> Novell Inc., M/S PRV-C-121 
> 122 E 1700 S, Provo, UT 84606
> voice: (801) 861-7366, (800) 453-1267 x17366
> fax: (801) 861-2517
> email: [email-masked]
> web: http://www.novell.com
> ************************************************************
> 
> 
> >>> Josh Cohen <[email-masked]> 06/01 11:51 AM >>>

---

From: Yaron Goland <[email-masked]>
Date: Wed, 3 Jun 1998 11:02:58 -0700

When you say "change the standard" are you referring to RFC 2068 or the IPP
standard?

			Thanks,
					Yaron

> From: Rob Polansky [mailto:[email-masked]]
> Sent: Wednesday, June 03, 1998 5:55 AM
> To: Paul Moore
> Cc: http-wg; [email-masked]
> Subject: RE: IPP> RE: Implications of introducing new scheme and port
> This kind of flamebait is not really helpful to our 
> discussion. Firewalls
> serve legitimate technical and business needs as our friends 
> from Microsoft
> know, and those firewalls with application proxies look at 
> protocols from a
> different point of view than your typical caching proxies. 
> The beauty of it
> is that protocol compliant implementations from either the 
> firewall or the
> cache point of view will interoperate. The difference is when 
> they encounter
> something unexpected. Firewalls by definition must "fail 
> closed" so as not
> to make their protected resources vulnerable to attacks; most 
> other software
> makes a best effort to pass data. I don't see anything wrong with that
> difference.
> 
> Once again, if IPP uses existing methods and schemes, it 
> should be passable
> through all proxies without trouble. Add a new method and/or 
> scheme i.e.
> CHANGE THE STANDARD, and you should expect that existing 
> implemenations will
> not understand it and some (not many) may not pass it.
> 
> -Rob Polansky
> 
> > From: Paul Moore [mailto:[email-masked]]
> > Sent: Tuesday, June 02, 1998 8:37 PM
> > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob 
> Polansky'; David
> > W. Morris
> > Cc: http-wg; [email-masked]
> > Subject: RE: IPP> RE: Implications of introducing new 
> scheme and port
> > The issue is proxies - enablers - not firewalls - disablers. If
> > you replace
> > my proxy by a passthrough cable I cannot do anything, if 
> you replace my
> > firewall by a cable you can do anything.
> >
> > > From:	Randy Turner [SMTP:[email-masked]]
> > > Sent:	Tuesday, June 02, 1998 8:34 AM
> > > To:	Vinod Valloppillil (Exchange); 'Rob Polansky'; 
> David W. Morris
> > > Cc:	http-wg; [email-masked]
> > > Subject:	Re: IPP> RE: Implications of introducing new 
> scheme and port
> > > The past few comments about firewalls do not (IMHO) 
> appear to pose a
> > > problem for IPP deployment. If the majority of the 
> installed base of
> > > firewall products do not do HTTP method inspection then thats ok.
> > > everything would work. When the "next-generation" 
> products that can
> > > perform
> > > this type of inspection, then during installation of this new
> > > infrastructure, the administrator will then enable IPP 
> (or WEBDAV) or
> > > whatever at that time.
> > >
> > > Ultimately, I believe firewall admins will explicitly 
> enable internet
> > > printing or faxing or whatever, and I don't think a firewall
> > issue should
> > > impose undue design constraints on what we (the WG) want to do.
> > > Firewall admins already do this explicitly enabling/disabling of
> > > application protocols (POP, FTP, IMAP, etc.) and I think 
> we're just
> > > another
> > > application. I don't think these protocol designers were 
> too bogged down
> > > in
> > > firewall issues during the development process. At least with the
> > > Checkpoint Firewall-1 product, it takes about 45 seconds 
> to bring up the
> > > console and enable or disable a particular application protocol.
> > >
> > > Just my (possibly more than) $0.02
> > >
> > > Randy
> > >
> > >
> > >
> > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote:
> > > >Rob's argument is broadly correct -- as a long term 
> firewall design
> > > issue,
> > > >method inspection (and occasionally payload inspection) 
> will become the
> > > >rule.
> > > >
> > > >However, as a small carrot to today's protocol 
> designers, the vast
> > > majority
> > > >of the installed base of firewalls do no method / 
> payload inspection on
> > > HTTP
> > > >data being passed through.   Purely from the perspective 
> of 'reach'
> > > there's
> > > >no impediment to IPP using it's own method in the short run.
> > > >
> > > >> From:	Rob Polansky [SMTP:[email-masked]]
> > > >> Sent:	Tuesday, June 02, 1998 6:06 AM
> > > >> To:	David W. Morris
> > > >> Cc:	http-wg; [email-masked]
> > > >> Subject:	RE: Implications of introducing new 
> scheme and port for
> > > >> existing  HTTP servers
> > > >>
> > > >> 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
> > > >>
> > > >> > 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
> > > >> >
> > > >> > (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.)
> > > >> >
> > > >
> >
>

---

From: Yaron Goland <[email-masked]>
Date: Wed, 3 Jun 1998 16:07:14 -0700

You're right, a non-transparent proxy could reject an unknown method.
However the point was that sending methods not specified in the HTTP spec is
not a protocol violation.

				Yaron

> From: Dave Kristol [mailto:[email-masked]]
> Sent: Wednesday, June 03, 1998 1:17 PM
> To: Yaron Goland
> Cc: 'http-wg'; [email-masked]'
> Subject: Re: IPP> RE: Implications of introducing new scheme and port
> Yaron Goland wrote:
> > Rob clarified in personal e-mail that he meant the latest 
> rev of the HTTP
> > draft.
> > 
> > One of the innovations of HTTP in respect to many other 
> protocols is that
> > you do not need to modify the HTTP standard in order to add 
> new methods for
> > use with HTTP. Rather HTTP defines exactly how one is to 
> act if one receives
> > an unknown method. Thus one can safely add new methods and 
> know that at the
> > worst one will simply receive a method unknown error from 
> servers/firewalls
> > and be tunneled by proxies.
> 
> How can one "know that at the worst one will ... be tunneled by
> proxies"?  I can't find anything in the HTTP/1.1 spec. that instructs
> proxies to tunnel unknown methods.  I think at worst the 
> request will be
> rejected.
> 
> Dave Kristol
>

---

From: "Larry Masinter" <[email-masked]> (by way of Carl-Uno Manros <[email-masked]>)
Date: Thu, 04 Jun 1998 20:51:29 -0700

All, I just found Larry's answer to my earlier question on my home mnachine. 
Unfortunately Larry had not copied the IPP DL.  
Herer it is for the rest of you to enjoy.

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