> -----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.)
> >> >
> >