Re: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it

Cullen Jennings wrote:
> 
> I think the problem we are having here is a confusion about IANA and I think
> I can help resolve it. I believe we all are fine with the text in section 6.
> (If we are not, well then the rest of this may be mute).  Note this text
> does not stop someone from using opaquelocktoken URI.
> 
> Julian would like to make sure that the IANA registration of opaquelocktoken
> at http://www.iana.org/assignments/uri-schemes does not go away.
> 
> My recommendation is that you remove Apendix C from the draft and that you
> change the IANA consideration to say that this specification does not
> require any IANA actions.
> 
> This will not cause the opaquelocktoken to be removed from IANA. It will not
> deprecate it. It will not make it illegal to use. It will not mean that
> servers can't use it.
> 
> Cullen

Cullen,

this option (removing the URI scheme definition from the spec) was 
discussed in the conference call, and rejected after long discussion.

The problem here is that if RFC2518bis indeed "obsoletes" RFC2518, this 
will mean that the IANA registration will live in a spec that is marked 
"obsolete" in the RFC database. That is, people looking for the 
definition may first go to the RFC database, find out that RFCxxxx 
obsoletes RFC2518, and then wonder where the definition is gone.

The consensus I recall is that we keep the URI scheme registration, but 
strip it to minimal text (referring normatively to all the good stuff in 
the URN:UUID spec).

The only open issue left in draft 08 (mod. editorial questions) is that 
is says that the scheme was obsoleted. It wasn't, so just dropping the 
statement would be sufficient.

Best regards, Julian

Received on Thursday, 24 November 2005 16:36:05 UTC