Re: [Bug 23] lock discovery vs shared locks

Some of the reasons why a server does not include the lock-token:
- all locks time-out in a reasonable period of time, and so no explicit 
unlock is needed/supported
- only the owner/admin is allowed to do the unlock, so the lock-token is 
only exposed to a client that is authenticated as being either the owner 
or the admin

Cheers,
Geoff

Lisa Dusseault <lisa@osafoundation.org> wrote on 11/16/2005 10:41:25 AM:

> That's fine with me too.  So does this mean that lockdiscovery property 
> (if readable) MUST contain all the locks and all their lock tokens? 
> Does that mean that in reply to a LOCK request which successfully 
> creates a new lock, the server MUST include the full lockdiscovery 
> property including not just the new lock but also other locks?
> 
> Lisa
> 
> On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote:
> 
> >
> > 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
> >  > >  > >
> >  > >  >
> >  > >  >