Re: [Bug 23] lock discovery vs shared locks

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