Re: [Bug 23] lock discovery vs shared locks

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
> >
> 
>