Hi Adam,
exactly, we want to avoid having a confusing IANA registry. It needs to
be crystal clear for the implementors who will check it at any point.
In any case, note that a few IPR disclosures on the INSIPID drafts are
being updated to reflect that they also apply to this draft. So, we will
need to wait in order to make a decision... in the mean time, it would
be great to get further input from more participants.
Thanks,
Gonzalo
On 13/09/2013 6:22 PM, Adam Roach wrote:
On 9/12/13 05:47, Gonzalo Camarillo wrote:
Therefore, this draft registers the Session-ID header field with the
IANA. The designated expert is reviewing this registration, per the
rules in RFC 5727.
Yes, I am, and the only reason I didn't rubberstamp this for
registration as soon as it hit my inbox is exactly the confusion that
having two documents that register the same header field is likely to
cause.
I've only been peripherally following the events in INSIPID, but I was
aware of the existence of a draft intended to document historical usage
as well as a separate standards-track document to publish a consensus
mechanism (possibly including some degree of backwards compatibility
with historical usage). Like Robert, I didn't expect the "historical
usage" document to perform any registration, and was quite confused when
the IANA approached me about doing so.
I don't have a really strong opinion about whether draft-kaplan creates
a new entry in IANA that is replaced by a reference to
draft-ietf-insipid when it is published (versus not registering
anything, and then having the WG consensus document perform the
registration). That's not to say that I don't have an opinion on the
topic; I just don't feel strongly enough about it to wrestle about it.
Here's what I do feel strongly about: whatever the plan of record needs
to be clearly recorded in a place that people will find it. If
draft-kaplan registers Session-ID, we need two changes to the existing
documents: First, draft-kaplan needs to be crystal clear about the plan
of record its section 10 (e.g., "This registration is intended to be
temporary, and should be removed when [draft-ietf-insipid-...] is
published.") Secondly, draft-ietf-insipid must clearly state that its
IANA registration *removes* the old reference and *completely* replaces
it with a pointer to the standards-track document.
The situation that I want to ensure cannot happen is an IANA-registered
SIP header field that points to two documents simultaneously, especially
if the ABNF is not absolutely identical between the two documents.
/a