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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Wed, 30 July 2014 12:25 UTC

Return-Path: <ivo.sedlacek@ericsson.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 6F67B1A001B for <sipcore@ietfa.amsl.com>; Wed, 30 Jul 2014 05:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 FVgUjTntSbl8 for <sipcore@ietfa.amsl.com>; Wed, 30 Jul 2014 05:24:59 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9DD1A000A for <sipcore@ietf.org>; Wed, 30 Jul 2014 05:24:58 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-45-53d8e4185b8b
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.AB.03739.814E8D35; Wed, 30 Jul 2014 14:24:56 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 14:24:56 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Adam Roach <adam@nostrum.com>, Robert Sparks <rjsparks@nostrum.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
Thread-Index: AQHPq0BrOQS4STe+wUmod32loOpPKpu4ht5A
Date: Wed, 30 Jul 2014 12:24:55 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011270B277@ESESSMB301.ericsson.se>
References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com>
In-Reply-To: <53D7BB5D.5010402@nostrum.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011270B277ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM+Jvja7EkxvBBjdfmVrs+buI3eLanEY2 i68/NrE5MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBlN2xYxFtyor9jU/JSpgXFBTRcj J4eEgInE4Qu7GCFsMYkL99azdTFycQgJHGWUuLl3ATOEs4RR4uvWA8wgVWwCehITtxxhBbFF BAokbjyfANYtLJAtsXIDxCQRgRyJ/s8tbBC2kcSkMz1gvSwCqhIvL79mAbF5BXwlrvfcg1pw HGjbGogEp4C2xK6/28AWMArISlz90ws2lFlAXOLWk/lMEKcKSCzZc54ZwhaVePn4H1A9B5Ct KLG8Xw6iPF/ia+c7qF2CEidnPmGZwCgyC8mkWUjKZiEpmwU0iVlAU2L9Ln2IEkWJKd0P2SFs DYnWOXPZkcUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMsINbfuvuYFz92vEQowAH oxIPb4LkjWAh1sSy4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5NLUgtii8qzUktPsTIxMEpBYyr 0r1KiS/6vaxezwp5Uep4/TyfWWbBTLN2mzzmddm/F8haLY74oKJZGlzJ8TjIZO4xn/fSCh+i k+5nG/7e8Cj/QJLCNcPpVlFNIbM8n54urZHhnvHvdMViP9srOxtOar7/eCr51ISZh04HNps+ EjvW4dEnpqWXfuGh9eeJTPnBBx36VSZI3lViKc5INNRiLipOBABlItpqkQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/cE9TJn57oYPy1WIAL38Y_13hRks
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, 30 Jul 2014 12:25:02 -0000

I understand the difficulty in formulation.

Would the following be acceptable?


   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 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: Adam Roach [mailto:adam@nostrum.com]
Sent: 29. července 2014 17:19
To: Ivo Sedlacek; Robert Sparks; 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