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

Lisa Dusseault wrote:
> 
> 
> 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.

I thought we were working on obsoleting RFC2518. RFC2223 defines what 
this means:

---
Obsoletes

       To be used to refer to an earlier document that is replaced by
       this document.  This document contains either revised information,
       or else all of the same information plus some new information,
       however extensive or brief that new information is; i.e., this
       document can be used alone, without reference to the older
       document.
---

As far as I understand this means that there's a chance that the URI 
scheme "opaquelocktoken" will not be considered a registered URI scheme 
anymore if we remove it. I don't think it's worth that just to save 
something like 15 lines of text in the spec.

So before removing it, I'd prefer that someone gets a statement from 
IANA/IETF what this means for the registration status.

Regarding your question: people will be confused when opaquelocktoken 
isn't registered anymore. Additional work (ie, writing a separate RFC) 
will be required to fix this.

I'd also like to point out that opaquelocktoken has semantics that go 
beyond urn:uuid, so there are many cases where an implementor can't 
simply switch schemes.

So, again:

+1 on recommending urn:uuid
+1 on using it examples
+1 on simplifying the opaquelocktoken definition to rely on RFC4122 but
-1 on removing the scheme declaration

Best regards, Julian

Received on Monday, 24 October 2005 07:40:34 UTC