Re: [Bug 23] lock discovery vs shared locks

Sorry, I misread your message.  The text that I was objecting to was
the clauses:

> if there were a client bug, a crash, a LOCK reply "lost in the mail"

in:

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

but the text you were proposing was just:

>  "Anyone can
>   find out anyone else's lock token by performing lock discovery."

which is fine.  I'd prefer making that explicit (e.g. "A lock token 
discovered by a client via lock discovery SHOULD NOT be used by that
client for anything other than an UNLOCK request, even if the user
is authenticated as owning that lock"), but I don't insist that this
be added (as long as the converse is not added :-).

Cheers,
Geoff


Lisa Dusseault <lisa@osafoundation.org> wrote on 11/15/2005 10:59:10 PM:

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