W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 16 Nov 2005 07:41:25 -0800
Message-Id: <9273f80ff101b5dd2d30a4582502e91b@osafoundation.org>
Cc: " webdav" <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
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
>  > >  > >
>  > >  >
>  > >  >
Received on Wednesday, 16 November 2005 15:41:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT