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