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