Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt
Andrew Allen <aallen@blackberry.com> Fri, 25 July 2014 14:06 UTC
Return-Path: <aallen@blackberry.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 B7FFB1B2965 for <sipcore@ietfa.amsl.com>; Fri, 25 Jul 2014 07:06:57 -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 hseZW4UzWogf for <sipcore@ietfa.amsl.com>; Fri, 25 Jul 2014 07:06:50 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8681B2974 for <sipcore@ietf.org>; Fri, 25 Jul 2014 07:05:29 -0700 (PDT)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Jul 2014 10:05:29 -0400
Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 10:05:28 -0400
From: Andrew Allen <aallen@blackberry.com>
To: Robert Sparks <rjsparks@nostrum.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt
Thread-Index: AQHPpTJ1moVVSWhzdkm0h/f6MW3FYZuw1bTg
Date: Fri, 25 Jul 2014 14:05:28 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD233991173A@XMB122CNC.rim.net>
References: <20140721222239.14965.50656.idtracker@ietfa.amsl.com> <53CD92F2.9060403@nostrum.com>
In-Reply-To: <53CD92F2.9060403@nostrum.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233991173AXMB122CNCrimnet_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3buLwgzOQojgaZRCsH1r-UIy_X4
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: Fri, 25 Jul 2014 14:06:58 -0000
Robert I have reviewed the new version and my comment is addressed now. Another issue though. In a discussion taking place on another SDO list some people are still taking the view that if they have defined a feature at both the UAC and UAS with a media feature tag that lets the UAC know the UAS supports the feature and the feature defines that the UAC will use norefersub to request that a subscription is not created by REFER and the UAS will accept the norefersub and not create a subscription then it’s OK to then send the REFER on an existing dialog. My view is this is a violation of protocol layering principles and could cause problems for implementations since SIP protocol layer functionality is now be coupled with the application semantics (i.e ths protocol layer has to know what the application behavior is going to be in order to know that no subscription will be created and therefore its OK to send the REFER on the pre-existing dialog). We need the refer-explicit-subscription mechanism in order to ensure that no implicit subscription is created. I welcome opinions on this? Andrew From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, July 21, 2014 6:24 PM 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