Re: Requirements for reliable message delivery

Guys,
I agree - HTTP is something that needs to be done in the near term but that
doesn't stop a proper solution being developed in the medium/longer term.
John

XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com



                                                                                                              
                    Brian E                                                                                   
                    Carpenter            To:     Keith Moore <moore@cs.utk.edu>                               
                    <brian@hursley       cc:     Jim Gettys <jg@pa.dec.com>, Claudio Allocchio                
                    .ibm.com>             <Claudio.Allocchio@garr.it>, Mark Baker <distobj@acm.org>, John     
                                          Ibbotson/UK/IBM@IBMGB, Discuss Apps <discuss@apps.ietf.org>,        
                    11/28/2001            Richard P King/Watson/IBM@IBMUS                                     
                    04:29 PM             Subject:     Re: Requirements for reliable message delivery          
                                                                                                              
                                                                                                              
                                                                                                              




Keith, layering over *something* seems to be the only solution...
it certainly doesn't have to be HTTP and that isn't at all
what John Ibbotson's draft is saying, unless I've misread
it badly.

  Brian

Keith Moore wrote:
>
> > > > Exactly. We can all agree on this. So given that fact, and the fact
that
> > > > people do want to reliably transfer hypertext across unreliable,
> > > > non-transparent and intermittently connected networks, what should
we do?
> > >
> > > We should explain why it doesn't make good sense to do these things,
> > > and provide alternatives that do make sense.
> >
> > Wait a minute. I'd love it if the network was reliable, transparent
> > and connected 100% of the time, but it isn't. We have to deal with
that.
>
> so how does layering over HTTP help this situation?  it certainly
> doesn't add reliability or transparency, nor does it help fix
> broken connections.  you can provide reliability and transparency
> over HTTP, but you have to work harder to do this than to provide
> the same services over IP.
>
> even if you use HTTP as a means to get through firewalls, this is a short
> term fix at best.  because the fact that traffic is tunnelled over HTTP
> doesn't mean that it's any more suitable to pass through the firewall
> than raw IP traffic.
>
> what we need are better means to provide security than our current
> firewalls, with fine-grained access control that is based on other
> properties than just the network locations of the participants, with
> the ability to specify access control centrally (within a domain).
> but enforcement done by the hosts and servers.   firewalls should
> also be able to examine credentials and provide coarse filtering of
> traffic to protect the network and to provide security in depth.
> and the credentials need to be usable in multiple security domains.

Received on Tuesday, 4 December 2001 10:52:11 UTC