W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: T is for Transfer

From: Joseph Hui <jhui@digisle.net>
Date: Thu, 28 Mar 2002 14:02:33 -0800
Message-ID: <C153D39717E5F444B81E7B85018A460B081B2798@ex-sj-5.digisle.com>
To: "Mountain, Highland M" <highland.m.mountain@intel.com>, "Mark Baker" <distobj@acm.org>, "Appleton Pete M" <PMAppleton@bemis.com>
Cc: <xml-dist-app@w3.org>
> From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]
[snip]
> >>I'd be quite comfortable to design an application
> >>protocol that specifies HTTP as its transport where in-band data
> >>(e.g. HTML content) are carried in HTTP bodies, and out-of-band
> >>data ( e.g. application-specific content signals) are embedded
> >>in HTTP extended headers.
> 
> 
> Please clarify...where would the SOAP envelope belong in this 
> approach: 
> a)in-band data  (HTTP body)
> b)out-of-band data - SOAP carries application-specific 
> content signals,
> correct?

So I was in SOAP (context) and I didn't even know it
(when I responded to Mark's new thread). ;-)
No matter.  I'll do what I can to clarify, by answering
the question directly.
The SOAP envolope should be the super structure for the
in-band and out-of-band data, i.e. data should be contained
within the SOAP envelope.  
It's bad engineering to transfer data of identical PDU
type -- in this case, SOAP is the PDU type -- in separate
protocols, let alone seperate protocol layers.  (SOAP sits
above HTTP.)  So no.

> Are you implying that these should only be handled 
> by HTTP extended headers?

Also no, absolutely not. 
Doing so will make binding SOAP to other reliable
transports (like TCP) infeasible.  
(TCP's out-of-band (aka urgent) data semantics stink.
But that's another story. :-)

Hope it helps.

Joe Hui
Exodus, a Cable & Wireless service
==========================================
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> ============================================
> 
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@acm.org]
> > Sent: Thursday, March 28, 2002 11:15 AM
> > To: Appleton Pete M
> > Cc: highland.m.mountain@intel.com; xml-dist-app@w3.org
> > Subject: T is for Transfer
> > 
> > 
> > > Yes, I do see HTTP as being purely transport.
> > 
> > With all due respect, it doesn't matter how you see it, it 
> is *not* a
> > transport protocol.  You can use it this way, the same way I 
> > can use any
> > application protocol as a transport protocol by 
> disregarding the task
> > that the application protocol is trying to coordinate.  But 
> > that doesn't
> > make it one.
> > 
> > http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.
> htm#sec_6_5_3
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
> 
> 
Received on Thursday, 28 March 2002 17:03:04 GMT

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