RE: T is for Transfer

Joe - please see my comments/request for clarification below....


-----Original Message-----
From: Joseph Hui [mailto:jhui@digisle.net]
Sent: Thursday, March 28, 2002 1:00 PM
To: Mark Baker; Appleton Pete M
Cc: highland.m.mountain@intel.com; xml-dist-app@w3.org
Subject: RE: T is for Transfer


>>This is interesting.

Yes, you are right, and it is consuming a great deal of my time ; - )

>>Mark's right that HTTP, unlike TCP or UDP, is not a transport
>>protocol in an OSI or DARPA networking stack.

>>However, Highland's claim, as far as I can tell from the quoted text
>>in Mark's message, is only that HTTP can be seen as a transport.
>>I have no problem with referring to HTTP -- which itself assumes an
>>underlying reliable transport protocol, say TCP, for transferring
>>HTTP messages reliably -- as a transport, where HTTP message headers
>>and bodies are used to carry application-level payloads.
  
>>HTTP is not a transport protocol by design; but it doesn't stop people
>>from seeing it as one creatively, often for its "port-80 firewall
>>friendliness."  

It is because of this fact that our specification better make the
application/transport protocol distinction.  Is the generic Protocol Binding
Framework title vs the former Transport Protocol Binding Framework title
enough to communicate this distinction.  If the WG feels strongly about this
distinction then more should be said about it in the spec.

>>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? Are you implying that these should only be handled by HTTP extended
headers?

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 15:36:08 UTC