Re: [Bug 23] lock discovery vs shared locks

I agree with you, but isn't the client supposed to UNLOCK by using the 
lock token?  If so then how does it learn it... ?

Lisa

On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote:

>
> I can only repeat what I posted a few weeks ago ... a client should
> never steal a lock taken out by an earlier client by re-using the
> lock token of that earlier client ... it should do so by UNLOCK'ing
> the resource and requesting its own lock.  That way if the original
> lock owner is still alive or comes back to life, the earlier client's
> attempt to use the original lock token to update the resource will 
> fail,
> thus preventing the changes made by the later client from being 
> overwritten.
>
> So I object to the text in the current draft, because it encourages
> clients to do the wrong thing, and encourages servers to support 
> clients
> doing the wrong thing.
>
> Cheers,
> Geoff
>
>
> w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM:
>
>  >
>  > I'm still concerned about a possible inconsistency here.  Sorry if 
> I'm  
>  > being dense, but I thought that we had a previous consensus (a long 
>  
>  > time ago) that servers SHOULD provide lock tokens for all locks so 
> that  
>  > if there were a client bug, a crash, a LOCK reply "lost in the 
> mail",  
>  > or a need for an owner or administrator to remove somebody else's 
> stale  
>  > lock.  Some text currently in the draft to that extent:
>  >
>  >    "Anyone can
>  >     find out anyone else's lock token by performing lock discovery."
>  >
>  > So given that implies that lock discovery can find out all lock 
> tokens  
>  > (given permission), and that the lockdiscovery property is returned 
> in  
>  > the LOCK response body, doesn't that mean that the lock token is  
>  > returned both in the LOCK response headers (Lock-Token) and body?
>  >
>  > Also, we had previously discussed at an interop which is the 
> "right"  
>  > place to put the lock token and concluded that servers ought to put 
> the  
>  > token in both places because we found during interoperability 
> testing  
>  > that we had clients that looked in one place, and other clients 
> that  
>  > looked in the other, so we might as well continue supporting both.
>  >
>  > Lisa
>  >
>  > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
>  >
>  > >
>  > > For the record,
>  > >
>  > > I don't think that the recent discussion has brought up any new 
> points  
>  > > that need to be said here, so I'd like to again recommend to 
> close the  
>  > > issue with the following change (as seen in  
>  > > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
>  > > 0242.html>).
>  > >
>  > > Proposed resolution for  
>  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]
>  > >
>  > > NEW:
>  > >    A lock token is a type of state token, represented as a URI, 
> which
>  > >    identifies a particular lock.  Each lock has exactly one 
> unique lock
>  > >    token, which is returned upon a successful LOCK creation 
> operation  
>  > > in
>  > >    the "Lock-Token" response header defined in Section 9.6.
>  > >
>  > >
>  > > Best regards, Julian
>  > >
>  >
>  >