Responses embedded below [MB]. Mary
-----Original Message----- From: Dean Willis [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 1:39 PM To: [email protected] Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 If I understood things correctly, during our discussion of resource priority header extensions at IETF 69, Robert Sparks proposed a procedural change for documents that define new SIP header fields. The current Guidelines for Authors of Extensions to the Session Initiation Protocol (RFC 4485) says: o The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension. Updating these tables (or is it just one table since it is split into two only for page-formatting reasons?) has been a contentious issue for some time. I've personally refused to do it for the last few drafts, since I got it wrong so many times before. Furthermore, this requirement is making the table(s) very, very wide, and introducing a draft-ordering problem. There's also the issue that everybody seems to interpret the table(s) differently, and that this has made for some very odd state machines when people try to code using the table(s). [MB] I agree that folks have problems interpreting the table and they tend to use their (wrong) interpretation rather than normative text. [/MB] And I'm sure Robert had even more compelling reasons as to why we should stop updating this table (or these tables) with every draft, though I fear that they weren't recorded effectively in the minutes. So I'd like to ask the group some questions: 1) Should we stop updating Table 2/3 in each draft? [MB] Yes. 2) If so, do we need an update to RFC 4485 to establish new guidelines? [MB] I don't think we need to update RFC 4485. As you mention previously, not all documents have been doing the table. I'd say to wait to update RFC 4485 until after you've got the alternative approach defined. [/MB] 3) Should we do something instead of updating Table 2/3, such as coming up with a new representation? [MB] I think we should wait until 3261bis before trying to come up with a new format. 4) If we have a new representation, should it be fully presented in each draft, or should it establish a new registry that each draft would update via IANA actions? Or somethinge else? [MB] If we do have a new representation, I don't think it needs to be fully represented in each draft. I think a registry would be far better. [/MB] -- Dean, Duly Appointed Co-Chair and Self-Appointed Pontificous Mediator _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
