Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]