- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 25 Jan 2000 18:58:54 -0500
- To: w3c-dist-auth@w3.org
From: bill@carpenter.ORG (WJCarpenter) gmc> The second issue is whether a client other than the lock gmc> requesting client should be able to use the lock token to get gmc> access to a resource. Doing so would violate the whole design of gmc> the lock token scheme, which is to have a protocol for reliably gmc> deciding whether a *particular* client has the authority granted gmc> by the lock token. The protocol only works if only the client gmc> that made the LOCK request uses the generated lock token. The gmc> fact that the lock token was issued to a particular principal is gmc> irrelevant. This doesn't address other reasons for doing unambiguous lock discovery. It leaves aside such rainy day scenarios as "oops, my application just crashed (et seq :-))" and "I guess I'll go home for the night and work on this". If you are using shared locks, neither of these scenarios are a problem: you just take out another shared lock and let the orphan locks time out or be eventually cancelled by routine lock administration. If you are using exclusive locks, then your second client must first UNLOCK (i.e. delete the lock from the first client). If the first client is still alive after all, this might leave it with changes that must be "merged", but your client can (and should) make it clear to you that you are taking that risk when you UNLOCK a resource you didn't LOCK. In either case, if you want to make sure that you are taking back your own lock, and not somebody else's, then the DAV:owner element should contain exactly the information the client needs to give to the user in order for the user to decide whether to "cancel" the lock. Note that this can *never* be an automatic operation based on "unambiguous" principal identification. Just because the second client has the same principal as the first provides no guarantee that the first client is no longer alive and active. gmc> So a client should always get its own lock token, not appropriate gmc> an existing one. If a resource is already exclusively locked, it gmc> first will need to UNLOCK the resource. This then guarantees gmc> that if the other client (that issued the LOCK request) is still gmc> around, it will notice the "cancellation" by the failure of its gmc> next update request. This technique also opens a (probably very small) window wherein someone else could grab the lock.(Such events are not always a matter of competition. There are a variety of situations where you want to specify relationships between a resource and a principal (or set of principals), such as: "this principal is the only one that can lock this resource". But holding and maintaining a lock token is pointless for this ... this are relationships between a resource and a principal, and passing around a (publically available) lock token is of no relevance. So I agree we want to be able to associate with a resource the access rights for specific principals, but the lock tokens are irrelevant for this association. You could be under the impression that your co-author was going to release the LOCK when s/he was done and it was your turn.) I'm not sure what point this scenario illustrates, but I predict my answer will be to look at the DAV:owner element of the lock (:-). Cheers, Geoff
Received on Tuesday, 25 January 2000 18:58:56 UTC