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

[Roman Shpount <[e-mail]>]

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=
[e-mail]> wrote:

> 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.
>
> Thanks
> Samir Srivastava
> https://samirsrivastava.typepad.com/
>
> On 5/11/2020 at 9:25 PM, "Christer Holmberg" <christer.holmberg=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> I suggest changing the subject of this thread, because it is not specific
> to session timers.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *sipcore <[e-mail]> on behalf of Samir Srivastava
> <srivastava_samir=[e-mail]>
> *Date: *Monday, 11 May 2020 at 18.40
> *To: *Keith Drage <drageke=[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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
> https://samirsrivastava.typepad.com/
>
>
> On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=
> [e-mail]> 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
> <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
>
>
> On 10/05/2020 17:59, Paul Kyzivat wrote:
> > 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
> >>
> >>
> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
> >>     |     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.
> >
> > 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
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>