[sipcore] Question regarding use of single NOTIFY by RFC3515

<marianne.mohali@orange.com> Tue, 12 November 2013 18:47 UTC

Return-Path: <marianne.mohali@orange.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 C545F21E8093 for <sipcore@ietfa.amsl.com>; Tue, 12 Nov 2013 10:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abKpeZxKu-0C for <sipcore@ietfa.amsl.com>; Tue, 12 Nov 2013 10:47:22 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 12D1E11E8179 for <sipcore@ietf.org>; Tue, 12 Nov 2013 10:47:02 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3A7FC18C6D8; Tue, 12 Nov 2013 19:47:00 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1EDC44C1B8; Tue, 12 Nov 2013 19:47:00 +0100 (CET)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 19:47:00 +0100
From: marianne.mohali@orange.com
To: "sipcore@ietf.org" <sipcore@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Adam Roach <adam@nostrum.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [sipcore] Question regarding use of single NOTIFY by RFC3515
Thread-Index: Ac7f1KwAkR9dqfbKSsCdxBGQsOPfPA==
Date: Tue, 12 Nov 2013 18:46:59 +0000
Message-ID: <20314_1384282020_528277A4_20314_6458_1_8B970F90C584EA4E97D5BAAC9172DBB81764E1@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.12.100014
Subject: [sipcore] Question regarding use of single NOTIFY by RFC3515
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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 Nov 2013 18:47:30 -0000

Hi folks,

I have a question because IMO there is a kind of gap in RFC 3515 for the following particular use case:
RFC3515 makes the NOTIFY as mandatory to execute a REFER transaction (because of the implicit subscription).
To end this subscription it is expected to receive a NOTIFY with “Subscription-State: terminated” with a reason of "noresource".
The NOTIFY contains a body of type message/sipfrag and the status of the referred action (eg. 100 Trying, 200 OK…)
And in the meantime, agents accepting REFER and not wishing to hold subscription state can terminate the subscription with the initial NOTIFY. 
So finally, if an agent wants to end the subscription with this initial/final NOTIFY it should send a NOTIFY with a subscription-state “terminated”, a reason “noresource” and a 100 TRYING body. 

Could you confirm this analysis because it sound inconsistent to have a “final” NOTIFY with a 100 Trying body?

In the standard there is neither an example of a NOTIFY (100 TRYING) with a subscription-state “terminated” and a reason “noresource”, nor it is stated that it is forbidden…

Here are some extracts from RFC3515:

In 2.4.4
"The creation of a subscription as defined by [2] always results in an immediate NOTIFY."
[…]
“Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY.”

In 2.4.5
“If a NOTIFY is generated when the subscription state is pending, its body should consist only of a status line containing a response code of 100.”

In 2.4.7
“Each NOTIFY must contain a Subscription-State header field as defined in [2].  The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request).”

In 3.4
“As described in Section 2.4.7, the agent accepting the REFER will terminate the subscription when it reports the final result of the reference, indicating that termination in the Subscription-State header field.”


If you can give me your opinion.

Best Regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.