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
