- From: <jamsden@us.ibm.com>
- Date: Mon, 31 Jan 2000 07:59:17 -0500
- To: w3c-dist-auth@w3.org
<geoff> As is made clear in rfc2518, restricting use of a lock-token to the principal that requested the lock does not provide overwrite protection, since a principal can have *multiple* clients acting on his behalf. The only reason for having lock-tokens is to provide overwrite protection, and overwrite protection requires that a lock-token be only used by the *client* (not the principal) that created the lock-token. So the fact that your client is acting on behalf of a certain principal is irrelevant to the proper use of lock-tokens. What matters is that a client only uses lock-tokens that it has issued. Alternatively, if clients aren't going to restrict themselves to using the lock tokens that they created via LOCK, but will grab any lock-token that was created by their principal, then there is no reason to have the complexity of lock-tokens in the protocol. </geoff> <jra> We're getting there. The reason for associating the lock token with a principal is to give that principal the flexibility of running concurrent clients that may update the same resource. Since not all these clients actually locked the resource but got the lock token some other way, they are aware that there might be other clients that have the same lock token and can warn the principal before using the lock token to update a locked resource. To enforce Geoff's semantics, that is to make locks more than just advisory, the lock token would have to be associated with the particular client application, and HTTP does not support such an identity. So although I agree that complete overwrite protection would require all clients to get their own lock token, I don't think this is an acceptable solution because: 1. locks are only advisory, any client, including clients of another principal can simply ignore them and overwrite the resource. 2. enforcing such locks would require specific client identification which is not possible using HTTP. 3. Multiple clients run by the same principal would have to get there own possibly exclusive write locks which would limit data availability by a single principal who likely knows what they are doing at the moment, and if it is safe to proceed with an update. For example, the principal may be running many concurrent clients, but only one of them is active at a time. The others are all waiting for input. So I think associating the lock token with a principal is a reasonable and useful compromise. It doesn't give absolute and complete overwrite protection for multiple current clients run by the same principal, but it does guarantee overwrite protection between principals. Note that GULP R8 is consistent with associating principals with lock tokens: R8: If a resource has a write lock with target ".", a request cannot modify the body or dead properties of that resource unless the principal of the request owns a write lock with target "." on that resource and the token of that write lock is specified in an IF header.
Received on Monday, 31 January 2000 08:01:46 UTC