Ok,
here's a procedural question.
I have made a proposal to resolve these issues, and in the conference
call we have sort-of agreed to that plan (for instance, keep
opaquelocktoken, but move it to an appendix).
The new draft posted by Lisa *also* does this, but it doesn't use the
text I proposed. In particular, it still refers to outdated documents.
If the working group wants people to propose ready-for-spec text, then I
think that text should either be used, or those you don't like it should
at least state what was wrong with it.
For the record, I proposed:
Appendix C. 'opaquelocktoken' URI Scheme
The 'opaquelocktoken' URI scheme defined below uses the Universal
Unique Identifier (UUID) mechanism ([9], Section 4) to easily
generate lock tokens fulfilling the uniqueness requirements stated in
Section 6.3.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
; UUID: see [RFC4122], Section 3.
; path: see [RFC3986], Section 3.3.
Note that the optional "path" postfix allows to generate many lock
tokens from a single URI, by appending an varying string such as a
sequence number.
Example:
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017
which is IMHO much better then the text we now got:
Appendix D. The opaquelocktoken scheme and URIs
The 'opaquelocktoken' URI scheme was defined in RFC2518 (and
registered by IANA) in order to create syntactically correct and
easy-to-generate URIs out of UUIDs, intended to be used as lock
tokens and to be unique across all resources for all time. This
scheme has been obsoleted by [9], but is re-defined here for clarity.
A server MAY generate one ore more UUIDs to use with the
'opaquelocktoken' scheme as lock tokens. A 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]
In particular:
- no, opaquelocktoken has *not* been obsoleted; it still does more that
urn:uuid does
- What is "A server MAY generate one ore more UUIDs to use with the
'opaquelocktoken' scheme as lock tokens." supposed to mean???
- "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." - that's by definition of the lock token uniqueness;
I'm not sure why it's repeated here.
- "OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; ..." --
just refer to the normative definition in RFC4122
- "Extension = path"... -- RFC2396 is obsoleted. Really :-)
Best regards, Julian