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

On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote:
>>
>
> 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.
>

Can you elaborate on the work and confusion?   Here's the whole set of 
text that would be removed:

     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.

Removing that text doesn't stop server implementors from using 
"opaquelocktoken" or make them non-compliant if they continue to use 
it.  I still recommend removing it now that we have the "urn:uuid:" 
namespace to recommend instead.

Lisa

Received on Sunday, 23 October 2005 23:04:09 UTC