Combined set of issues around lock tokens, examples, schemes

There are several issues that intersect around lock token requirements 
and examples.

  - Some examples use the "locktoken" scheme which is defined nowhere
  - The examples that use strings like "locktoken:a-lock-token" could be 
converted to "opaquelocktoken:a-lock-token" but then that would be an 
example of an invalid URI according to the rules of the 
"opaquelocktoken" scheme and we generally want to provide "best 
practices" examples (note, however, at the slight expense of 
readability)
  - In the meantime, RFC4122 appeared and makes it unnecessary for 
WebDAV to define how to do a UUID -- and we noticed that it defines a 
scheme as well (urn:uuid:)

What about resolving these by getting rid of the opaquelocktoken 
scheme?  The specification requirements would still make it legal to 
use any legal URI that was unique, so existing servers using 
"opaquelocktoken" would not be made non-compliant by this change.  It 
would simplify the spec by relying more on RFC4122 and defining one 
fewer new scheme and a bit of syntax associated with that scheme.

In summary a recommended (but not the only) form for lock tokens would 
be a UID in RFC4122 format, for example:
   "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

This seemed to make sense to Julian, Jim, Geoff and myself on the call 
today, so if we missed anything, or anybody has objections, please 
raise them.

Lisa

Received on Saturday, 22 October 2005 17:07:57 UTC