Subject: [sipcore] Outbound: Flow-Timer only in REGISTER responses?

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 14:11:46 +0200

Hi,

One issue which was raised by Ya-Ching, when giving comments on the
keep-draft, was whether it is allowed to use the Flow-Timer header in
other messages than REGISTER responses?

The keep draft also uses it in INVITEs when keep-alive is negotiated.

The procedures in Outbound naturally only mention the Flow-Timer header
in REGISTER responses, but it is nowever specifically indicated that the
header is applicable for REGISTER responses only.

What seems to be missing from Outbound is the table we normally use to
define for which methods and message types a header is applicable.

Example:

Header field          where   proxy ACK BYE CAN INV OPT REG
------------------------------------------------------------------------
--------------------

Flow-Timer             18x                -      -       -      o     -
-
Flow-Timer             2xx                -      -       -      o     -
o  

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 11:46:19 -0500

On May 5, 2009, at 7:11 AM, Christer Holmberg wrote:

> keep-draft, was whether it is allowed to use the Flow-Timer header  
> in other messages than REGISTER responses?
>
> The procedures in Outbound naturally only mention the Flow-Timer  
> header in REGISTER responses, but it is nowever specifically  
> indicated that the header is applicable for REGISTER responses only.
>
> What seems to be missing from Outbound is the table we normally use  
> to define for which methods and message types a header is applicable.
>
> Example:
>
> --------------------------------------------------------------------------------------------
>
> Flow-Timer             18x                -      -       -       
> o     -       -
> Flow-Timer             2xx                -      -       -       
> o     -       o
>
That's probably because that table is the source of more confusion,  
IMHO, than anything else in the entire SIP specification family. It  
direly needs a retrofit, although I'm not sure that such is really  
possible: we add another column to the table for each method-type  
extension, such as SUB, NOT, INF, etc. This raises the question: If a  
new request type is specified, is it up to that request-type to fix  
"the table" for every header field, or do we need to revise the RC for  
each extension so as to add the new column to their tables?

Consequently, I greatly prefer to specify the behavior in text, using  
more general terms such as "requests" and "responses", which specific  
caveats around where such an extension header is meaningful, where it  
is forbidden, and where it is ignorable.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 May 2009 11:53:42 -0500

In outbound, the following should be added:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Flow-Timer             2xx      a    -   -   -   -   -   o

In Keep, the following: 

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Flow-Timer             18x      a    -   -   -   o   -   -
      Flow-Timer             2xx      a    -   -   -   o   -   o

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Tuesday, May 05, 2009 09:46
> To: Christer Holmberg
> Cc: SIPCORE
> Subject: Re: [sipcore] Outbound: Flow-Timer only in REGISTER 
> responses?
> 
> 
> > header in REGISTER responses, but it is nowever 
> specifically indicated 
> > that the header is applicable for REGISTER responses only.
> >
> That's probably because that table is the source of more 
> confusion, IMHO, than anything else in the entire SIP 
> specification family. It direly needs a retrofit, although 
> I'm not sure that such is really
> possible: we add another column to the table for each 
> method-type extension, such as SUB, NOT, INF, etc. This 
> raises the question: If a new request type is specified, is 
> it up to that request-type to fix "the table" for every 
> header field, or do we need to revise the RC for each 
> extension so as to add the new column to their tables?
> 
> Consequently, I greatly prefer to specify the behavior in 
> text, using more general terms such as "requests" and 
> "responses", which specific caveats around where such an 
> extension header is meaningful, where it is forbidden, and 
> where it is ignorable.
> 
> --
> Dean
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 May 2009 20:33:25 +0100

What about SUBSCRIBE and REFER requests and responses?

John 

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: 05 May 2009 17:54
> To: Dean Willis; Christer Holmberg
> Cc: SIPCORE

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 22:42:38 +0200

Hi, 

>What about SUBSCRIBE and REFER requests and responses?

I guess the mechanism could be useful also for SUB and REF dialogs.

Regards,

Christer

> > extension, such as SUB, NOT, INF, etc. This raises the question: If 
> > a new request type is specified, is it up to that request-type to 
> > fix "the table" for every header field, or do we need to revise the 
> > RC for each extension so as to add the new column to their tables?
> > 
> > Consequently, I greatly prefer to specify the behavior in text, 
> > using more general terms such as "requests" and "responses", which 
> > specific caveats around where such an extension header is 
> > meaningful, where it is forbidden, and where it is ignorable.
> > 
> > --
> > Dean
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 22:45:01 +0200

Hi, 

>>header in REGISTER responses, but it is nowever specifically indicated

more general terms such as "requests" and "responses", which specific
caveats around where such an extension header is meaningful, 
>where it is forbidden, and where it is ignorable.

I think the table is clear.

Maybe we could have a table on some website. Then it would be easy to
update it every time new methods and/or headers are added.

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 5 May 2009 17:04:22 -0500

I'm kind of in the middle here...

> I think the table is clear.

I think that conceptually it is, or should be, clear. Having it split over a 
large number of documents today makes it less clear :-(

> update it every time new methods and/or headers are added.

I think Dean's concern wasn't about the technology ("need more columns"), 
but about the review and approval process - if there's one table, and I 
create a new method or header, is it my job to fill in the entire table for 
the new row/column, or is it someone else's job (keeping in mind that I may 
not be the smartest person about everything that's in the table now - I 
might just be the smartest person about the method or header that I'm 
defining. If three of us define two rows and a column, how do we ensure that 
there's enough review for the new version of the table?

Stuff like that, I think. Or Dean can correct me.

Thanks,

Spencer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 08:02:38 +0200

Hi, 

>I think that conceptually it is, or should be, clear. Having 
>it split over a large number of documents today makes it less 
>clear :-(
>
> 
>I think Dean's concern wasn't about the technology ("need 
>more columns"), but about the review and approval process - 
>if there's one table, and I create a new method or header, is 
>it my job to fill in the entire table for the new row/column, 
>or is it someone else's job (keeping in mind that I may not 
>be the smartest person about everything that's in the table 
>now - I might just be the smartest person about the method or 
>header that I'm defining. If three of us define two rows and 
>a column, how do we ensure that there's enough review for the 
>new version of the table?

Like everything else related to your new method/header, whatever is to
be added to the table is discussed and agreed upon among the interested
parties.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 May 2009 09:19:21 -0400

I have never had a problem with the idea of capturing this info in a 
table of this sort. It isn't perfect (some nuances still require text 
descriptions) but still useful.

What is a problem about the table is maintaining it as extensions are 
made. Some things add new rows, and other things add new columns. We 
don't have a mechanism for getting it all together.

A web site might be useful, but we would need some way to maintain it 
normatively. This is similar to the kinds of registries that IANA keeps 
for us, but it is more complex than anything else I have seen them do. 
We could explore if they could maintain such a structure. But that would 
not obviate the RFCs that introduce changes from enumerating the impact 
of those changes on all previously defined rows and columns.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 May 2009 09:31:58 -0400

Spencer Dawkins wrote:
> I think that conceptually it is, or should be, clear. Having it split 
> over a large number of documents today makes it less clear :-(
> 
> I think Dean's concern wasn't about the technology ("need more 
> columns"), but about the review and approval process - if there's one 
> table, and I create a new method or header, is it my job to fill in the 
> entire table for the new row/column, or is it someone else's job 
> (keeping in mind that I may not be the smartest person about everything 
> that's in the table now - I might just be the smartest person about the 
> method or header that I'm defining. If three of us define two rows and a 
> column, how do we ensure that there's enough review for the new version 
> of the table?
> 

Those are valid concerns. But they are valid whether there is a table or 
not. If we expect text in the document to replace the table, then the 
text has to address the same concerns.

There is no way out - the interaction of a new method with all headers 
and responses must be considered, and the interaction of a new header or 
response with all methods must be considered.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 6 May 2009 09:55:17 -0500

I'm probably not being clear here.

> made. Some things add new rows, and other things add new columns. We don't 
> have a mechanism for getting it all together.
>
> for us, but it is more complex than anything else I have seen them do. We 
> could explore if they could maintain such a structure. But that would not 
> obviate the RFCs that introduce changes from enumerating the impact of 
> those changes on all previously defined rows and columns.

What I was saying was that we know how to write, and review, multiple 
extensions in parallel using Internet Drafts, but we don't actually have 
infrastructure in place to do this using a single table.

We certainly COULD create this table as an IANA registry - but that's not 
what we have now.

I think Paul and I are agreeing that this would involve a gatekeeper who is 
more involved, earlier in the process, with more authority to say "no", than 
IANA usually is today.

This isn't a technical concern, it's a process concern.

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 May 2009 13:24:04 -0400

Spencer,

I agree with you, but I'm saying a bit more:

Whether we have the table or not, the need for the gatekeeping is there. 
Trying to keep the table straight just *exposes* the need more clearly.
When new message types, headers, or return codes are defined, the info 
equivalent to updating the table is needed, whether in the form of a 
table update or not.

	Thanks,
	Paul

Spencer Dawkins wrote:
>> normatively. This is similar to the kinds of registries that IANA 
>> keeps for us, but it is more complex than anything else I have seen 
>> them do. We could explore if they could maintain such a structure. But 
>> that would not obviate the RFCs that introduce changes from 
>> enumerating the impact of those changes on all previously defined rows 
>> and columns.
> 
> We certainly COULD create this table as an IANA registry - but that's 
> not what we have now.
> 
> I think Paul and I are agreeing that this would involve a gatekeeper who 
> is more involved, earlier in the process, with more authority to say 
> "no", than IANA usually is today.
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 6 May 2009 13:29:15 -0500

We agree on the bit more as well. 

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Wed, 6 May 2009 13:37:35 -0500

On May 6, 2009, at 8:31 AM, Paul Kyzivat wrote:

>> I think that conceptually it is, or should be, clear. Having it  
>> split over a large number of documents today makes it less clear :-(
>> columns"), but about the review and approval process - if there's  
>> one table, and I create a new method or header, is it my job to  
>> fill in the entire table for the new row/column, or is it someone  
>> else's job (keeping in mind that I may not be the smartest person  
>> about everything that's in the table now - I might just be the  
>> smartest person about the method or header that I'm defining. If  
>> three of us define two rows and a column, how do we ensure that  
> Those are valid concerns. But they are valid whether there is a  
> table or not. If we expect text in the document to replace the  
> table, then the text has to address the same concerns.

I agree.

>
>
> There is no way out - the interaction of a new method with all  
> headers and responses must be considered, and the interaction of a  
> new header or response with all methods must be considered.
>

Although strictly from a documentation procedure: the current format  
wouldn't allow enough columns to appear in an internet-draft format to  
actually allow a new RFC to properly updated the table.

Plus, there are a lot of "conditionals" encoded in the table as  
additional row comments. I'm pretty sure that this confuses a lot of  
people -- I know it confuses me. Of course, it would help if we didn't  
keep defining special cases of application-affecting-transport logic  
like weird responses codes that Change the Rules.

Perhaps some sort of formal language construct could express the logic  
in some sort of fsm-verifiable way?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 20:56:15 +0200

>>and responses must be considered, and the interaction of a new header 
>>or response with all methods must be considered.
>
>

I guess we could start using the same mechanism as in 3GPP TS 24.229
Annex A. I am sure Keith would be more and happy to teach us :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 11 May 2009 15:14:48 +0200

I actually suggest that the tables are insufficient, and can only be regarded as a summary, therefore you do need to say precisely what is required in the text as well (from both a sending and receiving perspective). And I would note that what is being specified in these tables is actually dynamic, rather than some static conformance.

I do not believe a maintained web site is the way to go - our external registries are not there to specify behaviour, they are they to stop duplicate assignment of values. If we go this way, we immediately run into the problem that the normative behaviour is meant to be specified in RFCs, so we still have a maintenance problem.

What I do suggest that in the text where you specify the usage of headers within individual methods, you try and be as method unspecific as possible. If, for example, you are allowing a header to have meaning in REFER, INVITE and SUBSCRIBE requests because they are all dialog creating requests, then write the requirements as such. That way, if a new method is created, we can easily extrapolate this sort of text to the new method. Most of our header usage can be categorised fairly easily in this manner.

Francois, your proposed outbound change belongs on the SIP list as that is still PROTO shepherded there. Perhaps you can update with additions as I suggest above.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Wednesday, May 06, 2009 7:56 PM
> To: Dean Willis; Paul Kyzivat
> Cc: SIPCORE
> wouldn't allow enough columns to appear in an internet-draft 
> format to actually allow a new RFC to properly updated the table.
> >
> additional row comments. I'm pretty sure that this confuses a 
> lot of people -- I know it confuses me. Of course, it would 
> help if we didn't 
> I guess we could start using the same mechanism as in 3GPP TS 
> 24.229 Annex A. I am sure Keith would be more and happy to teach us :)
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
>