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