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