- 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
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 UTC