Re: Combined set of issues around lock tokens, examples, schemes

Lisa Dusseault wrote:
> 
> 
> There are several issues that intersect around lock token requirements 
> and examples.
> 
>  - Some examples use the "locktoken" scheme which is defined nowhere

Correct. The spec shouldn't do that.

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

Yes.

>  - 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:)

That's a change that's already in -- draft 07 doesn't specify how to 
generate UUIDs anymore.

Section 6.4 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.6.4>) 
  says:

--
In order to guarantee uniqueness across all resources for all time a 
server MAY use the Universal Unique Identifier (UUID) [9] mechanism to 
generate a lock token:

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly 
while still guaranteeing the lock token to be unique across all 
resources for all time. With the 'opaquelocktoken' scheme, the server 
MAY reuse a UUID with extension characters added. If the server does 
this then the algorithm generating the extensions MUST guarantee that 
the same extension will never be used twice with the associated UUID.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID 
production is the string representation of a UUID. Note that white space 
(LWS) is not allowed between elements of this production.

Extension = path ; path is defined in section 3.3 of RFC2396 [5]
--

Besides fixing the obvious editorial problems here (ABNF examples and 
spec in the same paragraph), I don't see why we need to take out even more.

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

The "opaquelocktoken" scheme is defined in RFC2518. Existing servers use 
it and are unlikely to stop using it (unless there's a replacement that 
provides exactly the same sematics). If RFC2518bis is going to 
"obsolete" RFC2518, I think it needs to keep the scheme declaration. On 
the other hand, if it doesn't keep it, I'll probably submit that as a 
separate spec.

Again: if it ain't broke don't fix it. I don't see any benefit in 
removing it, but lots of additional work and confusion if we do.

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

It just happens to be a simple URN scheme that fulfills the requirements 
for lock tokens. RFC2518 always allowed different schemes, and we should 
not make the impression that this changed.

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

+1 on having valid lock tokens in examples
+1 on using urn:uuid URIs to do that
+1 on simplifying the definition of "opaquelocktoken" by simply 
referring to the UUID generation instructions in RFC4122 (already done 
in draft 07)
-1 on removing the definition of "opaquelocktoken"

Best regards, Julian

Received on Saturday, 22 October 2005 18:53:41 UTC