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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Tue, 29 July 2014 14:52 UTC

Return-Path: <ivo.sedlacek@ericsson.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 19F5B1B2935 for <sipcore@ietfa.amsl.com>; Tue, 29 Jul 2014 07:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 TZTPSDE4MZV0 for <sipcore@ietfa.amsl.com>; Tue, 29 Jul 2014 07:52:24 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531F81A03C1 for <sipcore@ietf.org>; Tue, 29 Jul 2014 07:52:23 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-98-53d7b5255e89
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.D7.27520.525B7D35; Tue, 29 Jul 2014 16:52:21 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Tue, 29 Jul 2014 16:52:20 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.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-03.txt
Thread-Index: AQHPqrHlCVbutnWm4UGh+sd45/UiLpu3Exsg
Date: Tue, 29 Jul 2014 14:52:20 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se>
References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com>
In-Reply-To: <53D6CC3D.4000005@nostrum.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011270A76BESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvja7q1uvBBltWqFpcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjeP81loITdxkrvu+bwNzAeOc6YxcjJ4eE gInEnEdvoWwxiQv31rN1MXJxCAkcZZS4dGgrlLOEUWLBmW42kCo2AT2JiVuOsILYIgKBEgsn LWEBsYUFsiVWbtjFCBHPkej/3MIGYRtJXJ51GKyGRUBVYm3LZ2YQm1fAV6Jt9gawuJBAksS5 7e/AbE4BbYkXx+eB9TIKyEpc/dMLNpNZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rhK0k8WPD JRaI+nyJM4t/s0DsEpQ4OfMJywRGkVlIRs1CUjYLSdksRg6guKbE+l36ECWKElO6H7JD2BoS rXPmsiOLL2BkX8UoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFsHt/w22MH48rnjIUYBDkYl Ht4Hx68FC7EmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxpjH dretLa9/L2Y9eG/qVzNdfZdp9y1cU1TOLppWuJ5T8PHHC2cuL7Hhqa8Jsqn1Cr48s7pXnPOW hmbls2bfrTZqLYk8BxMeTpx746Wq2zzBznuFZg3PY8z5LkeFvTL9/PZ+acR6ttfFzUxh+RNu znsfnlgRmZI610/u8YGv9c1fzkyO+qDxWomlOCPRUIu5qDgRAJNE7LOOAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EEfqPsF_NYtdPjD7Wo0LCzvvArE
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.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: Tue, 29 Jul 2014 14:52:31 -0000

Hello,

thank you for the updated draft.

Changes in section 4 resolve the first ISSUE I raised. Thank you.

Changes in section 3 are improvement. However, there is one more situation when the draft requires UA to set Contact of INVITE request to GRUU, when the GRUU would actually NOT be needed.

Particularly, if a UA supports receiving and accepting REFER request, the UA can be willing to accept such REFER for some sessions only. E.g. the UA can have two types of sessions:
- Type_A sessions for which the UE is willing to accept corresponding out-of-dialog REFER; and
- Type_B sessions for which the UE is NOT willing to accept corresponding out-of-dialog REFER. Any received out-of-dialog REFER request corresponding to such session would be rejected.

For Type_A sessions, I agree that GRUU (or at least a URI with GRUU properties) in Contact of INVITE is needed.
For Type_B sessions, GRUU in Contact of INVITE is not needed. UA will anyway reject any received out-of-dialog REFER request corresponding to such session.

So, in other words, GRUU in Contact of INVITE is needed only if UA wishes to receive an out-of-dialog REFER and >>is will to accept<< such out-of-dialog REFER.

Thus, the text should state:


   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include
   a GRUU in the Contact header field of >>the<< INVITE request.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will never create a implicit subscription in response to a REFER
   (that is, those that will reject any REFER that might result in an
   implicit subscription) are exempted from this behavior.


Kind regards

Ivo Sedlacek





From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 29. července 2014 0:19
To: sipcore@ietf.org
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Adam and I spent some time today editing to account for the discussion.
We believe we covered all the concerns raised.

The sentence in section 3 was getting a bit complex, so we split it up into several.
Here's what it was before splitting it up:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

You can see what it turned into by looking in the draft.

RjS


-------- Original Message --------
Subject:

New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Date:

Mon, 28 Jul 2014 15:16:04 -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-03.txt

has been successfully submitted by Robert Sparks and posted to the

IETF repository.



Name:          draft-sparks-sipcore-refer-clarifications

Revision:      03

Title:         Clarifications for the use of REFER with RFC6665

Document date: 2014-07-28

Group:         Individual Submission

Pages:         4

URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt

Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/

Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03

Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03



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