Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3

From: Dean Willis <[email-masked]>
Date: Wed, 01 Aug 2007 13:39:03 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 01 Aug 2007 14:49:53 -0500

At 01:39 PM 8/1/2007, Dean Willis wrote:
>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?

If we choose #s 3 or 4 - we need to update RFC-4485

Doing #1 also requires an update to RFC-4485

meaning, unless we continue doing the table fill per draft, we need 
to update RFC-4485.

What would an alternative to table 2/3 be?

While I agree that supporting text in a particular doc doesn't always 
follow the doc's table 2/3 update, which should have been a 
requirement in RFC-4485 BTW, having that inconsistency can only cause 
inconsistent implementations.

I like the table, but feel we need to update RFC-4485 with consistent 
text supporting the table in each doc, if we keep the table (and the 
RFC-4485 requirement in Dean's original message).

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 1 Aug 2007 14:51:12 -0500

Responses embedded below [MB].

Mary

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 1:39 PM
To: [email-masked]
Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3

problem.

[MB] I agree that folks have problems interpreting the table and they
tend to use their (wrong) interpretation rather than normative text.
[/MB]

[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.   

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]

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 3 Aug 2007 12:48:45 +0200

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

> Sent: Wednesday, August 01, 2007 7:39 PM
> To: [email-masked]
> 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:
> 
> 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.
> 
> 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?
> 
> --
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip