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 Wednesday, 15 July 1998 15:17:57 UTC