- From: <jamsden@us.ibm.com>
- Date: Thu, 27 Jan 2000 09:49:15 -0500
- To: w3c-dist-auth@w3.org
<geoff> In particular, for merge avoidance, a lock token is required, and which principal is issuing the request is irrelevant. On the other hand, for authenticated access control, the principal is required, and a "lock-token" is irrelevant. Thus all the confusion in the working group about when/where a principal is required and when/where a lock token is required. Furthermore, for merge avoidance, you want to protect the URL, because the URL is what the client is holding as the "key" to identify the resource being authored. On the other hand, for authenticated access control, it is the *resource* that is being controlled, not the URL. Thus all the confusion in the working group about whether a resource is being protected or whether a URL is being protected. So whatever was intended by WebDAV locks, the protocol that is specified in rfc2518 does a fine job of preventing merge conflicts for cooperating clients, and is totally inadequate for providing authenticated access control. So I propose that anyone that cares about authenticated access control become active in the WebDAV ACL specification effort, and just use WebDAV locks for what they can do, namely prevent merge conflicts for cooperating clients. </geoff> <jra> OK. Now I see what you're getting at. I didn't understand you were proposing something that isn't in RFC2518 - lock tokens to prevent merge conflicts for COOPERATING clints. (I know you said it a number of times, I just kept interperting it from the point of view of the existing spec.) This is an interesting approach, and one that could be more acceptable if we had ACLs. But what does it hurt to require the lock token/authorization pair? Especially in the case of shared locks? Wouldn't this allow the server to "help" the clients cooperate? Isn't this the more traditional notion of locking? </jra>
Received on Thursday, 27 January 2000 11:14:36 UTC