- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 9 Jan 2002 11:00:50 -0800
- To: Mike Dierken <mike@dataconcert.com>
- Cc: "'Xml-Dist-App@W3. Org'" <xml-dist-app@w3.org>, "'David Orchard'" <david.orchard@bea.com>
+1 HTTP is not the place to do reliability. HTTPR is 'layered' on top of HTTP in the sense that it defines a message format that is transported in the HTTP body, making it opaque to HTTP, but it still requires on HTTP. You can't take a HTTPR payload and stick it in SMTP, for example. If reliability is done this high in the stack, it should either encapsulate the application protocol (a la TLS) or it should be integrated well into the application protocol (e.g., as a SOAP header, or much less preferably, an HTTP extension). On Wed, Jan 09, 2002 at 09:23:33AM -0800, Mike Dierken wrote: > > > > -----Original Message----- > > From: David Orchard [mailto:david.orchard@bea.com] > > > > Why is there a need for reliable http? I believe that > > reliability should be layered on top of HTTP, and SOAP is a > > good place to do it. > > > > Imagine the multi-hop case, and you can immediately see why > > the higher layer needs end-to-end reliability. > > I agree. Has anybody done a message sequence diagram showing the http > messages > that would flow in: > a) multi-hope situation > b) client initiated situation (the 'request' is in the response to a client > request) > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 9 January 2002 14:30:18 UTC