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

Re: When is a Fault a Fault?

From: Mark Baker <distobj@acm.org>
Date: Tue, 5 Mar 2002 08:03:24 -0500 (EST)
Message-Id: <200203051303.IAA29616@markbaker.ca>
To: jacek@systinet.com (Jacek Kopecky)
Cc: chris.ferris@sun.com (Christopher Ferris), skw@hplb.hpl.hp.com (Williams Stuart), xml-dist-app@w3.org
Ok, one last stab at this ... 8-)

>  Mark,
>  my position about your examples is that I specify what happens 
> when somebody sends me an evelope to 10.0.0.1:2345, exactly the 
> same way that I specify what happens when somebody sends me an 
> envelope to http[POST]://systinet.com/jacek.

You tunnelists may do things this way 8-), but application protocols
already have a way of specifying "what happens"; their method set.
Agreeing on "what happens" up front is what allows a priori
communications to occur, which our charter requires.

Granted, you could advertise that a message sent to 10.0.0.1:2345 means
whatever, but giving that intent a name and including it in the framed
message as a method (like GET, PUT, POST) has superior extensibility and
visibility (read; security) properties than keeping it out-of-band.

> It's not like the 
> sender's telling me how to understand and process the envelope, 

That's exactly how application protocols work.  The methods are
predefined.  No more agreement between endpoints is needed to
implement that application.  Sending a resume with PUT means something
different than sending it with POST, and both client and server share
a common understanding of those intents because they have been
predefined in RFC 2616.

You have to agree on what happens (the methods) at some layer.  RPC
professes to be such a layer, yet by doing so, stomps over the agreement
(the methods) that is made beneath it.

> it's me telling the sender what it can expect when it sends me an 
> envelope.
>  And we have, too, got back to REST - I haven't (yet) fully 
> accepted this fairly restricted view of HTTP. The (yet) part is 
> because I can see how REST can be useful in its restrictedness. 
> 8-)

REST is restrictive in the same way spoken languages are restrictive;
sure, you have to follow certain base rules (grammar, spelling,
punctuation), but once you've learned them, you can talk about anything
with anybody who speaks that same language, a priori.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Tuesday, 5 March 2002 08:12:42 GMT

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