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

Robert Sparks <rjsparks@nostrum.com> Wed, 13 August 2014 15:42 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 3FF281A0891 for <sipcore@ietfa.amsl.com>; Wed, 13 Aug 2014 08:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.268
X-Spam-Level:
X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RP_MATCHES_RCVD=-0.668] autolearn=no
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 HvRVZ9A4NPRe for <sipcore@ietfa.amsl.com>; Wed, 13 Aug 2014 08:42:07 -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 32C091A03C9 for <sipcore@ietf.org>; Wed, 13 Aug 2014 08:42:07 -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 s7DFg1s6086350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 13 Aug 2014 10:42:02 -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: <53EB8749.5090306@nostrum.com>
Date: Wed, 13 Aug 2014 10:42:01 -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> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/KQ590jbZlLkIvK-1sqt7PrkegfQ
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: Wed, 13 Aug 2014 15:42:08 -0000

On 8/13/14, 10:03 AM, Ivo Sedlacek wrote:
> Hello,
>
>>>> 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 you meant REFERs related to dialogs created by the particular INVITE request, then:
>>> - the UA rejects any out-of-dialog REFERs related to dialogs created
>>> by the particular INVITE request as stated in the question below; and
>>> - the UA handles any in-dialog REFER received in a dialog created by the particular INVITE request according to RFC6665. The UA rejects any in-dialog REFER request that would result in an implicit subscription.
>> Is this back to norefersub? Is your argument that you can accept the refer because you're the potential notifier and you know you won't take the path of norefersub that would create a subscription? If so, we may have a box around what we need to cover. If not, say more.
> Could we focus on the next question (which seems to be the KEY question) and, after we solved it, return to this one?
I think you'll find they're the same question.
>
>>> If you also meant REFERs related to dialogs created by other INVITE request, then UA can accept or reject them within rules given by RFC6665.
>> No, I was talking the the context of a given dialog.
>>>> If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665.
>>>> ...
>>>> 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".
>>> Can you please quote the RFC6665 requirement which the UA does not satisfy?
>> The first sentence of 4.5.1.
>> The clarification that Adam has signed up for well shine the light on that.
>> If there is any potential for a UA to become a notifier for _any_ event package (not just refer, but think also dialog), it will need to provide a GRUU for any dialog it tries to enter.
> RFC6665, section 4.5.1, 1st sentence states:
>
> 	Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target.
>
> Isn't notifier a role taken in subscription, applicable only for the dialog of the subscription?
> The UA does not act as notifier in the dialogs created by the particular INVITE request.
Specifically the UA is deciding, before it enters a dialog, that it will 
not use SIP events for _any_ event package related to this dialog, and 
is deciding to effectively internally fork all messages for this dialog 
to an implementation that supports neither 3265 nor 6665, right?

 From a protocol perspective (inspecting the messages on the wire), from 
the far end, something that does that is indistinguishable from two UAs 
that have different capabilities and routing across intermediaries 
landed dialog-creating messages on the different UAs. (Andrew, this is 
the best model I've found for discussing the interoperability concern 
you've been expressing.)

That UA that doesn't support 3265 or 6665 (specifically, how the UA you 
posit is behaving for this dialog) is by definition unconcerned with 
what 3265 and 6665 say. It is effectively out-of-scope for _this_ 
document, EXCEPT potentially for the one case I ask about above.

>   
> Thus, in my reading, the requirement does not apply for the particular INVITE request.
> Or do I miss anything?
>
> Kind regards
>
> Ivo Sedlacek