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

I had assumed that removing opaquelocktoken from RFC2518bis would leave 
it registered because it would remain registered in RFC2518.  The BCP 
on registering schemes 
(ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) doesn't say much on 
obsoleting schemes in STD track documents.    The registration page 
doesn't show any info about obsoleted or historic schemes 
(http://www.iana.org/assignments/uri-schemes).  However, it does show 
several schemes (fax, modem) that were defined in an obsoleted RFC 
(2806) and not redefined in the new RFC (3966).

Thus I conclude that leaving mention of opaquelocktoken out of 
RFC2518bis would not lose its registration.  Does that change any 
opinions?

Lisa

On Oct 24, 2005, at 4:40 AM, Geoffrey M Clemm wrote:

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