Subject: [sipcore] Consensus Call: SIP Table 2

From: Adam Roach <[email-masked]>
Date: Tue, 30 Mar 2010 13:51:20 -0500

[as chair]

Last week, at the face-to-face meeting in Anaheim, the SIPCORE 
participants in attendance had a discussion regarding the future of 
Tables 2 and 3 in RFC 3261. A summary of the conversation, along with 
links to the presentations and an audio recording of the conversation, 
can be found in the minutes:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203

During that conversation, the chairs polled those present for support 
between two options:

   1. Produce an artifact stating that documents defining new header
      fields and methods define semantics in prose, and will no longer
      extend Table 2; or

   2. Produce an RFC that defines new procedures for adding elements to
      Table 2 as new header fields and methods are defined

Among those present, there was strong support for option 1. If you wish 
to raise an objection to this direction, please do so on the SIPCORE 
mailing list before April 15th.

Thank you.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 22:30:08 +0200

Hi,

Just to clarify: both alternatives will leave whatever is currently unclear as it is, and only for new header fields and methods would be make things clear (whatever mechanism we would use)?

And, couldn't alternative 1 result in lots of "defined semantics" - especially if we define a new method and may have to take a large number of header fields into consideration? Maybe you'll even end up with something that looks like Table 2...

Note that I am not objecting to option 1 - I just haven't been able to "picture" it yet :)

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 21:51
To: SIPCORE
Subject: [sipcore] Consensus Call: SIP Table 2

[as chair]

Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants in attendance had a discussion regarding the future of Tables 2 and 3 in RFC 3261. A summary of the conversation, along with links to the presentations and an audio recording of the conversation, can be found in the minutes:

During that conversation, the chairs polled those present for support between two options:

 1.  Produce an artifact stating that documents defining new header fields and methods define semantics in prose, and will no longer extend Table 2; or

 2.  Produce an RFC that defines new procedures for adding elements to Table 2 as new header fields and methods are defined

Among those present, there was strong support for option 1. If you wish to raise an objection to this direction, please do so on the SIPCORE mailing list before April 15th.

Thank you.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Mar 2010 16:38:57 -0500

On 3/31/10 3:30 PM, Christer Holmberg wrote:
> Just to clarify: both alternatives will leave whatever is currently 
> unclear as it is....
[as individual]

In truth, I don't think anything is particularly unclear -- it's just 
not documented the same way. The documents that didn't expand table 2 
while adding new header fields all have prose that describes when the 
header field can appear. (Yes, I know this, because I looked at every 
one of them when I did the table 2 expansion that appears in the slides).

[as chair]

But, yes, the consensus call only deals with actions as they apply to 
future documents -- such as RFC3265bis -- and does not address actions 
that would affect RFCs or any other documents that have already cleared 
IETF review.

> And, couldn't alternative 1 result in lots of "defined semantics" - 
> especially if we define a new method and may have to take a large 
> number of header fields into consideration? Maybe you'll even end up 
> with something that looks like Table 2...

[as individual again]

I don't think so. As Keith has pointed out, statements like "both header 
fields defined in this document can appear only in methods that create 
new dialogs" fill out entire swaths of the table all at once. They also 
have the pleasantly future-proof quality that we don't need to say 
anything specifically about the header fields when someone creates a new 
method. A simple evaluation of the new method's properties against the 
header fields' normative text makes the answer brilliantly clear.

/a

> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Roach
> *Sent:* 30. maaliskuuta 2010 21:51
> *To:* SIPCORE
> *Subject:* [sipcore] Consensus Call: SIP Table 2
>
> [as chair]
>
>    2. Produce an RFC that defines new procedures for adding elements
>       to Table 2 as new header fields and methods are defined
>
> Among those present, there was strong support for option 1. If you 
> wish to raise an objection to this direction, please do so on the 
> SIPCORE mailing list before April 15th.
>
> Thank you.
>
> /a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 08:45:11 +0200

Hi, 

>Just to clarify: both alternatives will leave whatever is currently unclear as it is....
>		
>
>[as individual]
>	
>In truth, I don't think anything is particularly unclear -- it's just not documented the same way. The documents that didn't expand table 2 while adding new header fields all have prose that 
>describes when the header field can appear. (Yes, I know this, because I looked at every one of them when I did the table 2 expansion that appears in the slides).
>
>So, you are saying that by reading the specs we would be able to complete the table you had put toghether?
>	
>	[as chair]
>	
>But, yes, the consensus call only deals with actions as they apply to future documents -- such as RFC3265bis -- and does not address actions that would affect RFCs or any other documents that 
>have already cleared IETF review. 
>	
>And, couldn't alternative 1 result in lots of "defined semantics" - especially if we define a new method and may have to take a large number of header fields into consideration? Maybe you'll 
>even end up with something that looks like Table 2...
>
>
>[as individual again]
>	
>I don't think so. As Keith has pointed out, statements like "both header fields defined in this document can appear only in methods that create new dialogs" fill out entire swaths of the table 
>all at once. They also have the pleasantly future-proof quality that we don't need to say anything specifically about the header fields when someone creates a new method. A simple evaluation of 
>the new method's properties against the header fields' normative text makes the answer brilliantly clear.

Sure. That is fine when you define new headers, and when you define new methods and need to cover those new headers.

But, when you define a new method, you still also need to consider all "old" existing header fields - for which we unfortunately do not have statements as those suggested by Keith.

Take 3265bis as an example, and assume you remove table 2. The text will of course describe the usage of header fields directly associated with SUB/NOT, eg. Allow-Events. But, how will you deal with all the other header fields that we have defined over the years? I am sure there are header fields that we do NOT need to cover, because they are associated with specific mechanisms (e.g. RSeq and RAck). But, there is a huge number of more "generic" header fields that somehow need to be covered.

Anyway, there is only one way to figure out: by doing the work :)

Regards,

Christer

		[as chair]

		

		
		Thank you.
		
		/a