Re: [Bug 23] lock discovery vs shared locks

I agree there's a fair argument for allowing servers not to put lock 
tokens in lockdiscovery all the time.  I can clarify the text there 
because there certainly isn't a consensus to require servers to do 
that.

We could, however, treat the LOCK (create lock) response slightly 
differently, and require that the body contains the lockdiscovery 
property *including* the new lock token -- a special case to handle 
those clients that had problems at Interop tests.

Lisa

On Nov 16, 2005, at 8:11 AM, Geoffrey M Clemm wrote:

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