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