- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 16 Jul 1998 20:06:15 -0700
- To: Yaron Goland <yarong@microsoft.com>, "'Jim Amsden'" <jamsden@us.ibm.com>, w3c-dist-auth@w3.org
Damn. I agree, Jim Amsden did discover a bug in the spec. I agree with Yaron's proposed changes. - Jim > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Wednesday, July 15, 1998 12:18 PM > To: 'Jim Amsden'; 'w3c-dist-auth@w3.org'; Jim Whitehead (E-mail) > Subject: RE: Locking questions > > > Jim, you were absolutely right, we got a bug in the spec. > > Insert after section 6.1: > > "6.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 then there will be five outstanding unique lock tokens." > > Add to the end of the last paragraph in section 7.10.1: > > "If the LOCK request was for a new lock and was successful then the > Lock-Token response header MUST be included in the response in order to > indicate the lock token associated with the newly created lock. > That is, the > Lock-Token header would not be returned with a successful refresh LOCK > request because a new lock wasn't created." > > Replace Section 8.5 with: > > "8.5 Lock-Token Header > > Lock-Token = "Lock-Token" ":" Coded-URL > > The Lock-Token request header is used with the UNLOCK method to > identify the > lock to be removed. The lock token in the Lock-Token request header MUST > identify a lock that contains the resource identified by the > Request-URI as > a member. > > The Lock-Token response header is used with the LOCK method to > indicate the > lock token created as a result of a successful LOCK request to > create a new > lock." > > For the record I believe this error made it into the spec because at the > last minute I proposed and the group accepted removing the lock-token > response header as it was "redundant" because we returned the > lockdiscovery > information in all LOCK responses. As you discovered Jim, the > header was not > redundant at all because we do not yet have a mechanism for generically > identifying principals. > > What I'm now wondering is if Jim is the only one who has tried to > implement > shared locks. I figure he must be or this one would have shown up earlier. > > Normally finding an error of this magnitude would earn you an entry in the > Acknowledgement section, but you are already there. I don't suppose we can > just buy you off with a Microsoft DAV T-shirt? =) > > Yaron > > > > > -----Original Message----- > > From: Yaron Goland > > Sent: Tuesday, July 14, 1998 5:20 PM > > To: 'Jim Amsden'; w3c-dist-auth@w3.org > > Subject: RE: Locking questions > > > > > > > <jra> > > > But there may be many shared locks in the lockdiscovery > > > property. How would an > > > application figure out which one was the one just created for > > > this user? I see > > > that it works with exclusive locks because there can only be one. > > > </jra> > > > > So we agree that we can always resolve the proper lock token > > for an exclusive lock, the question now is how to handle a > > shared lock. I believe that the core of your misunderstanding > > is that you believe that when a shared lock is issued there > > will be multiple lock tokens for each owner of the shared > > lock. That is not the case. A shared lock has one and only > > one lock token assigned to it, regardless of the number of > > owners. Thus if you ask for a shared lock and you get back a > > successful result then you need only examine the body to find > > out which entry describes the shared lock you asked for (by > > definition there can be only one) and you know which one > > identifies your lock token. > > > > A further legitimate issue is how to identify your lock in > > the case where you have "lost" your memory. Again the owner > > header can be useful here. Shared locks are free to add > > multiple entries inside of owner so a client can always > > recognize its own owner entry. > > > > However I certainly believe that the world will be a better > > place when the standard principal identifier is agreed on by > > the ACL types. > > > > > <jra> > > > But DAV did specify Basic (with SSL) and Digest authorization > > > schemes must be > > > supported for security. They both provide the principal > > > userid. Couldn't this > > > be used? > > > > > > Next, the temporary hack couldn't be relied upon as not all > > > servers would > > > necessarily do it the same way. > > > > > > So I still don't see how an application can get the lock > > > token from the lock it > > > just requested. > > > </jra> > > > > > > > However SSL uses a completely different principal identifier > > (a certificate). Rather than try to shoe horn a "universal" > > principal identifier we decided to punt the problem to the ACL group. > > > > > > Yaron > > >
Received on Thursday, 16 July 1998 23:12:46 UTC