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

From: [email-masked]
Date: Wed, 23 Nov 2005 18:02:17 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked]      [email-masked]
             Status|REOPENED                    |NEW

------- Additional Comments From [email-masked]  2005-11-23 18:02 -------
This bug is only assigned to me because the bug was reopened.  Assigning to
Julian to get confirmation of the consensus if that's at issue.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Nov 2005 08:00:06 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Nov 2005 17:34:35 +0100

> deprecate it. It will not make it illegal to use. It will not mean that

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Nov 2005 12:42:48 -0800

> discussed in the conference call, and rejected after long discussion.

More below on I am not arguing this one way or another but just want to
comment on IANA ....

> obsoletes RFC2518, and then wonder where the definition is gone.

Hmm, The IANA registration will say this is defined in 2518 and when people
look up 2518, they will find it there. That a later RFC (2518bis) updates
2518 no longer requires or suggests the use of this is OK. It's not like the
IANA registration is going to mark the opaquelocktoken as obsolete.

> strip it to minimal text (referring normatively to all the good stuff in
I don't remember exactly but I suspect you are correct that this is what the
folks on the call decided to put in the draft.

> statement would be sufficient.
Well if that is how folks want to fix this, great with me, I'm not arguing
it should be one way or another. I just wanted to make sure we were not
doing something because of a misunderstanding about IANA.