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

From: Josh Cohen <[email-masked]>
Date: Mon, 1 Jun 1998 10:51:56 -0700

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: 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: Paul Moore <[email-masked]>
Date: Wed, 3 Jun 1998 09:12:02 -0700

I just want to be clear on what I am trying to say:- 

Firewalls are a completely legitimate and valuable tool in the Internet and
I think that issues associtaed with IPP and its penetration or otherwise
through them are extremely important. Having said that I think that the
proxy issue is the more important one because:-

a) This is how most businesses users access the Internet 
b) They invert the firewall model (a firewall blocks, a proxy enables)

If we use a mechanism not carried by the current proxy installed base then
the majority of business users will not be able to use IPP to talk to
'printers' on the Internet. This would be a big change. I do not place a
value judement on this - I merely point out the enormity of the change that
would occur.

I should point out that at one of the first IPP meeting attended by MS we
pointed out that using HTTP primarily as a means of 'stealthing' through
firewalls was totally bogus and this continues to be our position. The PWG
came to an uneasy agreement that the 'firewall issue' was no longer open for
debate since the group divided in two on it and would not be reconciled.

> From:	Rob Polansky [SMTP:[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 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]]
> 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
> cache point of view will interoperate. The difference is when 
> they encounter
> to make their protected resources vulnerable to attacks; most 
> other software
> Once again, if IPP uses existing methods and schemes, it 
> should be passable
> CHANGE THE STANDARD, and you should expect that existing 
> implemenations will
> > > To:	Vinod Valloppillil (Exchange); 'Rob Polansky'; 
> David W. Morris
> > > Cc:	http-wg; [email-masked]
> > > application. I don't think these protocol designers were 
> too bogged down
> > > in
> > > Checkpoint Firewall-1 product, it takes about 45 seconds 
> to bring up the
> > > >method inspection (and occasionally payload inspection) 
> will become the
> > > >rule.
> > > >
> > > >of the installed base of firewalls do no method / 
> payload inspection on
> > > HTTP
> > > >> Subject:	RE: Implications of introducing new 
> scheme and port for
> > > >> existing  HTTP servers
> > > >>
> > > >> but also examines the HTTP request method as part of 
> its "algorithm".
> > > From
> > > >> a
> > > >> failing to pass IPP if it uses a new scheme and/or a 
> new method. Not
> > > that
> > > >> > 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]'
> 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
>