W3C home > Mailing lists > Public > www-ws@w3.org > December 2001

Re: W3C THP Note Comment Response

From: Mark Baker <distobj@acm.org>
Date: Tue, 18 Dec 2001 11:55:27 -0500 (EST)
Message-Id: <200112181655.LAA06492@markbaker.ca>
To: highland.m.mountain@intel.com (Mountain, Highland M)
Cc: www-ws@w3.org ('www-ws@w3.org'), michael.w.condry@intel.com (Condry Michael W), randy.e.hall@intel.com (Hall Randy E), krishnamurthy.srinivasan@intel.com (Srinivasan Krishnamurthy), pallavi.g.malu@intel.com (Malu Pallavi G)
Thanks for your response, Highland.

> Mark,
> 
> Thank you for your interest in the Tentative Hold Protocol submission from
> Intel.  We appreciate your comments and suggestions.  Here is our response
> to your points regarding our submission:
> 
> 1) One note of clarification, THP is not an RPC based protocol, but document
> based  .

Yes, that's true.  I should have said "better than a tunnel based
solution", which THP is.

>  Also, THP does not Lock resources, but marks them as held, in a
> business context.
> Because of this, we believe WebDAV locking may not be appropriate.

Yes, I acknowledged that possibility.  I don't have a strong opinion
on this point, I was just introducing the possibility of reusing an
existing, similar mechanism.

> 2) Regarding a new Web DAV Hold method using an "e-tag like" mechanism, we
> are uncomfortable using an HTTP extension to facilitate an application level
> semantic.

Hmm, why would that be?  HTTP is an application protocol that already
defines several general application semantics that can be applied to
any URI.  I see "HOLD" as being a complementary application semantic to
GET, PUT, POST, DELETE, etc..

>  We do not want to tie THP to the underlying protocol by
> incorporating the Hold action to a transport protocol extension.

To reiterate, HTTP is not a transport protocol, it's an application
protocol.

You might be interested in something I wrote up for the XMLP WG about
this;

http://www.markbaker.ca/2001/07/SoapUses/

>  THP would
> be better served by creating a SOAP extension to facilitate resource
> Tentative Holds where the resources in question are outside the scope of the
> transport protocol (these resources would typically be represented by
> database records).  

I don't believe it would for the reasons giving above.  I believe it
would be best served by extending HTTP's application semantics.

> 3) We agree with the notion of a SOAP/HTTP extension with a non-rpc
> approach, where these extensions would be facilitated via a well-understood
> header.  These SOAP extensions could then be reused over other protocols. 
> 
> Please let us know if you are satisfied with the above statements or if we
> misinterpreted any of your points.  If you would like to discuss this
> further, we would be open to hosting a conference call, at your earliest
> convenience.  
> 
> Thank you again for your comments.

My pleasure.  Thanks again for your thoughtful response.

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, 18 December 2001 11:56:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:38 GMT