Subject: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 10 May 2020 19:12:35 +0600

Hi,
  The table mentioned in Section 4 in RFC 4028 does not contain
entries for REFER, PUBLISH and MESSAGE methods Below is the table from
Section 4
	  
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 
  |     Header   
|where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|   
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 
  |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | -
|    |               |     |     |   |   |   |   |   |   |   |   |   |
  |    |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | -
| - |    |               |     |     |   |   |   |   |   |   |   |   |
  |   |    |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o
| - | - |    |               |     |     |   |   |   |   |   |   |   |
  |   |   |    |Min-SE         | 422 |     | - | - | - | m | - | - | -
| m | - | - |   
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ 
They are not applicable for these, but it would have been better if it
is said categorically.
ThanksSamir Srivastava
https://samirsrivastava.typepad.com/

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 10 May 2020 13:35:48 +0000

Hi Samir,

Note that there is work ongoing to create a new version of the session-timer specification, so this is one thing that could be clarified in the new spec.

Regards,

Christer

________________________________
From: sipcore <[email-masked]> on behalf of Samir Srivastava <srivastava_samir=[email-masked]>
Sent: Sunday, May 10, 2020 4:12 PM
To: [email-masked] <[email-masked]>
Subject: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

Hi,

  The table mentioned in Section 4 in RFC 4028 does not contain entries for REFER, PUBLISH and MESSAGE methods Below is the table from Section 4

   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
   |     Header    |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
   |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - | - |
   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+

  They are not applicable for these, but it would have been better if it is said categorically.

Thanks
Samir Srivastava

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 May 2020 12:59:55 -0400

On 5/10/20 9:12 AM, Samir Srivastava wrote:
> Hi,
> 
>    The table mentioned in Section 4 in RFC 4028 does not contain entries 
> for REFER, PUBLISH and MESSAGE methods Below is the table from Section 4
> 
> 

IIRC, quite a long time ago it was decided that this table in 3261 was a 
bad idea, because it is essentially a summary of normative language in 
other sections of the document and is necessarily an approximation.

After that, other work that updates and extends 3261 has been 
inconsistent it whether it updates the table or not.

What we should be careful of is that the in progress update to session 
timers is clear, normatively and expositively,  one way or another.

	Thanks,
	Paul

---

From: Keith Drage <[email-masked]>
Date: Sun, 10 May 2020 22:29:20 +0100

I dont know whether we reached something we can formally describe as a 
decision, but the overall opion was that it should be the text that 
should normatively describe what the requirements were for the actions 
in respect of inclusion in messages. If these tables were included, they 
should be clearly described as informative.

Further, the normative text should be adequately worded to encompass the 
understanding what happened when new messages were invented - so rather 
than specifically listing messages, it should probably talk about 
messages that create a dialog, etc.

Keith

On 10/05/2020 17:59, Paul Kyzivat wrote:
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table 
>> from Section 4
>>
>>
> IIRC, quite a long time ago it was decided that this table in 3261 was 
> a bad idea, because it is essentially a summary of normative language 
> in other sections of the document and is necessarily an approximation.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 May 2020 17:57:45 -0400

> messages that create a dialog, etc.

Thanks Keith! I don't have a clear memory, but what you say is 
consistent with my vague recollection.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 May 2020 06:34:34 +0000

Correct. I think the idea to not use tables to begin with, unless there is a very good reason for doing so.

Regards,

Christer

________________________________
From: sipcore <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Monday, May 11, 2020 12:57 AM
To: [email-masked] <[email-masked]>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

        Thanks,
        Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 11 May 2020 21:39:42 +0600

Hi,
  Please find my replies Inline below prefixed with SS>>
ThanksSamir Srivastava 
https://samirsrivastava.typepad.com/
On 5/11/2020 at 2:59 AM, "Keith Drage"  wrote:I dont know whether we
reached something we can formally describe as a 
decision, but the overall opion was that it should be the text that 
should normatively describe what the requirements were for the actions

in respect of inclusion in messages. If these tables were included,
they 
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the
tabulated form. SIP Parser developers cannot be expected to know the
minute details of applicability of the messages and headers etc. SIP
architect in the vendor comapnies might be required to give the
headers and messages in the tabulated form to SIP Parser developers.
If we all agree in the tabulated form as SPEC Writers, it will be good
service to the community. What are the difficulties considered which
made us to deprecate the table format?

Further, the normative text should be adequately worded to encompass
the 
understanding what happened when new messages were invented - so
rather 
than specifically listing messages, it should probably talk about 
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ietf.org/html/rfc3515
          MESSAGE RFC https://tools.ietf.org/html/rfc3428

  They all were invented before RFC 4028. They were NOT developed
after Session Timers. So it is left because of mistake. 4028bis and
RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere.
SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined
in the table nowhere in text. If the added headers (MIN-SE,
SEssion-Expires are found in these message should be reject the
REQUEST or accept the by following "be lenient what one accepts". Some
guideline needs to be specified. 
  Developer of new method need to look each header, message etc in
their respective RFC. What one can specify for method foo for header
foobar in advance? 
Keith
>>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | -
| 
>> - |
>>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | -
| 
>> - |
>>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | -
| 
>> - |
>>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | -
| 
>> - |
>>
>>    They are not applicable for these, but it would have been better

>> if it is said categorically.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 May 2020 15:55:21 +0000

Hi,

I suggest changing the subject of this thread, because it is not specific to session timers.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Samir Srivastava <srivastava_samir=[email-masked]>
Date: Monday, 11 May 2020 at 18.40
To: Keith Drage <drageke=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

Hi,

Thanks
Samir Srivastava

On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=[email-masked]> wrote:
I dont know whether we reached something we can formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format?

  They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified.
  Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance?

Keith

---

From: Keith Drage <[email-masked]>
Date: Mon, 11 May 2020 17:01:45 +0100

Most header fields are included for a specific purpose entirely 
unassociated with what mesage it is in.

i.e. things like

-    included because this message creates a dialog

-    included because this message ends a dialog

-    included becases this message is the request in a transaction

-    included because this message responds to a transaction

-    included because I can include it in any request

etc.

Those concepts have existed since RFC 3261.

The exceptions tend to be header fields that are defined along with a 
MESSAGE to carry them, i.e. in the same RFC.

I am not suggesting the definers of new messages should not give due 
consideration, only that in most cases they will not need to add any 
extra requirements to their new RFC, because all the considerations 
could already be in the header field defining RFC.

Keith

P.S. I would note that you cannot go on the date of publication - many 
RFCs take years to get through publication request to published while 
others proceed quicker.

On 11/05/2020 16:39, Samir Srivastava wrote:
> On 5/11/2020 at 2:59 AM, "Keith Drage" 
> <drageke=[email-masked]> wrote:
>
>     tabulated form. SIP Parser developers cannot be expected to know
>     the minute details of applicability of the messages and headers
>     etc. SIP architect in the vendor comapnies might be required to
>     give the headers and messages in the tabulated form to SIP Parser
>     developers. If we all agree in the tabulated form as SPEC Writers,
>     it will be good service to the community. What are the
>     difficulties considered which made us to deprecate the table format?
>
>       They all were invented before RFC 4028.. They were NOT developed
>     after Session Timers. So it is left because of mistake. 4028bis
>     and RFC does not mention PUBLISH, REFER, MESSAGE in the text
>     anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are
>     only defined in the table nowhere in text. If the added headers
>     (MIN-SE, SEssion-Expires are found in these message should be
>     reject the REQUEST or accept the by following "be lenient what one
>     accepts". Some guideline needs to be specified.
>     their respective RFC. What one can specify for method foo for
>     header foobar in advance?
>
>
>
>
>     Keith
>
>
>     >>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o
>     | - |
>     >> - |
>     >>     |               |     |     |   |   |   |   | |   |   | |  
>     |   |
>     >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o
>     | - |
>     >> - |
>     >>     |               |     |     |   |   |   |   | |   |   | |  
>     |   |
>     >>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o
>     | - |
>     >> - |
>     >>     |               |     |     |   |   |   |   | |   |   | |  
>     |   |
>     >>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m
>     | - |
>     >> - |
>     >>

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 12 May 2020 16:54:29 +0600

Hi Keith Drage,
  The below does not answer reason for deprecating tabular format i.e.
what are things which cannot be captured in tabular format.
 ThanksSamir Srivastavahttps://samirsrivastava.typepad.com/
On 5/11/2020 at 9:32 PM, "Keith Drage"  wrote:                   

	i.e. things like 

	-    included becases this message is the request in a      
transaction     

	etc.     

	Those concepts have existed since RFC 3261.
	The exceptions tend to be header fields that are defined along      
with a MESSAGE to carry them, i.e. in the same RFC.     

	I am not suggesting the definers of new messages should not give     
 due consideration, only that in most cases they will not need to     
 add any extra requirements to their new RFC, because all the      
considerations could already be in the header field defining RFC.
	Keith     

	P.S. I would note that you cannot go on the date of publication -    
  many RFCs take years to get through publication request to      
published while others proceed quicker.     
          On 11/05/2020 16:39, Samir Srivastava       wrote:
                                 Hi,         
                    Please find my replies Inline below prefixed with
SS>>         
                  Thanks         Samir Srivastava 
           https://samirsrivastava.typepad.com/         
           On 5/11/2020 at 2:59 AM, "Keith Drage"            wrote:   
       I dont know             whether we reached something we can
formally describe as a 
             decision, but the overall opion was that it should be the
            text that 
             should normatively describe what the requirements were
for             the actions 
             in respect of inclusion in messages. If these tables were
            included, they 
             should be clearly described as informative.
             SS>> I am of the opinion that we need header, message    
        etc in the tabulated form. SIP Parser developers cannot be    
        expected to know the minute details of applicability of the   
         messages and headers etc. SIP architect in the vendor        
    comapnies might be required to give the headers and messages      
      in the tabulated form to SIP Parser developers. If we all       
     agree in the tabulated form as SPEC Writers, it will be good     
       service to the community. What are the difficulties            
considered which made us to deprecate the table format?
             Further, the normative text should be adequately worded
to             encompass the 
             understanding what happened when new messages were
invented             - so rather 
             than specifically listing messages, it should probably
talk             about 
             messages that create a dialog, etc.
             SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
                      REFER RFC https://tools.ietf.org/html/rfc3515
                       MESSAGE RFC https://tools.ietf.org/html/rfc3428
               They all were invented before RFC 4028.. They were NOT 
           developed after Session Timers. So it is left because of   
         mistake. 4028bis and RFC does not mention PUBLISH, REFER,    
        MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK,       
     CANCEL, REGISTER, OPTIONS are only defined in the table          
  nowhere in text. If the added headers (MIN-SE,            
SEssion-Expires are found in these message should be reject           
 the REQUEST or accept the by following "be lenient what one          
  accepts". Some guideline needs to be specified. 
               Developer of new method need to look each header,
message             etc in their respective RFC. What one can specify
for method             foo for header foobar in advance? 
             Keith
             >>     |Session-Expires|  R  | amr | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Session-Expires| 2xx | ar  | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Min-SE         |  R  | amr | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Min-SE         | 422 |     | - | - | - | m | -   
         | - | - | m | - | 
          
	_______________________________________________ sipcore mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 12 May 2020 17:06:00 +0600

Hi Christer,
  I am hoping that in the next version 4028bis, The Min-SE,
Session-Expires header field will have consideration for REFER,
PUBLISH, MESSAGE methods, in tabular format or in text. Tabular format
or text will depend on the agreement on another thread discussion
which is started today.
ThanksSamir Srivastavahttps://samirsrivastava.typepad.com/
On 5/11/2020 at 9:25 PM, "Christer Holmberg"  wrote:      

	Hi, 
	I suggest changing the subject of this thread, because it is not
specific to session timers. 
	Regards, 
	Christer 
	From: sipcore  on behalf of Samir Srivastava 
 Date: Monday, 11 May 2020 at 18.40
 To: Keith Drage , "[email-masked]" 
 Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH,
MESSAGE not defined   
	Hi,   
	  Please find my replies Inline below prefixed with SS>>   
	Thanks   

	Samir Srivastava 

	I dont know whether we reached something we can formally describe as
a 
 should normatively describe what the requirements were for the
actions 
 >>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o |
- | 
 >> - |
 >>     |               |     |     |   |   |   |   |   |   |   | |  
|   |
 >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o |
- | 
 >> - |
 >>     |               |     |     |   |   |   |   |   |   |   | |  
|   |
 >>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o |
- | 
 >> - |
 >>     |               |     |     |   |   |   |   |   |   |   | |  
|   |
 >>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m |
- |

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 May 2020 11:50:46 -0500

The executive summary is that there was strong consensus not to attempt 
to maintain Tables 2 and 3 in RFC 3261, and many of the reasons for not 
doing so have become even stronger as the protocol has grown. If you're 
interested in the details, you can find the mailing list discussion by 
reading the messages from February through April 2010 here:

https://mailarchive.ietf.org/arch/search/?q=%22table%202%22&f_list=sipcore

There was substantial discussion of the topic at the in-person meeting 
in Anaheim; you can listen to the audio recordings here:

http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore1.mp3
http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore2.mp3

...and examine the slides here:

https://www.ietf.org/proceedings/10mar/slides/sipcore-2.pdf

/a

On 5/12/2020 5:54 AM, Samir Srivastava wrote:
> On 5/11/2020 at 9:32 PM, "Keith Drage" 
>             SS>> I am of the opinion that we need header, message etc
>             in the tabulated form. SIP Parser developers cannot be
>             expected to know the minute details of applicability of
>             the messages and headers etc. SIP architect in the vendor
>             comapnies might be required to give the headers and
>             messages in the tabulated form to SIP Parser developers.
>             If we all agree in the tabulated form as SPEC Writers, it
>             will be good service to the community. What are the
>             SEssion-Expires are found in these message should be
>             reject the REQUEST or accept the by following "be lenient
>             what one accepts". Some guideline needs to be specified.
>             >>     |Session-Expires|  R  | amr | - | - | - | o | - | -
>             | - | o | - |
>             >> - |
>             >>     |               |     |     |   | |   |   |   |  
>             |   | |   |   |
>             >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | -
>             | - | o | - |
>             >> - |
>             >>     |               |     |     |   | |   |   |   |  
>             |   | |   |   |
>             >>     |Min-SE         |  R  | amr | - | - | - | o | - | -
>             | - | o | - |
>             >> - |
>             >>     |               |     |     |   | |   |   |   |  
>             |   | |   |   |
>             >>     |Min-SE         | 422 |     | - | - | - | m | - | -
>             | - | m | - |
>             >> - |
>             >>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 May 2020 17:30:49 -0400

Samir,

Most likely Min-SE and Session-Expires headers in  REFER, PUBLISH, MESSAGE
would be out of scope for 4028bis. So far there was an agreement to limit
the scope of 4028bis to fixing handling of multiple transactions which
modify Session-Expiration at the same time and associated race conditions.

Any other changes would need to go into another RFC.

P.S. Why would you put  Min-SE and Session-Expires into REFER, PUBLISH,
MESSAGE? These header fields are only defined for INVITE/UPDATE messages
and not applicable for any other messages.
_____________
Roman Shpount

On Tue, May 12, 2020 at 7:06 AM Samir Srivastava <srivastava_samir=
[email-masked]> wrote:

> Session-Expires header field will have consideration for REFER, PUBLISH,
> MESSAGE methods, in tabular format or in text. Tabular format or text will
> depend on the agreement on another thread discussion which is started today.
>
> Thanks
> Samir Srivastava
> On 5/11/2020 at 9:25 PM, "Christer Holmberg" <christer.holmberg=
> [email-masked]> wrote:
>
> Hi,
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Samir Srivastava
> <srivastava_samir=[email-masked]>
> *Date: *Monday, 11 May 2020 at 18.40
> *To: *Keith Drage <drageke=[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH,
> MESSAGE not defined
>
>
>
> Hi,
>
>
>
> SS>> I am of the opinion that we need header, message etc in the tabulated
> form. SIP Parser developers cannot be expected to know the minute details
> of applicability of the messages and headers etc. SIP architect in the
> vendor comapnies might be required to give the headers and messages in the
> tabulated form to SIP Parser developers. If we all agree in the tabulated
> form as SPEC Writers, it will be good service to the community. What are
> the difficulties considered which made us to deprecate the table format?
>
> <https://tools.ietf..org/html/rfc3903>         REFER RFC
> https://tools.ietf.org/html/rfc3515
>   They all were invented before RFC 4028.. They were NOT developed after
> Session Timers. So it is left because of mistake. 4028bis and RFC does not
> mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY,
> PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in
> text. If the added headers (MIN-SE, SEssion-Expires are found in these
> message should be reject the REQUEST or accept the by following "be lenient
>   Developer of new method need to look each header, message etc in their
> respective RFC. What one can specify for method foo for header foobar in
> advance?
>
>
>
>
> Keith
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 May 2020 17:45:45 -0400

On 5/12/20 5:30 PM, Roman Shpount wrote:
> Samir,
> 
> Most likely Min-SE and Session-Expires headers in  REFER, PUBLISH, 
> MESSAGE would be out of scope for 4028bis. So far there was an agreement 
> to limit the scope of 4028bis to fixing handling of multiple 
> transactions which modify Session-Expiration at the same time and 
> associated race conditions.
> 

Putting them in *these* messages would be nonsensical because they are 
neither dialog establishing nor dialog refreshing. OTOH, it would make 
perfect sense to use them in SUBSCRIBE/NOTIFY because they *are*. 
Session Timer is about maintaining the dialog. I would think it would be 
equally applicable to these kinds of dialog usages. But that is probably 
deserving of discussion.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 May 2020 17:57:10 -0400

On Tue, May 12, 2020 at 5:45 PM Paul Kyzivat <[email-masked]> wrote:

> OTOH, it would make perfect sense to use them in SUBSCRIBE/NOTIFY because
> they *are*.
SUBSCRIBE/NOTIFY messages have a mandatory built-in dialog expiration
support (Expires/Min-Expires headers), so Session Timer in these message
would be redundant. I've never seen anybody using Session Timers with SIP
Events, but as you have said this can be discussed.

Best Regards,
_____________
Roman Shpount

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 13 May 2020 11:43:06 +0600

In-line prefixed with SS>>
ThanksSamir Srivastavahttp://samirsrivastava.typepad.com
On 5/13/2020 at 3:15 AM, "Paul Kyzivat"  wrote:On 5/12/20 5:30 PM,

perfect sense to use them in SUBSCRIBE/NOTIFY because they *are*. 
Session Timer is about maintaining the dialog. I would think it would
be 
equally applicable to these kinds of dialog usages. But that is
probably 
deserving of discussion.

SS>>  There are other messages in the table for which these headers
are not applicable. On the same line mention these headers are not
applicable for REFER, PUBLISH, MESSAGE methods. Messages apart from
(re)Inv and UPD are only mentioned in the table in 4028bis and RFC
4028. 4028bis mentions in the table that these headers are not
applicable for SUBSCRIBE / NOTIFY also.  

 Thanks,
 Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 May 2020 01:53:32 -0400

On Wed, May 13, 2020 at 1:43 AM Samir Srivastava <[email-masked]>
wrote:

> There are other messages in the table for which these headers are not
> applicable. On the same line mention these headers are not applicable for
> REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are
> only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in
> the table that these headers are not applicable for SUBSCRIBE / NOTIFY
> also.

Samir,

Since this change is purely editorial, serves no real purpose, and does not
address any real implementation issues, it is out of scope for the 4028bis.

There is a good argument to be made, that that entire table should be
removed to avoid any future queries like this in the future, but since this
is editorial as well, it is likely out of scope too.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 May 2020 07:43:18 +0000

Hi,

Note that editorial changes ARE fine, if they are done in order to avoid confusion, or to clarify things. But, we are not going to do things that are against previously agreements (see Adam’s reply).

In the video I mentioned some things that need to be clarified, e.g. the meaning of “initial session refresh request” etc.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Wednesday, 13 May 2020 at 8.53
To: Samir Srivastava <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

On Wed, May 13, 2020 at 1:43 AM Samir Srivastava <[email-masked]<mailto:[email-masked]>> wrote:
There are other messages in the table for which these headers are not applicable. On the same line mention these headers are not applicable for REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in the table that these headers are not applicable for SUBSCRIBE / NOTIFY also.

Samir,

Since this change is purely editorial, serves no real purpose, and does not address any real implementation issues, it is out of scope for the 4028bis.

There is a good argument to be made, that that entire table should be removed to avoid any future queries like this in the future, but since this is editorial as well, it is likely out of scope too.

Best Regards,
_____________
Roman Shpount

---

From: Keith Drage <[email-masked]>
Date: Wed, 13 May 2020 13:25:23 +0100

To answer your question from my perspective (and others may have further 
reasons)

1)    Maintainability. Every new header field and every new message 
would require some representation of the table, which either needs to 
reproduce the entire table, or explain the extension part relates to the 
existing table. If the entire table is not reproduced, then obviously 
there is not just the RFC 3261 table, but every other table in every 
other specification. If the tables were also made normative, this would 
also raise the question of how many other specifications would need to 
be updated by creating a new specification with a table.

2)    Double specification. The tables are in themselves insufficient. 
In RFC 3261 we have tables, the notes to the tables, and the main text 
all providing data on the use of the headers. I hate double 
specification; right of the start of my standardisation career, in order 
to obtain consensus on a specification, we were forced to change the 
normative part of a specification to align with an incorrect informative 
annex. It is far better to state something clearly only once.

3)    Incomplete specification. The tables are insufficient to 
adequately define the usage. Reliance on the tables therefore encourages 
incomplete specification.

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 May 2020 08:45:55 -0400

Keith,

I agree with all your points. The only sticky issue is that 3261 
contains normative language about the table. This could be fixed in a 
bis, but I don't foresee a bis coming any time soon.

	Thanks,
	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 13 May 2020 19:50:45 +0600

Hi Paul,
  SUBSCRIBE / NOTIFY have headers Expires, Min-Expire to handle dialog
clearing. 
ThanksSamir Srivastava
http://samirsrivastava.typepad.com

On 5/13/2020 at 11:13 AM, "Samir Srivastava"  wrote:In-line prefixed
with SS>>
ThanksSamir Srivastavahttp://samirsrivastava.typepad.com
On 5/13/2020 at 3:15 AM, "Paul Kyzivat"  wrote:On 5/12/20 5:30 PM,

 Thanks,
 Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 May 2020 18:45:54 +0000

Hi,

Since RFC 4028 was published we got RFC 5057, which defines different “dialog usages”.

So, I guess we in 4028bis can clarify that the session-timer is for “invite usages”, and that the procedures apply for methods associated with such usages. That would exclude SUBSCRIBE, NOTIFY, REFER and PUBLISH.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Samir Srivastava <srivastava_samir=[email-masked]>
Date: Wednesday, 13 May 2020 at 16.51
To: Samir Srivastava <srivastava_samir=[email-masked]>, "[email-masked]" <[email-masked]>, Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

Hi Paul,

  SUBSCRIBE / NOTIFY have headers Expires, Min-Expire to handle dialog clearing.

Thanks
Samir Srivastava

On 5/13/2020 at 11:13 AM, "Samir Srivastava" <srivastava_samir=[email-masked]> wrote:
In-line prefixed with SS>>

Thanks
Samir Srivastava

On 5/13/2020 at 3:15 AM, "Paul Kyzivat" <[email-masked]> wrote:
On 5/12/20 5:30 PM, Roman Shpount wrote:
> P..S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH,

SS>>  There are other messages in the table for which these headers are not applicable. On the same line mention these headers are not applicable for REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in the table that these headers are not applicable for SUBSCRIBE / NOTIFY also.

Thanks,
Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 May 2020 14:25:15 -0500

> bis, but I don't foresee a bis coming any time soon. 

Yep. That's why the conclusion in 2010 was to stop maintaining it, but 
not to go back and try to "fix" it for existing documents. The 
normativity in 3261 is worse than it seems at first: there is behavior 
that is normatively specified in Tables 2 & 3, and nowhere else -- so 
any fix would involve going through the table with a fine-toothed comb 
and ensuring that everything is specified in prose before removing it.

/a

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 14 May 2020 18:03:51 +0600

Hi,
  4028bis should provide the changes done with respect to RFC 4028.
Like RFC 3261 provide changes done with respect 2543.
Thanks 
Samir Srivastava
http://samirsrivastava.typepad.com

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 May 2020 13:54:03 +0000

Hi,

I am not sure I understand what you mean by “provide the changes with respect to RFC 4028”.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Samir Srivastava <srivastava_samir=[email-masked]>
Date: Thursday, 14 May 2020 at 15.04
To: "[email-masked]" <[email-masked]>
Subject: [sipcore] Change log for 4028bis

Hi,

  4028bis should provide the changes done with respect to RFC 4028. Like RFC 3261 provide changes done with respect 2543.

Thanks

Samir Srivastava

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 14 May 2020 20:05:33 +0600

Hi,
  Suppose I support RFC 4028, And I want to support your new RFC which
is in bis form now. Instead of going through the  minute details of
your new RFC as a whole, I focus on the changes done in the new RFC
with respect to 4028. 
  I am looking something similar to Chapter 28 of RFC 3261. Where it
lists the details of changes done with respect earlier SIP RFC 2543.
  Thanks
   Samir Srivastava
   http://samirsrivastava.typepad.com
On 5/14/2020 at 7:24 PM, "Christer Holmberg"  wrote:      

	Hi, 
	I am not sure I understand what you mean by “provide the changes
with respect to RFC 4028”. 
	Regards, 
	Christer 
	From: sipcore  on behalf of Samir Srivastava 
 Date: Thursday, 14 May 2020 at 15.04
 To: "[email-masked]" 
 Subject: [sipcore] Change log for 4028bis   
	Hi,   
	  4028bis should provide the changes done with respect to RFC 4028.
Like RFC 3261 provide changes done with respect 2543.   
	Thanks    
	Samir Srivastava   
	http://samirsrivastava.typepad.com

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 May 2020 14:10:51 +0000

Hi,

> Suppose I support RFC 4028, And I want to support your new RFC which is in bis form now. Instead of going through the  minute
> details of your new RFC as a whole, I focus on the changes done in the new RFC with respect to 4028. 

The aim is to change as little as possible, but time will show how many changes we will have to do.

>  I am looking something similar to Chapter 28 of RFC 3261. Where it lists the details of changes done with respect earlier SIP RFC 2543.

We are going to list/describe the changes in 4028bis.

Regards,

Christer

On 5/14/2020 at 7:24 PM, "Christer Holmberg" <christer.holmberg=[email-masked]> wrote: 
Hi,

Regards,
 
Christer

Hi, 

Thanks 
 
Samir Srivastava

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 21 May 2020 23:11:43 +0600

Hi,
  Chapter 9, Para 3 states
	   Thus, a UAS SHOULD NOT trust the information in the "Call-Info"   
header field unless the SIP session between the entity inserting the  
 header field and the UAS is protected by TLS [RFC8446].
  What about protection from DTLS? There may be hops which may be
protected by IPSEC tunnel.
  BTW how many deployments of SIPS, we have??  We need to modify the
statement.
ThanksSamir Srivastava
https://samirsrivastava.typepad.com       -    End of Unfairness

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 May 2020 13:14:39 -0400

There is no SIP over DTLS.
_____________
Roman Shpount

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 21 May 2020 23:33:59 +0600

Hi,
Long time back when I wrote ciphersuite draft, I mention DTLS in SIP
too in the email discussion.IMHO SIPS No momentum, We need to take
this statement out.If we do not take this out, then mention DTLS here
and write one draft for SIP Over DTLS.
Thanks
Samir Srivastava

http://samirsrivastava.typepad.com    - End of unfairness
On 5/21/2020 at 10:45 PM, "Roman Shpount"  wrote:There is no SIP over
DTLS.
_____________
Roman Shpount

On Thu, May 21, 2020 at 1:11 PM Samir Srivastava  wrote:
Hi,
  Chapter 9, Para 3 states
	   Thus, a UAS SHOULD NOT trust the information in the "Call-Info"   
header field unless the SIP session between the entity inserting the  
 header field and the UAS is protected by TLS [RFC8446].
  What about protection from DTLS? There may be hops which may be
protected by IPSEC tunnel.
  BTW how many deployments of SIPS, we have??  We need to modify the
statement.
ThanksSamir Srivastava
https://samirsrivastava.typepad.com       -    End of
Unfairness_______________________________________________
 sipcore mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/sipcore

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 May 2020 13:43:32 -0400

Samir,

DTLS needs to be fixed first to allow multiplexing multiple DTLS
connections over the same source/destination address/port pairs. If this is
done, I am willing to write a SIP-over-DTLS draft.

Until DTLS multiplexing is added, SIP-over-DTLS is not very useful since it
cannot be used in a manner similar to SIP-over-UDP and provides no benefits
to SIPS (SIP-over-TLS).

I do agree that TLS sentence in draft-ietf-sipcore-callinfo-spam needs to
be relaxed and does not reflect common operating procedures for SIP with
telecom operators, which are SIP-over-UDP over private links or IPSEC, and
not SIPS over TLS. SIPS over TLS is mostly used to connect calls from
service providers to end users over public internet.

Best Regards,
_____________
Roman Shpount

On Thu, May 21, 2020 at 1:34 PM Samir Srivastava <[email-masked]>
wrote:

> Hi,
>
> Long time back when I wrote ciphersuite draft, I mention DTLS in SIP too
> in the email discussion.
> IMHO SIPS No momentum, We need to take this statement out.
> If we do not take this out, then mention DTLS here and write one draft for
> SIP Over DTLS.
>
> Thanks
>
> Samir Srivastava
>
>
> On 5/21/2020 at 10:45 PM, "Roman Shpount" <[email-masked]> wrote:
>