Re: RFC-2518 LOCK-TOKEN: header

<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