Subject: Re: [sipcore] Consensus Call: SIP Table 2

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Apr 2010 15:24:27 +0200

There are essentially two potential parts of the work here:

-	Decide on the future documentation structure
-	work out how to deal with interactions with legacy specifications.

SIPCORE is being asked only to decide on the first of these at the moment.

As Adam says, most of the existing header field usage is fully defined. The problem exists with certain header fields where it appears a somewhat arbitrary analysis was given to the entries, and therefore the entries appear inconsistent. 

An example of this is in the RFC 3329 header fields, where I personally would expect the semantics of these headers to be dealt with before one looks at the method. That means they should appear in all methods, but you will see from RFC 3329 that the headers are not valid in PRACK.

With a set of documentation rules to follow, there are no legacy issues if a new header field is defined. It follows one of the proforma rules, or creates a new one.

There is a legacy issue if a new method is created, but it is a long while since we created a new method. Yes we hit the documentation issues with the update to INFO and event packages, but for existing headers we can just carry on with table 2 and 3 if we really need to. Or at that point we can choose to create a new specification that updates those RFCs that do define header fields. I would note however that that may well result in some technical change, due to perceived inconsistencies in the current definitions, as in the example indicated above.

At the moment I do not favour the existing table method of documentation.

I do favour a set of proforma rules that specifiers can choose from.

A couple of examples of these proforma rules would be something like:

"The use of the header field is optional in all requests that are expected to be exchanged end-to-end between UAs. Implementations of this extension MUST support reception of this header field in such requests."

"The use of the header field is optional in all requests that initiate a dialog, or are used outside of a dialog being created. Implementations of this extension MUST support reception of this header field in such requests."

I suspect we could deal with most of the current header field usage with about 10 or so such proforma rules, and I do not expect new header fields to create a substantial set of new ones.

These need to specify both use (mandatory/optional) and if it is not otherwise clear, support (mandatory/optional). The latter is missing from the existing tables.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Thursday, April 01, 2010 7:45 AM
> To: Adam Roach
> Cc: SIPCORE
> Subject: Re: [sipcore] Consensus Call: SIP Table 2
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> ________________________________
> 
> 		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:
> 		
> 		
> 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
> 		
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Apr 2010 07:08:04 +0200

Keith,

I do agree with what you are saying. I am not proposing another way forward - I simply had some issues/questions. But, we'll learn as we walk.

Instead of having text describing the proforma rules, maybe we should addopt Annex A from 3GPP TS 24.229 ;) 

Regards,

Christer

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: 1. huhtikuuta 2010 16:24
To: Christer Holmberg; Adam Roach
Cc: SIPCORE
Subject: RE: [sipcore] Consensus Call: SIP Table 2

regards

Keith

> 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).
> >
> address actions that would affect RFCs or any other documents that 
> have already cleared IETF review.
> >	
> large number of header fields into consideration? Maybe you'll even 
> end up with something that looks like Table 2...
> >
> >
> >[as individual again]
> >	
> 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.
> 
> 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.
> 
> 		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:
> 		
> 
> documents defining new header fields and methods define semantics in 
> prose, and will no longer extend Table 2; or
> 			
> 			
> 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: "Elwell, John" <[email-masked]>
Date: Tue, 6 Apr 2010 16:09:16 +0200

No objection.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 30 March 2010 19: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:

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: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 10:16:31 -0400

+1

Elwell, John wrote:
> No objection.
>  
> John
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Adam Roach
>     *Sent:* 30 March 2010 19:51
>     *To:* SIPCORE
>     *Subject:* [sipcore] Consensus Call: SIP Table 2
> 
>     [as chair]
> 
>     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:
> 
>        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 
> 
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 10:17:57 -0400

[this was as an individual]