W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: New issue (?): locktoken (12.1.2) syntax

From: Jason Crawford <ccjason@us.ibm.com>
Date: Wed, 10 Jul 2002 23:48:09 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
Message-ID: <OFBF583B55.951C4DDD-ON85256BF3.0013900A@us.ibm.com>
                                                                                                               
                                                                                                               
                                                                                                               


<<
Question: why would multiple lock tokens refer to the same lock? And *if*
there are multiple URIs referring to the same lock (a consequence of
BINDs???), what's the point in reporting more than one? Is anybody using
this? Has interoperability been tested?
>>
That caught me by surprise.  But you made me read a bit and I did
uncover the following.   Apparently in the case of a shared lock
it's considered the same lock, just different tokens.  It's not
clear they actually mean that with the following wording, but the
following is just one of several places where they use the same
sort of wording.

7.2 Write Locks and Lock Tokens

   A successful request for an exclusive or shared write lock MUST
   result in the generation of a unique lock token associated with the
   requesting principal.  Thus if five principals have a shared write
   lock on the same resource there will be five lock tokens, one for
   each principal.


This leaves me perplexed about how UNLOCK works for shared locks.   I
suggest we (1) check with Yaron if this was intentional and get an
explanation and (2) make it clear that each lock has one token and a
shared lock means that multiple locks are acting on a resource, not
just multiple tokens.  (Does anyone know how to contact Yaron?)

J.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
Received on Thursday, 11 July 2002 01:07:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT