Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Ivo Sedlacek <ivo.sedlacek@ericsson.com> Thu, 31 July 2014 07:28 UTC
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A981A03DF for <sipcore@ietfa.amsl.com>; Thu, 31 Jul 2014 00:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 BiWy2scPE1Vt for <sipcore@ietfa.amsl.com>; Thu, 31 Jul 2014 00:28:21 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A751A0292 for <sipcore@ietf.org>; Thu, 31 Jul 2014 00:28:20 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-5d-53d9f01267b7
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 13.47.03739.210F9D35; Thu, 31 Jul 2014 09:28:19 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 31 Jul 2014 09:28:18 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Andrew Allen <aallen@blackberry.com>, Adam Roach <adam@nostrum.com>, Robert Sparks <rjsparks@nostrum.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZu3Zw8AgAAHa4CAAU4pgIABD2rw
Date: Thu, 31 Jul 2014 07:28:17 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011270BA03@ESESSMB301.ericsson.se>
References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <BBF5DDFE515C3946BC18D733B20DAD233991419A@XMB122CNC.rim.net>
In-Reply-To: <BBF5DDFE515C3946BC18D733B20DAD233991419A@XMB122CNC.rim.net>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011270BA03ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3Rlf4w81gg3VruCzuz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVcaatj6Xg00PG itefXjM2MP64zdjFyMkhIWAicax7MguELSZx4d56ti5GLg4hgaOMEk9W7WSHcJYwSrzvmcUG UsUmoCcxccsRVpCEiMA0RokH2z+ygiSEBbIlVm7YBTZWRCBHov9zC1ADB5DtJjF3gjlImEVA VeLil0tgJbwCvhITL/czQyxoY5LomNUNdgangKfE/r1/wWxGAVmJq396wRqYBcQlbj2ZzwRx qoDEkj3nmSFsUYmXj/+xQtiKElenL2eCqM+X+HT9BDvEMkGJkzOfsExgFJmFZNQsJGWzkJTN AjqbWUBTYv0ufYgSRYkp3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIy9g1t+6+5gXP3a8RCjAAejEg/vg6ybwUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgdFO+8Z2898XtOrF7mlonNUILP/Vtuy36LGIz1ZZ4kE6BiIf r+2xUEszMHW1KahzeN14N9jCO7JDKjj49UzVuoqFL5mbOwsa0jM977dusfC6UMIx9efFmS/d zn8o5eFeP+VeQu2EFSlTHN+5BAftX5PzcHaw4/TZN8uuH1tfnH75SD9vSF9LnBJLcUaioRZz UXEiALqbg2WeAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/BER-vjLUcD_EMU0-Qi0psNQ_wu4
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 31 Jul 2014 07:28:24 -0000
RFC3515 states: 2.4.2 Processing a REFER request ... If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer> From: Andrew Allen [mailto:aallen@blackberry.com] Sent: 30. července 2014 17:33 To: Adam Roach; Ivo Sedlacek; Robert Sparks; sipcore@ietf.org Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt I have a general concern with the direction this is now going. Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)? According to RFC 3515 2.4.4 Using SIP Events to Report the Results of the Reference The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference. Therefore the ability to create an implicit subscription when accepting a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC. If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn’t end up at a UAS that doesn’t support compliant RFC 3515 behavior and ends up having its REFER requests rejected. My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued. Andrew From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, July 29, 2014 11:19 AM To: Ivo Sedlacek; Robert Sparks; sipcore@ietf.org<mailto:sipcore@ietf.org> Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt On 7/29/14 09:52, Ivo Sedlacek wrote: Thus, the text should state: In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include a GRUU in the Contact header field of >>the<< INVITE request. This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs are routed to the correct user agent. UAs that will never create a implicit subscription in response to a REFER (that is, those that will reject any REFER that might result in an implicit subscription) are exempted from this behavior. I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing. Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases. So I'll counterpropose: In general, UAs that support receiving REFER requests need to include a GRUU in the Contact header field of all INVITE requests. This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs are routed to the correct user agent. UAs that will not create a implicit subscription in response to a REFER for the resulting dialog(s) -- that is, those that will reject a corresponding REFER that might result in an implicit subscription -- are exempted from this behavior. /a
- [sipcore] Fwd: New Version Notification for draft… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… OKUMURA Shinji
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… OKUMURA Shinji
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek