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

Adam Roach <adam@nostrum.com> Tue, 29 July 2014 15:20 UTC

Return-Path: <adam@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 DD8EB1B297F for <sipcore@ietfa.amsl.com>; Tue, 29 Jul 2014 08:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 Mz1R0LEBjd40 for <sipcore@ietfa.amsl.com>; Tue, 29 Jul 2014 08:20:51 -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 4E2F81A02D2 for <sipcore@ietf.org>; Tue, 29 Jul 2014 08:18:58 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6TFIrx1041734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Jul 2014 10:18:54 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <53D7BB5D.5010402@nostrum.com>
Date: Tue, 29 Jul 2014 10:18:53 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Robert Sparks <rjsparks@nostrum.com>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se>
Content-Type: multipart/alternative; boundary="------------010202070003050206060107"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/UJQNfpSL5LqsREY04Ut_kkY801U
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, 29 Jul 2014 15:20:54 -0000

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