- From: <Noah_Mendelsohn@lotus.com>
- Date: Thu, 25 Oct 2001 22:45:15 -0400
- To: Mark Baker <distobj@acm.org>
- Cc: kumeda@atc.yamatake.co.jp (Kumeda), marc.hadley@sun.com (Marc Hadley), ms@mitre.org (Marwan Sabbouh), skw@hplb.hpl.hp.com (Williams Stuart), xml-dist-app@w3.org
Mark Baker writes: >> This is only appropriate in the tunnel view of >> the underlying protocol. I don't think so. I think you are missing a common case in which features are defined that map naturally to multiple protocols. Take simple request/response. I can do a reasonable mapping of certain forms of request/response to http without "tunnelling" in any very bizarre way. Http will understand to a fair degree that it is a req/resp. I can map the same request response to smtp, possibly even using the "reply to" header for routing the reply. In that case, SMTP also understands, and you're not really tunnelling. I bet I could find several other transports that would provide a similar service without tunnelling (I.e., in which the transport knew I was doing req/resp, and was supporting it in a way natural to the transport.) Sometimes the same pattern or feature is tunnelled on one protocol, but not another. One could argue that request/response over TCP would in some sense necessarily be tunnelled, as TCP doesn't really have that flavor. Still, letting the application see all of these as common is very, very useful. If you really want a pattern or feature that truly exploits the nuances of exactly one transport, that's fine too. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Thursday, 25 October 2001 23:02:04 UTC