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

Robert Sparks <rjsparks@nostrum.com> Thu, 24 July 2014 21:38 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 3E2D71B28D1 for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 14:38:52 -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 gKd8PKR4_BoC for <sipcore@ietfa.amsl.com>; Thu, 24 Jul 2014 14:38:50 -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 D13A91A0033 for <sipcore@ietf.org>; Thu, 24 Jul 2014 14:38:49 -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 s6OLcgS2019259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 24 Jul 2014 16:38:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <53D17CE1.7070503@nostrum.com>
Date: Thu, 24 Jul 2014 17:38:41 -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: "DOLLY, MARTIN C" <md3135@att.com>, Ivo Sedlacek <ivo.sedlacek@ericsson.com>
References: <20140721222239.14965.50656.idtracker@ietfa.amsl.com> <53CD92F2.9060403@nostrum.com>, <39B5E4D390E9BD4890E2B31079006101127075C7@ESESSMB301.ericsson.se> <D500DF83-6C0D-41B1-8D2B-C7D8E13541A3@att.com>
In-Reply-To: <D500DF83-6C0D-41B1-8D2B-C7D8E13541A3@att.com>
Content-Type: multipart/alternative; boundary="------------010305000301010004070700"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kyhCXTWmHHb2cURaaiZ_89cYa7s
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
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:38:52 -0000

To be clear, this document points out that the currently published RFCs 
require GRUU in these situations.
The refer-explicitsub document provides a way to relax that.

RjS

On 7/24/14, 7:36 AM, DOLLY, MARTIN C wrote:
> We require GRUU, to which I have never seen in the field ( 
> deployments)...mmmm
>
> Martin Dolly
> Lead Member of Technical Staff
> Core Network & Gov't/Regulatory Standards
> AT&T Standards and Industry Alliances
> +1-609-903-3360
> md3135@att.com <mailto:md3135@att.com>
>
> On Jul 24, 2014, at 6:50 AM, "Ivo Sedlacek" <ivo.sedlacek@ericsson.com 
> <mailto:ivo.sedlacek@ericsson.com>> 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 attools.ietf.org  <http://tools.ietf.org>.
>>   
>> The IETF Secretariat
>>   
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org <mailto:sipcore@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sipcore