Re: FW: LC Comments: Web Method Feature

On Friday, July 5, 2002, at 01:56 PM, Champion, Mike wrote:
>> -----Original Message-----
>> From: Mark Baker [mailto:distobj@acm.org]
>> Definitely a terminology issue, but what you build when you
>> build a "Web
>> app" is not an application in the OSI sense of the word, it's just an
>> addition to the existing application of the Web, though perhaps with
>> "extended intents".
>
> Is OSI normative for "the Web" (whatever that is) or the Internet?

No.

> There's a lot about REST that I find illuminating, but this "thou shalt
> treat HTTP as the highest level application of The Web" commandment is
> unpersuasive to me, and apparently many others.  It's The Right Thing for
> one technology generation's top level to be the next generation's
> infrastructure.

TCP/IP is not an OSI protocol stack, and was not built using the 
principles (or horrid compromises, take your pick) of the OSI 7-layer 
model.  That model failed horribly in the real world of interoperability, 
despite a five to ten year mandate for its adoption by the US government 
(which has a lot of weight to throw around).

TCP/IP is built on a four-layer model: hardware, IP, TCP/UDP, and 
application.  These correspond, roughly, to layers 1 into 2 of the OSI 
model, layers 2 through 3, layers 4 into 5, and layer 7 (layer 6, 
"presentation," is either above the application or in the IP layer, in 
practice).

HTTP is itself effectively built on another application protocol, the 
Network Virtual Terminal (as are SMTP, FTP, and many other basic protocols,
  the most primitive of which is Telnet, which can be used to "imitate" the 
other protocols by supplying an interactive Network Virtual Terminal, in 
which the user supplies client semantics).  If one were to try to 
characterize HTTP in 7-layer-land, it ends up spanning at least layers 
five to seven, but lives on top of an abstraction that lives in layer 
seven.  Which proves little except that applying a foreign model to the 
protocols in the TCP/IP suite doesn't get you very far, outside of a 
textbook.

MIME is an example of a super-application layering as well; it carries 
information over protocols that were not originally designed to support 
the carriage of those sorts of information.  Is it an extension or a layer?
   Well ... it's quite possible to handle MIME/SMTP messages without 
knowing a thing about MIME.  Such a message is completely compatible with 
all the things that a message transfer agent might want to do with a 
message (but a message user agent that doesn't understand MIME won't 
usually get much joy from attempting to display the content).  Rather like 
SOAP, really.

Another example: Sun RPC lives in the application layer of the four-layer 
model, but is intended solely to enable "true" application protocols, such 
as NFS.

In TCP/IP's four-layer model, it is perfectly reasonable to layer 
application protocols and application abstractions on top of one another.  
There is no "top of the stack;" the term "application" was preferred in 
both models in order to indicate that something happens in this area that 
has less well-defined semantics than (in TCP/IP) hardware, address & 
routing, and delivery semantics, or (in the OSI model) hardware, link 
control and addressing, routing, delivery semantics, connection semantics,
  and display control.

Keep in mind, too, that ten and fifteen years ago there were vocal 
opponents of ftp-to-email gateways and of MIME.  "SMTP is a *message* 
protocol.  If you want to transfer files, use a *file* *transfer* protocol.
"  The glorification of HTTP as the highest possible layer in the stack 
seems to reflect those attitudes.

Amy!
--
Amelia A. Lewis
Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 5 July 2002 23:16:08 UTC