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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Fri, 25 July 2014 06:49 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 9AC6B1A854D for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 23:49:00 -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, 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 10u9_ZEL2LHk for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 23:48:57 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EC31ABB2A for <sipcore@ietf.org>; Thu, 24 Jul 2014 23:48:56 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-67-53d1fdd68208
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.8F.04090.6DDF1D35; Fri, 25 Jul 2014 08:48:54 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 08:48:53 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt
Thread-Index: AQHPp4dFr5uZtyabiE6DXPm510CXXJuwWMvw
Date: Fri, 25 Jul 2014 06:48:53 +0000
Message-ID: <39B5E4D390E9BD4890E2B3107900610112707C39@ESESSMB301.ericsson.se>
References: <20140721222239.14965.50656.idtracker@ietfa.amsl.com> <53CD92F2.9060403@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127075C7@ESESSMB301.ericsson.se> <53D17C3D.5050103@nostrum.com>
In-Reply-To: <53D17C3D.5050103@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.19]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112707C39ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje61vxeDDRb/ErS4NqeRzeLrj01s DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAldG16rZ7AW/jjJVTPt/iLWBccdepi5GTg4J AROJQ8vmsUPYYhIX7q1nA7GFBI4yStyaatXFyAVkL2GUeP22gxkkwSagJzFxyxFWEFtEIFBi 4aQlLCC2sEC2xKQPN9gh4jkSl2YegKoxkth9aTsjiM0ioCrx+ddVsDm8Ar4SBx+uZ4ZYcJxR YtGSd2CDOAW0JbpOvAQrYhSQlbj6pxesmVlAXOLWk/lQVwtILNlznhnCFpV4+fgfK4StKNH+ tAGqPl+id9V8VohlghInZz5hmcAoMgvJqFlIymYhKZvFyAEU15RYv0sfokRRYkr3Q3YIW0Oi dc5cdmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECY+vglt9WOxgPPnc8xCjAwajE w/ug8WKwEGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpg1PzS H/a6X5Tz3D0j3hfZ8mKXP8y+EVg2c8Ls11L/GpZN1F9ssFHi6uszt98EbWCpf39Fq6zOdVK+ /qTA38UT8j71SVgLG3IKVK5iWRd+23Duean6pc5CnluP8ner/FLYM//Z0tmmjA+1HczYXvYF 8z2df/Vb8oXtOutPcJ1awNQs32Uhfd/3rxJLcUaioRZzUXEiAF1tLhSOAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JMm1ZeDnAtyrtADa5cZ22Jos2lA
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.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: Fri, 25 Jul 2014 06:49:00 -0000

Thank you for taking my comment into account.

I identified one more issue:

ISSUE 2:

section 3 states:
------------------------
   A UA that supports receiving REFER needs to include a GRUU as a
   Contact in INVITE requests to ensure out-of-dialog REFER requests
   related to this dialog arrive at this UA.
------------------------

The above requirement is unnecessary in case the UA supports receiving only REFER requests sent within an existing dialog, for which the UA is certain that no implicit subscription will be created.

Moreover, the 2nd part of the sentence discusses "out-of-dialog REFER requests related to this dialog" while 1st part discusses just "REFER".

PROPOSAL 2:

The requirement should be modified e.g. as follows:

------------------------
   A UA that supports receiving an out-of-dialog REFER request related to a dialog created by an INVITE request needs to include a GRUU as a
   Contact in the INVITE request to ensure any out-of-dialog REFER requests
   related to a dialog created by the INVITE request arrive at this UA.
------------------------

Kind regards

Ivo Sedlacek


From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 24. července 2014 23:36
To: Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Yes - thanks for the catch, and sorry for not tweaking that already (should have waited until next week).
I'll send an update soon.

RjS
On 7/24/14, 6:50 AM, Ivo Sedlacek wrote:
Hello,

ISSUE:

section 4 states:
------------------------
4.  Dialog reuse is prohibited

   As a direct consequence of requiring the use of GRUU, and the
  requirements in section 4.5.2 of RFC6665, sending a REFER that might
   result in an additional dialog usage within any existing dialog is
   prohibited.

   >>>A user agent constructing a REFER request MUST built it as an out-of-
   dialog message as defined in [RFC3261].<<<  Thus, the REFER request will
   have no tag parameter in its To: header field.

   A user agent wishing to identify an existing dialog (such as for call
   transfer as defined in [RFC5589] MUST use the "Target-Dialog"
   extension defined in [RFC4538] to do so.

   >>>If a user agent can be certain that no implicit subscription will be
   created as a result of sending a REFER request (such as by requiring
   an extension that disallows any such subscription), the REFER request
   MAY be sent within an existing dialog.<<<  Such a REFER will be
   constructed with its Contact header field populated with the dialog's
   Local URI as specified in section 12 of [RFC3261].
------------------------

2nd paragraph of the section 4 states unconditional UA procedure (MUST built it as an out-of-dialog message).
4th paragraph of the section 4 states an option for the UA (If a user agent can be certain ...., the REFER request MAY be sent within an existing dialog).

It is not possible to create a UA which would use the option described in 4th paragraph and still be compliant to the statement in 2nd paragraph.

PROPOSAL:

The 2nd paragraph should be conditioned by a condition opposite to the one in the 4th paragraph.

I.e. 2nd paragraph should be conditioned by "Unless a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription),"

Kind regards

Ivo Sedlacek


From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 22. července 2014 0:24
To: sipcore@ietf.org<mailto:sipcore@ietf.org>
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

This fixed the missing slide 3 text.

RjS


-------- Original Message --------
Subject:

New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Date:

Mon, 21 Jul 2014 15:22:39 -0700

From:

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

To:

Robert Sparks <rjs@nostrum.com><mailto:rjs@nostrum.com>, "Adam Roach" <adam@nostrum.com><mailto:adam@nostrum.com>, Adam Roach <adam@nostrum.com><mailto:adam@nostrum.com>, "Robert Sparks" <RjS@nostrum.com><mailto:RjS@nostrum.com>



A new version of I-D, draft-sparks-sipcore-refer-clarifications-02.txt

has been successfully submitted by Robert Sparks and posted to the

IETF repository.



Name:          draft-sparks-sipcore-refer-clarifications

Revision:      02

Title:         Clarifications for the use of REFER with RFC6665

Document date: 2014-07-21

Group:         Individual Submission

Pages:         4

URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-02.txt

Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/

Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-02

Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-02



Abstract:

   An accepted SIP REFER method creates an implicit subscription using

   the SIP-Specific Event Notification Framework.  That framework was

   revised by RFC6665.  This document highlights the implications of the

   requirement changes in RFC6665, and updates the definition of the

   REFER method, RFC3515, to clarify and disambiguate the impact of

   those changes.









Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat