Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 31 July 2014 09:20 UTC
Return-Path: <christer.holmberg@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 6D52D1A05F5 for <sipcore@ietfa.amsl.com>; Thu, 31 Jul 2014 02:20:52 -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 zk4aSU-WWeFh for <sipcore@ietfa.amsl.com>; Thu, 31 Jul 2014 02:20:49 -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 DCD461A063F for <sipcore@ietf.org>; Thu, 31 Jul 2014 02:20:39 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-bb-53da0a65f956
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.5C.03739.56A0AD35; Thu, 31 Jul 2014 11:20:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 31 Jul 2014 11:20:37 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>, Andrew Allen <aallen@blackberry.com>, Adam Roach <adam@nostrum.com>, Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Thread-Index: AQHPqrHlM30uwpOqe0eZb2vEZAWOo5u3AnoAgAAHa4CAAZZfgIAAFnEAgAAk07A=
Date: Thu, 31 Jul 2014 09:20:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3DB6A4@ESESSMB209.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> <53D92314.6040607@nostrum.com>
In-Reply-To: <53D92314.6040607@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3DB6A4ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RjeN61awQfcPHov787YyWuz5u4jd 4tqcRjaLrz82sTmweMxqWMvusWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlrHl1kqXgw0Km ist/T7A2MC6ZxdTFyMEhIWAi8fODfRcjJ5ApJnHh3nq2LkYuDiGBo4wSd3btY4VwFjFKtLx/ CtbAJmAh0f1PGyQuInCIUeLEx3vsIN3CAtkSKzfsYgSxRQRyJPo/t7BB2H4SP7b2gdWwCKhK zLnwB8zmFfCVOLLgJdSC5UwSW5+eA2vmFNCW6Pu2lRXEZgQ66fupNUwgNrOAuMStJ/OZIE4V kFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1+RIvVr9hhVgmKHFy5hOWCYwis5CMmoWkbBaSsllA fzILaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eakl mxiBkXdwy2/dHYyrXzseYhTgYFTi4X2QdTNYiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw8jO7NGzLqBfzUj0xU0n8yV3xcysdO32zHhezsH5xNxBSP8O1 Q8d+F1OSj/RtQfHJluvuWOjMCrvJzPB1h1a/1J1v994+2NHr7KedP6MpX/hco0tQpL7i+qjp vx9ui3H9zNLqdOhcm/w8ZnHB5Of5/Idvnj72TqL9/7wD8+dv6OOc0laT3xSjxFKckWioxVxU nAgAapC7IJ0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sHupA5K7vf_OmjXOrZhOrLFuKTI
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 09:20:52 -0000
Hi Robert, I agree that we should not define new behaviour in this draft. However, I think your suggested text could be modified to say: “A UA that will accept an out-of-dialog REFER request needs 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 arrive at this UA. Future extensions [draft-sparks-sipcore-refer-explicitsub] might relax this requirement by defining a REFER request that cannot create an implicit subscription.” It does not introduce new functionality, as in-dialog REFERs can be sent without any extensions. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 30 July 2014 19:54 To: Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt On 7/30/14, 10:33 AM, Andrew Allen wrote: I have a general concern with the direction this is now going. I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet. 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)? No, _this_ document is not defining new behavior. It's only clarifying what's already defined. 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 FWIW, Accepting is the key word here. 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. This, and what you have below, is a discussion we definitely need to have as part of the extension document. It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_. My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist. There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension. So, lets go back to the slightly longer sentence that led to this: A UA that will accept a subscription-creating REFER request needs to include a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests related to any dialog created by the INVITE arrive at this UA. In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define. Let's remove that confusion. Here's a proposed replacement, taking Adam's sentence simplification into account: A UA that will accept a REFER request needs 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 arrive at this UA. Future extensions [draft-sparks-sipcore-refer-explicitsub] might relax this requirement by defining a REFER request that cannot create an implicit subscription. Unless I hear objection soon, I'll rev the draft with that content. 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