Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Robert Sparks <rjsparks@nostrum.com> Tue, 12 August 2014 19:19 UTC
Return-Path: <rjsparks@nostrum.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 6BF5B1A06D7 for <sipcore@ietfa.amsl.com>; Tue, 12 Aug 2014 12:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RP_MATCHES_RCVD=-0.668] 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 9y0Gwx11qvPd for <sipcore@ietfa.amsl.com>; Tue, 12 Aug 2014 12:19:08 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5BFE81A0661 for <sipcore@ietf.org>; Tue, 12 Aug 2014 12:19:08 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7CJJ6HT011456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for <sipcore@ietf.org>; Tue, 12 Aug 2014 14:19:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local
Message-ID: <53EA68AA.7060108@nostrum.com>
Date: Tue, 12 Aug 2014 14:19:06 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: sipcore@ietf.org
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> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com>
In-Reply-To: <53EA2BCC.2080306@nostrum.com>
Content-Type: multipart/alternative; boundary="------------020208000603000102080100"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/h4ZquuKNM0P4r4kW125ZyHRUFbc
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: Tue, 12 Aug 2014 19:19:15 -0000
The rev is up, and the diff is available at <http://www.ietf.org/rfcdiff?url1=draft-sparks-sipcore-refer-clarifications-03&difftype=--html&submit=Go!&url2=draft-sparks-sipcore-refer-clarifications-04> On 8/12/14, 9:59 AM, Robert Sparks wrote: > So, I think we're getting closer to the disconnect. > > Your posited UA is going to reject out-of-dialog refers (at least in > the context of a given dialog). > Is it going to reject all refers? If so, 3515 (updated by 6665) > doesn't apply to its behavior during this dialog. > So, I'm assuming you are specifically interested in the case where it > accepts in-dialog refers. > > If your UA provided a GRUU when it started the dialog, and the far end > is satisfying the requirements of 6665, it would not send you an > in-dialog REFER. It would be violating a MUST NOT to do so. > > If your UA did not provide a GRUU, it is (in the context of this > dialog) not satisfying the requirements of 6665. It's acting like a > pre-6665 implementation, at least in the context of that dialog. If > the far end is 6665 compliant, it has the option (as specified in 6665 > section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is > what you're trying to get the text to reflect. > > If the far end is not 6665 compliant, it's effectively two old > implementations talking to each other and this document doesn't apply. > > The text you're proposing (if I've got it right) is trying to say > "this UA is not using 6665 in the context of this dialog". > As long as it is behaving that way, this document does not apply, and > the tension comes from trying to talk about such things in this document. > > I also don't think you're really concerned about UAs that will decide, > when sending an INVITE request, that they're going to be 6665 > compliant on some and not some others. Let me know if I'm wrong - we > need to have a different conversation than what's below. > > Rather, I suspect you're concerned about a population of pre-6665 UAs > that always won't. The more interesting question is what 6665 capable > UAs do when _accepting_ offered INVITE dialogs where the peer has not > provided a GRUU. If they are 6665 compliant, they have the fallbacks > available to them from section 4.5.2 on accepting in dialog > subscriptions, but 6665 should discuss whether they should provide a > GRUU for their local contact in response to the INVITE, and it should > explicitly talk about all subscriptions in either direction falling > under 5.4.2. That's a job for the update to RFC 6665 that Adam has > signed up for, not this document. > > What this document _can_ do is speak more concretely and correctly in > terms of things that the document applies to. > The changes will touch a couple of the paragraphs in section 4, and I > think trying to follow the diffs in email is going to get dicey, so > I'll drop a revision of the draft with them so rfcdiff can help. > > RjS > > On 8/12/14, 3:52 AM, Ivo Sedlacek wrote: >> >> (extended with my answer on the question and the proposed draft text) >> >> Hello, >> >> There still seems to be misunderstanding. Let me state my issue in a >> different and more general way: >> >> If: >> >> - a UE supports receiving and accepting of out-of-dialog REFER >> request related to dialogs created by _some (but not all)_ INVITE >> requests; and >> >> - for _a particular INVITE request_, the UA rejects any out-of-dialog >> REFERs related to dialogs created by the particular INVITE request; >> >> should the UE be still mandated to put GRUU in the Contact of _the >> particular INVITE request_? If so, what will the GRUU be used for? >> >> Please note that the question above focuses solely on out-of-dialog >> REFERs. >> >> IMO, answer to the questions above is: >> >> The UE should not be mandated to put GRUU in Contact of the >> _particular INVITE request_, since any out-of-dialog REFER request >> related to any dialog created by the _particular INVITE request_is >> rejected. Thus, the GRUU does not provide any value. >> >> Therefore, the draft should state: >> >> ----------------------- >> >> A UA that will accept a subscription-creating REFER request >>related >> to a dialog of an INVITE request<< needs to include >> >> a GRUU as the Contact in >>the<< INVITE request to ensure >> out-of-dialog REFER requests >> >> related to any dialog created by the INVITE >>request<< arrive at >> this UA. >> >> ----------------------- >> >> Kind regards >> >> Ivo Sedlacek >> >> *From:*Robert Sparks [mailto:rjsparks@nostrum.com] >> *Sent:* 7. srpna 2014 19:55 >> *To:* Ivo Sedlacek; Andrew Allen; Adam Roach; sipcore@ietf.org >> <mailto:sipcore@ietf.org> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> I've spent quite some time trying to understand the push for the >> proposal below, and I really think there's confusion, so I'm going to >> try to step up a level and see if we can make progress there. >> >> A UA such as your proposed exception clause describes is simply not a >> compliant 6665 implementation which is what this clarification >> document is about. >> If it accepts in-dialog subscription creating REFERs it is following >> 3265, not 6665 - further it is violating a 6665 requirement. >> If it accepts no REFERs whatsoever, then it's not affected by this >> document. >> >> If the point of the wordsmithing is to make legacy implementations >> compliant with 6665, there's no way to succeed - they simply aren't. >> >> If that's not the point of the wordsmithing, what is? >> >> At the moment, I think what I sent below is still the right path forward. >> >> RjS >> >> >> On 8/1/14, 1:44 AM, Ivo Sedlacek wrote: >> >> Any comments on the proposal below? >> >> Kind regards >> >> Ivo Sedlacek >> >> 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.*From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf >> Of *Ivo Sedlacek >> *Sent:* 31. c(ervence 2014 9:26 >> *To:* Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org >> <mailto:sipcore@ietf.org> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> Hello, >> >> According to the draft, the purpose of GRUU in Contact of INVITE >> request to " >> ensures that out-of-dialog REFER requests corresponding to any >> resulting INVITE dialogs arrive at this UA." >> >> If a UA rejects any out-of-dialog REFER requests corresponding to >> any dialogs related to an INVITE request, then setting up GRUU in >> Contact of INVITE does not provide any purpose. >> >> This is true __regardless__ whether the UA supports and use the >> draft-sparks-sipcore-refer-explicitsub. >> >> See attached mail giving an example of UA having two types of >> sessions, Type_A transferrable by REFER, and Type_B not >> transferrable by REFER. >> >> Given that different standardization organization has defined so >> many enablers which can run on a single UA, I find it weird that >> one can guarantee that the above cannot occur. >> >> Thus, I hesitate to mandate an unnecessary requirement >> influencing possible existing UA implementations and I prefer to >> be explicit on the exception for usage of GRUU in Contact of >> INVITE request: >> >> >> >> 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.>>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request >> >> are exempted from including a GRUU in the Contact header field of the INVITE request.<<< >> >> Kind regards >> >> Ivo Sedlacek >> >> *From:*Robert Sparks [mailto:rjsparks@nostrum.com] >> *Sent:* 30. c(ervence 2014 18:54 >> *To:* Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org >> <mailto: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 mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore
- [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