W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

Re: Action Item - Part I: WSRX and MEP signaling on the wire

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 5 Jan 2006 12:12:38 -0500
To: David Hull <dmh@tibco.com>
Cc: Mark Baker <distobj@acm.org>, xml-dist-app@w3.org
Message-ID: <OFD30C0747.4040C55F-ON852570ED.005DC348-852570ED.005EADE0@lotus.com>

David Hull writes:

> Sorry to have caused bleeding or other discomfort, but no 
> matter how ironclad HTTP may be, and no matter what kind of 
> protocol we decide to call it, there will be situations in 
> which a given HTTP operation is only part of the story.  If we 
> consider such situations, then whether HTTP has transported or 
> transfered a message seems moot.  For the record, I would tend 
> to agree that in the case I describe we are using a transfer 
> protocol for transport.

I think there are indeed times when using HTTP in a tunneled manner may be 
a necessary evil, but the tone of your note seems to de-emphasize the 
downsides.  It is reasonable, IMO, for HTTP aware software to assume in 
general that the semantics of an HTTP interaction are what the spec says. 
I believe it's a fair reading of the HTTP spec. that the response you 
receive is indeed to be semantically a response to the corresponding 
request. 

You are right that one can imagine a useful class of software that will 
indeed do useful things when this invariant is violated.  There may indeed 
be times when async streams resulting, e.g., from reliable message flows 
can be useful tunneled over multiple HTTP connections.  That said, I think 
that we should approach such practice with great hesitancy.  Almost surely 
some of the useful characteristics of HTTP will be compromised, at least 
in terms of one's ability to use arbitrary HTTP aware tools (certainly 
logging and management software is likely to give misleading reports about 
the state of a "Request"). 

So, I don't think the difference is "moot" at all.  I think it's a crucial 
difference.  I also think that in some cases one may find that using HTTP 
as a transport is an appropriate compromise, but certainly not an entirely 
happy one.

Also, one other thing:  it is a nice characteristic of application-level 
Request/Response that receipt of the response does give you reliable 
acknowledgement that all levels of the software have worked, that the 
application has indeed been invoked, and in the absence of bugs, that the 
response is authoritative.  I read your note as implying that each level 
requires its own notion of reliability.  The end-to-end argument [1,2,3] 
suggests that not to be true in all cases.  (BTW: as I've mentioned once 
or twice in the past, [2] is about my all time favorite CS paper.  Highly 
recommended.)

Noah

[1] http://portal.acm.org/citation.cfm?id=357402
[2] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
[3] http://web.mit.edu/Saltzer/www/publications/endtoend/ANe2ecomment.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Thursday, 5 January 2006 17:13:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT