Re: RFC-2518 LOCK-TOKEN: header

   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