Re: [Bug 23] lock discovery vs shared locks

The last sentence is incorrect.  A lock token appears in a PROPFIND
lockdiscovery only if the server wishes to expose it.  I have argued
in the past that a sensible server should never expose a lock token in a
PROPFIND lockdiscovery, since it just allows a client of a user 
to incorrectly re-use a lock token still in use by another client
of that user.  So if we say anything, it should "A server SHOULD NOT
include a lock token in a PROPFIND lockdiscovery, since it introduces
the possibility of two clients of a given user overwriting each others
changes".

Cheers,
Geoff

Lisa wrote on 10/28/2005 06:48:52 PM:

> 
> On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote:
> 
> >
> > Julian Reschke wrote:
> >
> >> 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.
> >
> > I have no issues with the proposed text.
> >
> >
> > Cheers,
> > Elias
> >
> >
> It's not just the Lock-Token response header that shows the lock token 
> in response to LOCK, the token also appears in the lockdiscovery 
> property value, which is included in the body of the LOCK response. 
> There's a couple issues that the section on lock tokens should address:
>   - how lock tokens relate to locks (one and only one)
>   - who generates them, how, and requirements (uniqueness, that clients 
> MUST not interpret)
>   - where to get them (Lock-Token response, lockdiscovery property)
> 
> So here's the (work-in-progress) text for the whole section on lock 
> tokens, including my attempts to incorporate several bits of suggested 
> text in a readable order, while also being complete:
> 
> ----
> 
>   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 generated by the server. Clients MUST NOT attempt to interpret 
> lock tokens in any way.
> 
> Lock token URIs MUST be unique across all resources for all time. This 
> uniqueness constraint allows lock tokens to be submitted across 
> resources and servers without fear of confusion.
> 
> When a LOCK operation creates a new lock, the new lock token is 
> returned in the Lock-Token response header defined in Section 9.6 
> (Lock-Token Header), and also in the body of the response. Also note 
> that lock tokens MUST appear in the 'lockdiscovery' property of a 
> locked resource.
> 
> Submitting a lock token does not confer full privilege to use the lock 
> token or modify the locked resource. Anyone can find out anyone else's 
> lock token by performing lock discovery. Write access and other 
> privileges MUST be enforced through normal privilege or authentication 
> mechanisms, not based on the slight obscurity of lock token values.
> 
> Since lock tokens are unique, a client MAY submit a lock token in an If 
> header on a resource other than the one that returned it.
> 
> This specification encourages servers to create UUIDs for lock tokens, 
> and to use the URI form defined by Universal Unique Identifier (UUID) 
> [9]. However servers are free to use another valid URI so long as it 
> meets the uniqueness requirements. For example, a valid lock token 
> might be constructed using the "opaquelocktoken" scheme defined in an 
> appendix of this document.
> 
> Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 
> ----
> 
> There were some comments in a previous email from Julian about how the 
> lock token might not appear in the 'lockdiscovery' property if there 
> are multiple (shared) locks on the resource.  This statement doesn't 
> fit my understanding, so I haven't yet "fixed" that if I am indeed 
> wrong.  Doesn't the 'lockdiscovery' property include every active lock 
> on the resource and all their lock tokens?
> 
> Lisa