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

Samir Srivastava <srivastava_samir@hush.com> Tue, 12 May 2020 11:06 UTC

Return-Path: <srivastava_samir@hush.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26F63A0D7D for <sipcore@ietfa.amsl.com>; Tue, 12 May 2020 04:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDOLdZ4ll3Kx for <sipcore@ietfa.amsl.com>; Tue, 12 May 2020 04:06:02 -0700 (PDT)
Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E913A0D7B for <sipcore@ietf.org>; Tue, 12 May 2020 04:06:01 -0700 (PDT)
Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 88020E03AE for <sipcore@ietf.org>; Tue, 12 May 2020 11:06:01 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=jA6f2HZLgiVj2DBICbK594E+G8ljNTwfHhC2odGELSE=; b=PKtwIRywJNNQILV/b1eCr1r2E5EFsUW9g6Hnjy78oU/EeD1d6CrBriLav4gRVMVpbj0gdvk3AGHi/GKP4/ucUf+YslGiRaBdIc1p5CdOGem2OrsxgYtRtNP9XENiS9Z+z6Jhb9xPEfPHt2a0d/5Jhxb2QTgD/E0Tk8uzB1xpMWDFQwMg6YQ6CFFHS8mN+Q11nTJUgpfw8VAw9JJ/Avg94StpQHZxTFqQRenolEtVjan5R+E+pHzlJZ32gn+l+1ytodZpws7sZtCQk40BBnMW57ZRERMreCXzpf8w/4/10PP6NjNEPIgqtNrGtRbxSHYOuNKjuht2sBftT0FGM12+PA==
Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Tue, 12 May 2020 11:06:00 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 9497C2011C; Tue, 12 May 2020 11:06:00 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 12 May 2020 17:06:00 +0600
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, Keith Drage <drageke@ntlworld.com>, sipcore@ietf.org
From: Samir Srivastava <srivastava_samir@hush.com>
In-Reply-To: <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com>
References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com>
Content-Type: multipart/alternative; boundary="=_4c2ccc5a2e512cf1a214fe5f84640441"
Message-Id: <20200512110600.9497C2011C@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/MvFNuaDGTj0hiL07UGYFQx-A_Pw>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 11:06:04 -0000

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 , "sipcore@ietf.org" 
 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"  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
 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
 > sipcore@ietf.org
 > https://www.ietf.org/mailman/listinfo/sipcore
 _______________________________________________
 sipcore mailing list
 sipcore@ietf.org
 https://www.ietf.org/mailman/listinfo/sipcore