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