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
- [sipcore] Fwd: New Version Notification for draft… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… OKUMURA Shinji
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… OKUMURA Shinji
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Adam Roach
- Re: [sipcore] Fwd: New Version Notification for d… Ivo Sedlacek