W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: RFC-2518 LOCK-TOKEN: header

From: WJCarpenter <bill@carpenter.ORG>
Date: Tue, 25 Jan 2000 14:58:57 -0800
Message-ID: <2271-Tue25Jan2000145857-0800-bill@carpenter.ORG>
To: w3c-dist-auth@w3.org
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".

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.  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.)
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
Received on Tuesday, 25 January 2000 18:03:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC