- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Wed, 26 Jan 2000 23:39:26 -0500
- To: w3c-dist-auth@w3.org
From: jamsden@us.ibm.com But Geoff, the semantics you describe below would make locks useless (maybe your intent?!). I believe locks are very useful for avoiding merge conflicts between cooperating clients. By "cooperating clients", I mean clients that whenever they want to update a resource: - get an exclusive lock on the resource (LOCK) - get the body/properties of the resource (GET, PROPFIND) - update the body/properties of the resource (PUT, PROPPATCH) - unlock the resource (UNLOCK) If a locking unaware client tries to update the resource, the locking protocol prevents the update while the resource is locked, but has no way of preventing the locking unaware client from getting the state of the resource before or during the lock, and then unknowingly overwriting updates from a locking client because it issues its update after the locking client performed an UNLOCK. This point is made in section 6.7 of rfc2518. Now if rfc2518 stopped there, we'd be fine. But unfortunately, it doesn't, but tries to present locks as also providing authenticated access control (e.g. "the right to update a resource"). The reason this is unfortunate is that "merge avoidance between cooperating clients" and "authenticated access control" require radically different support and semantics. 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. If only the lock token was used to protect from overwrite conflicts, then any user could just do a PROPFIND, get the lock token from the DAV:lockdiscovery element, and then have at the resource! Exactly. Which is precisely what that user can do as soon as you UNLOCK the resource. If you intend on keeping the resource permanently "writable only by a certain principal" (i.e. never issuing an UNLOCK), then requiring a lock token is pointless, since it is the principal that matters, and the lock token is irrelevant. Furthermore, it is the resource you want to control, and that control should survive a MOVE, unlike a LOCK. The spec indicates that the user agent owning the lock, the one taking out the lock in the LOCK request, must be specified along with the lock token. I see no protocol header or XML element in rfc2518 for this purpose. As you've pointed out, the DAV:owner element does not provide this, and as you have also pointed out, saying that something should be the case without providing protocol elements for doing so is useless. It does not however say exactly what the user agent is. That's because ACLs weren't done yet, and the working group didn't want to define principal. So they just punted and left if up to the server implementation with server-specific ACL mechanisms until the ACL spec was done. This is why the principal element wasn't included in the DAV:activelock element. However, I think we've made enough progress in defining ACLs and principals that we can now safely include this information in DAV:activelock in which case all problems are resolved. I've been basing my statements on what is in rfc2518, not on some ACL functionality that might (and hopefully will!) appear in some successor to rfc2518. But I believe the ACL functionality should be orthogonal to the locking functionality, and in particular, the ACL's should have no notion of an "ACL token that must be included in an IF header", nor should an ACL on a resource imply any "protection" of any URL to that resource. When this is done, I expect to see a DAV:acl-discovery element defined, and with appropriate DAV:principal sub-elements. Cheers, Geoff
Received on Wednesday, 26 January 2000 23:39:33 UTC