RE: Locking questions

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