Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt
Robert Sparks <rjsparks@nostrum.com> Thu, 24 July 2014 21:36 UTC
Return-Path: <rjsparks@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 00B131B2904 for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 14:36:06 -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 M9bQaswrfmfx for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 14:36:03 -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 84D471B28D1 for <sipcore@ietf.org>; Thu, 24 Jul 2014 14:36:03 -0700 (PDT)
Received: from dhcp-b1d0.meeting.ietf.org (dhcp-b1d0.meeting.ietf.org [31.133.177.208]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6OLZwJY019035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 24 Jul 2014 16:35:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <53D17C3D.5050103@nostrum.com>
Date: Thu, 24 Jul 2014 17:35:57 -0400
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <20140721222239.14965.50656.idtracker@ietfa.amsl.com> <53CD92F2.9060403@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127075C7@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127075C7@ESESSMB301.ericsson.se>
Content-Type: multipart/alternative; boundary="------------000604080300080202050905"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ZIGzzetHqb1NrIMGgPcG7iAgoe8
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: Thu, 24 Jul 2014 21:36:06 -0000
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 > *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 > >
- [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… DOLLY, MARTIN C
- Re: [sipcore] Fwd: New Version Notification for d… Robert Sparks
- 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… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- 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… Ivo Sedlacek
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- Re: [sipcore] Fwd: New Version Notification for d… Christer Holmberg
- Re: [sipcore] Fwd: New Version Notification for d… Andrew Allen
- 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