Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Robert Sparks <rjsparks@nostrum.com> Tue, 12 August 2014 14:59 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 681C91A0917 for <sipcore@ietfa.amsl.com>; Tue, 12 Aug 2014 07:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wF2V6nlHFD_Z for <sipcore@ietfa.amsl.com>; Tue, 12 Aug 2014 07:59:32 -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 A96141A0914 for <sipcore@ietf.org>; Tue, 12 Aug 2014 07:59:32 -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 s7CExOp1089230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 12 Aug 2014 09:59:25 -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: <53EA2BCC.2080306@nostrum.com>
Date: Tue, 12 Aug 2014 09:59:24 -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: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Andrew Allen <aallen@blackberry.com>, Adam Roach <adam@nostrum.com>, "sipcore@ietf.org" <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>
In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se>
Content-Type: multipart/alternative; boundary="------------060902000507080802010908"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/R5CE2ADRl4Sir0ohS2XxZfFbj7Y
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 14:59:36 -0000

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. č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. č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
>