Re: [Bug 23] lock discovery vs shared locks

Lisa Dusseault wrote:
> 
> 
> 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. 

Yes. But does this need to be stated here? The right place to state it 
are the definitions for the LOCK method and the DAV:lockdiscovery 
property. Why repeat it here?

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

I don't see any benefit of stating this here. What clients are 
interested in is how to get the lock token once they issues the LOCK, 
and the *only* correct answer to that is to use the response header.

Mentioning a different mechanism here would at least require to make 
statements about when it won't work (shared locks), leading to even more 
spec text & confusion.

> 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 

That reference seems to use the wrong title, the spec is called "A 
Universally Unique IDentifier (UUID) URN Namespace".

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

Example and text don't match.

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

Yes.

Best regards, Julian

Received on Saturday, 29 October 2005 08:39:50 UTC