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

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

Received on Friday, 28 October 2005 19:13:38 UTC