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

Jim Whitehead wrote:
>> 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 

Don't think so.

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

Yes, it is. However, I think we would be even more productive if text 
that is proposed actually gets discussed, instead of being ignored. 
Unless we want people to stop making proposals, if it starts to look 
like a waste of time.

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

Really? I'm no ABNF expert, but that seems to be incorrect. If it's 
true, we need similar text for the TimeType production in the Timeout 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>) header.

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

That's true; but it gives the raison d'être for this URI scheme. Once 
I'm being a bit more verbose :-)

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

See above.

 > ...

Best regards, and thanks fore reviewing both proposals.

Best regards, Julian

Received on Saturday, 29 October 2005 08:04:48 UTC