RE: T is for Transfer

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