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

Perhaps we could just mention opaquelocktoken in a "deprecated" section.
We can indicate there that "opaquelocktoken" is a registered IANA scheme
defined in 2518 (to remove any concerns about its loss of registration)
but that it has been deprecated in favor of urn:uuid.

This gets opaquelocktoken out of the main body of the text (I'm in favor
of anything we can do do simplify the main body of 2518bis), without
creating any confusion about the registration of the opaquelocktoken 
scheme.

Cheers,
Geoff

Julian wrote on 10/24/2005 03:40:15 AM:
> 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
>