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 >