RE: T is for Transfer

This is interesting.

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."  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.

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