Re: [Bug 23] lock discovery vs shared locks

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