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

OKUMURA Shinji <ietf.shinji@gmail.com> Thu, 07 August 2014 04:38 UTC

Return-Path: <ietf.shinji@gmail.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 243921A0AAE for <sipcore@ietfa.amsl.com>; Wed, 6 Aug 2014 21:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 iv2WxdCHq4qD for <sipcore@ietfa.amsl.com>; Wed, 6 Aug 2014 21:38:14 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9186C1A0AA7 for <sipcore@ietf.org>; Wed, 6 Aug 2014 21:38:14 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ey11so4686553pad.38 for <sipcore@ietf.org>; Wed, 06 Aug 2014 21:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=Tqhk2j9Q9Fhv7upum7efWqaxdyPG3ClL2YGmoiYdfg8=; b=spUvaVZsCB4pVy5GkMxHAk/0O8gzNV0u/PyZlP8A3jZczQ4soo3RbZ3C7CGamVaq6R qrIxcHWsWaQh53pN7aBR+JbfypcqL7QZRYDAETIHS5rFsPBGpoZtp7sa6zlL9vY6cUwW mRg38gyjr+f36NUiEN7fXj4UtDCJ+jlZ5IS5GkifQQzujAs5LCeFsBlzl6MOy6mKvWSg YHOaxiEyApIIeHJgyDz90Nd6QqSN8AW4+urviK19RmQ25Kp5bZyqIrNjdiEqpfkouaYf xDFWszJ1HgCPEu2tLpqPcR/f8eSBKiPY87lE5tR8CdgWilYDPb/3n2SoJMbuJ1QZfV5q jqeQ==
X-Received: by 10.70.124.195 with SMTP id mk3mr15414987pdb.126.1407386294186; Wed, 06 Aug 2014 21:38:14 -0700 (PDT)
Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id gb1sm2887803pbd.76.2014.08.06.21.38.11 for <sipcore@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Aug 2014 21:38:12 -0700 (PDT)
From: OKUMURA Shinji <ietf.shinji@gmail.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 07 Aug 2014 13:38:03 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: HidemaruMail 6.01 (WinNT,601)
In-Reply-To: <53D6CC3D.4000005@nostrum.com>
References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com>
Message-Id: <FCCFB1F9605EB8ietf.shinji@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/W4c3IvKWB6nf7RXUyMjozjjhvrc
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: Thu, 07 Aug 2014 04:38:17 -0000

Hi,

>3.  Use of GRUU is mandatory
>
> Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to
> implement and use as the local target in the subscription created by
> the REFER request.

IIUC, RFC6665 requires only notifiers to implement GRUU.

> A user agent constructing any REFER that can result in an implicit
> subscription MUST populate its Contact header field with a GRUU.

Notifiers populate in Contact header of 2xx response for REFER
and NOTIFY request with a GRUU.

> As RFC6665 details, this is necessary to ensure that NOTIFY requests
> sent in the implicitly created subscription arrive at this user agent
> without creating a second usage inside an existing dialog.  Using the

RFC6665 details,
      Because GRUUs are guaranteed to route to a specific device, this
      ensures that the subscription will be routed to the same place as
      the established dialog.

NOTIFY request is sent in dialog, any GRUU is not necessary for
a notifier.

> "norefersub" option tag [RFC4488] does not change this requirement,
> even if used in a "Require" header field.  Even if the recipient
> supports the "norefersub" mechanism, and accepts the request with the
> option tag in the "Require" header field, it is allowed to return a
> "Refer-Sub" header field with a value of "true" in the response, and
> create an implicit subscription.

Because GRUU is used just to receive REFER request, "norefersub" option
is irrelevant.

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

But if notifier is not support GRUU, RFC6665 allosws for flexibility.

> A user agent constructing a REFER request that could result in an
> implicit subscription MUST build 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].

A simplest solution I think is to ignore section 4.5.1.
There is no problem in backward compatibility.

Or someone writes new draft that relaxes the GRUU requirement.

Regards,
Shinji

-------- Original Message --------
> Adam and I spent some time today editing to account for the discussion.
>We believe we covered all the concerns raised.
>
>The sentence in section 3 was getting a bit complex, so we split it up into 
>several.
>Here's what it was before splitting it up:
>
>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.
>
>You can see what it turned into by looking in the draft.
>
>RjS
>
>
>-------- Original Message -------- Subject: New Version Notification for 
>draft-sparks-sipcore-refer-clarifications-03.txt
> Date: Mon, 28 Jul 2014 15:16:04 -0700
> From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org
> To: Robert Sparks [a:mailto:rjs@nostrum.com]<rjs@nostrum.com>, "Adam Roach" 
>[a:mailto:adam@nostrum.com]<adam@nostrum.com>, Adam Roach [a:mailto:
>adam@nostrum.com]<adam@nostrum.com>, "Robert Sparks" [a:mailto:RjS@nostrum.
>com]<RjS@nostrum.com>
>
>
>A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt
>has been successfully submitted by Robert Sparks and posted to the
>IETF repository.
>
>Name:		draft-sparks-sipcore-refer-clarifications
>Revision:	03
>Title:		Clarifications for the use of REFER with RFC6665
>Document date:	2014-07-28
>Group:		Individual Submission
>Pages:		4
>URL:            [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-
>refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks-
>sipcore-refer-clarifications-03.txt
>Status:         [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-
>refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-
>refer-clarifications/
>Htmlized:       [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-
>clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-
>clarifications-03
>Diff:           [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-
>refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore
>-refer-clarifications-03
>
>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