On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote:


<excerpt>

Julian Reschke wrote:


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

</excerpt>

I have no issues with the proposed text.



Cheers,

Elias



</excerpt>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:


---- 


<fontfamily><param>Courier</param> 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"</fontfamily>


----


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