Re: Requirements for reliable message delivery

100% support to what Keith points out!

It also explains the hidden reason behind the "customers request"...

:-)

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                        Project Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

     PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09

On Mon, 26 Nov 2001, Keith Moore wrote:

> > HTTP's application model is not at all restrictive.  IMHO, it's the
> > most powerful and generic one ever created.  I wrote about this
> > recently;
> > 
> > http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model
> 
> I like your description, but I fear it completely misses the point.  
> 
> First, the argument about whether HTTP is suitable has little to do with 
> the state model of HTTP - issues like message direction, efficiency, 
> security model, authentication, use of HTTP URIs, and compatibility with
> firewalls are far more germaine.  It's worthwhile to think about the state 
> model but this doesn't justify ignoring the other issues.
> 
> Second, the way that HTTP POST is typically used (and the way in which 
> protocol authors want to use it) bears little resemblance to that
> described in your draft.
> 
> Third, you have failed to support the argument that even the state model 
> you describe in your draft is either 'powerful' or 'generic'.  
> 
> Most people who want to use HTTP aren't attracted to its state
> model.  They're attracted to HTTP because it runs over port 80, works
> through firewalls (usually), seems to have security (which may or 
> may not be appropriate for the user's particular purpose), can be 
> plugged into an existing server, and/or (mostly) because they are 
> (somewhat) familiar and comfortable with it.  They (often incorrectly) 
> assume that by simply using HTTP they can avoid worrying about protocol 
> design issues.  
> 
> Keith
>