Whatever we do here, we should recognise the prime requirement of what we need to specify.
All to often our procedures state what we do need to implement. This can either be specific to one method, or in some cases the procedures are rather unspecific as to which method they are referring to. Sometimes the table is our only reference as to what happens when it is used in a method that is not explicitly mentioned in the procedures. There is an issue of conformance here; if an implementor supports both the REFER extension, and the later xyz header field extension, but then does not support the interaction of the two (but rather treats it as an unknown header), is it conformant or not. In many cases we can only tell by the contents of the table. So it is my belief that we cannot just delete the table. If we wish to remove the table, we have to specify what would have otherwise have gone in the table in RFC 2119 language in the procedures, i.e. things like: The xyz header field MUST NOT be used in responses The xyz header field is not intended for use in the abc methods What the table is poor on is indicating things like whether the header field parameter is applicable only to the first request of a dialog or is also valid in a subsequent request and so on. So in summary, if we delete the table, we must lay down clear guidelines of what must appear in the procedures text to replace it. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 01, 2007 7: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). > > 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? > > 2) If so, do we need an update to RFC 4485 to establish new > guidelines? > > 3) Should we do something instead of updating Table 2/3, such > as coming up with a new representation? > > 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? > > -- > 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
