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
> -----Original Message-----
> From: Paul Moore [mailto:paulmo@microsoft.com]
> Sent: Tuesday, June 02, 1998 8:37 PM
> To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob Polansky'; David
> W. Morris
> Cc: http-wg; ipp@pwg.org
> Subject: RE: IPP> RE: Implications of introducing new scheme and port
> for existing HTTP servers
>
>
> 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.
>
> > -----Original Message-----
> > From: Randy Turner [SMTP:rturner@sharplabs.com]
> > Sent: Tuesday, June 02, 1998 8:34 AM
> > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. Morris
> > Cc: http-wg; ipp@pwg.org
> > Subject: Re: IPP> RE: Implications of introducing new scheme and port
> > for existing HTTP servers
> >
> >
> > 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.
> > >
> > >> -----Original Message-----
> > >> From: Rob Polansky [SMTP:polansky@raptor.com]
> > >> Sent: Tuesday, June 02, 1998 6:06 AM
> > >> To: David W. Morris
> > >> Cc: http-wg; ipp@pwg.org
> > >> 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
> > >>
> > >> > -----Original Message-----
> > >> > From: David W. Morris [mailto:dwm@xpasc.com]
> > >> > Sent: Monday, June 01, 1998 10:34 PM
> > >> > To: Carl-Uno Manros
> > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com
> > >> > 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.)
> > >> >
> > >
>