RE: T is for Transfer

> With regard to Mark's statement, I accept the spirit of the 
> argument and have no desire to start a flame war.  However, 
> re. "T is for Transfer", please remember that HTTP does stand 
> for "Hyper Text *Transfer* Protocol". It tends to be used for 
> HTML, but that is a layer overlying HTTP - my position is 
> that SOAP can be layered over HTTP, with equal status to 
> HTML, but that HTTP does not imply either HTML or SOAP as the 
> actual message transferred - indeed, looking back at Mark's 
> previous message referring to RDF, this implies that HTTP is 
> being used as a transport for RDF.

But there's a big difference between using HTTP to transfer the
representations of a resource and using it to transfer/transport a blob
that has its own application semantics.

The former means you're using GET, POST, PUT, DELETE, etc. and following
all the usual, expected rules that HTTP specifies, which allows a whole
lot of interesting things to happen in the world automatically. It also
allows for composability because I can address those representations
(the GET-able ones anyway) from my own. HTTP doesn't specify the content
of those representations, but it does specify the semantics of the
transfer.

The latter (ie. SOAP today) is using HTTP in such a way that you could
cross out HTTP and write in TCP and lose nothing in the bargain. You get
only the free use of the HTTP stack, which is easier for (some)
programmers to use than the TCP stack. The firewall advantage is silly;
the first thing the firewall vendors will do once SOAP is finalized is
distribute the "SOAP stops here" upgrade.

Scott Cantor
cantor.2@osu.edu
Office of Info Tech
The Ohio State Univ

Received on Thursday, 28 March 2002 17:12:48 UTC