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

RE: FW: LC Comments: Web Method Feature

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 5 Jul 2002 14:06:33 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A06F03@0-mail-1.hpl.hp.com>
To: "'Mark Baker'" <distobj@acm.org>
Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 04 July 2002 17:10
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: Re: FW: LC Comments: Web Method Feature
> 
> 
> Hey again,
> 
> FWIW, I think we're doing a fine job at getting to the point here,
> unlike some of our previous "blossoming" exchanges. 8-)
> 
> On Thu, Jul 04, 2002 at 09:07:54AM +0100, Williams, Stuart wrote:
> > > The access and manipulation operations *are* messages.  I don't
> > > understand the distinction you're making.
> > 
> > I guess I'm making a distinction between mean and ends. Messages are the
> > means to transfer representations of resource state.  But the ends is
the
> > access and manipulation of resource state, not the exchange of messages.
> 
> Right, I understood that.  But a message needs an intent in order for it
> to be a message, even if that intent is just "here, take this" (like
> HTTP POST or SMTP DATA).  Otherwise it's more like a "packet".

And HTTP knows the intent of the message? That a message is intended to
cause money to be debited from my credit card and some goods to be shipped
to my home address?

I will grant that the 'this message' may not be used to construe a
commitment is a very useful property to know of an HTTP GET request.

> I'm not sure if that adds value to this conversation, but I thought I'd
> toss it out. 8-)
> 
> > > "The difference between an application-level
> > > protocol and a transport-level protocol is that an application-level
> > > includes application semantics, by standard agreement, within
> > > the messages that the protocol transfers.  That is why HTTP is called
> > > a Transfer protocol.  It is impossible to conform to an 
> > > application-level protocol without also conforming faithfully to
> > > its message semantics."
> > >  -- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0303
> > 
> > Firstly I agree with Roy, but I would also generalise this as:
> > 
> > "The difference between an N layer protocol and a M layer protocol is
that a
> > N layer protocol includes layer N semantics, by standard agreement,
within
> > the messages that the protocol transfers.... It is impossible to conform
to
> > an N layer protocol without conforming faithfully to its message
semantics."
> > 
> > With which I also agree.
> 
> Good point.  I guess Roy's use of the word "conform" there wasn't as
> precise as it should have been.
> 
> Let's look at this another way.  Typically, a layer has two uses; it
> can be extended, or it can be layered on top of.  For example, TCP has
> been extended many times by RFCs such as 2414, 1323, 1072, etc..  But of
> course, TCP has also been layered on top of many times; HTTP, for
> example.

Ok... but at least with respect to the 3 'extensions' you cite, none change
the semantics of TCP. The presense of support for those extensions in a
given TCP implementation is only a concern for those TCP users that want to
use them. Unaware TCP users can simply ignore them.

Anyway... I think I understand the difference between extension and
layering.

> What's special about the application layer, is that it is the "top dog".
> You can't layer on top of it and still call yourself a valid use of
> that protocol.  You can only extend it.

Well there's to rub... you attribute the label 'application' to HTTP and
IIRC the 'application' that you cite HTTP as being the 'application' for is
'the Web'. I find myself seeing 'the Web' as a platform upon which
applications in classes such as on-line commerce, news and information
delivery, search and retrieval... and there are many instances of
applications in each of these classes. Which makes the Web a means and not
an end.

> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com

I fear that we may be well off topic by now...

Regards

Stuart
Received on Friday, 5 July 2002 09:06:49 GMT

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