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

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

I don't think the editor should have to defend every minor text  
change. In particular, I think some of Lisa's additions are good (and  
she caught one error in the ABNF that you missed). However, you did  
catch a few minor errors, and one case of overspecification. Gee,  
it's almost like when multiple people collaborate on a document, the  
final result is of higher quality :-)

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

I like this text, but I think Lisa does have some valuable  
contributions.

Lisa's note about LWS is necessary, since otherwise you could have  
any amount of LWS between "opaquelocktoken:" and UUID and [path].

I also generally like Lisa's new introduction sentence, since it  
provides a modicum of context for the appendix.

I'd tweak the introduction sentence slightly:

The 'opaquelocktoken' URI scheme can be used by servers to create  
syntactically correct and easy-to-generate URIs out of UUIDs,  
intended to be used as lock tokens, meeting the requirements for  
uniqueness across all resources for all time.

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

This is implicit in the ABNF definition for opaquelocktoken, and  
doesn't need to be stated.


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

For this section, I recommend:

OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
    ; UUID: see [RFC4122], Section 3.
    ; path: see [RFC3986], Section 3.3.
Note that white space (LWS) is not allowed between elements of this  
production.


> - no, opaquelocktoken has *not* been obsoleted; it still does more  
> that urn:uuid does
>

I agree.


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

I agree.

>
> - "OpaqueLockToken-URI = "opaquelocktoken:" UUID  
> [Extension]  ; ..." -- just refer to the normative definition in  
> RFC4122

I agree.

>
> - "Extension = path"... -- RFC2396 is obsoleted. Really :-)

I agree.

- Jim