- From: Mark Baker <distobj@acm.org>
- Date: Tue, 18 Dec 2001 11:55:27 -0500 (EST)
- 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 UTC