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

RE: T is for Transfer

From: Appleton, Pete M <PMAppleton@bemis.com>
Date: Thu, 28 Mar 2002 16:06:53 -0600
Message-ID: <D9860668E25BA24B93D14DE111B475977062@NT160_MAIL.bemisltduk.local>
To: "'Joseph Hui'" <jhui@digisle.net>, "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
+1

<snip />
> 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. :-)

Sure do!!!!

> 
> 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:07:25 GMT

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