Thanks,
Yaron
> -----Original Message-----
> From: Rob Polansky [mailto:polansky@raptor.com]
> Sent: Wednesday, June 03, 1998 5:55 AM
> To: Paul Moore
> Cc: http-wg; ipp@pwg.org
> Subject: RE: IPP> RE: Implications of introducing new scheme and port
> for existing HTTP servers
>
>
> 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
>
> > -----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.)
> > > >> >
> > > >
> >
>