Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

<marianne.mohali@orange-ftgroup.com> Fri, 19 November 2010 15:31 UTC

Return-Path: <marianne.mohali@orange-ftgroup.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100453A6818 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 07:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT0A916msEei for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 07:31:37 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 37C023A6812 for <sipcore@ietf.org>; Fri, 19 Nov 2010 07:31:35 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E73B8B8008; Fri, 19 Nov 2010 16:33:14 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 267258B8002; Fri, 19 Nov 2010 16:33:14 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 16:32:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Nov 2010 16:32:19 +0100
Message-ID: <B11765B89737A7498AF63EA84EC9F5771EF0BF@ftrdmel1>
In-Reply-To: <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
Thread-Index: AcuCGi1fz/ZUOl2uSquWRR64hshQVgDkFe3A
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com><4CDCAC2F.2090904@nostrum.com> <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com>
From: <marianne.mohali@orange-ftgroup.com>
To: <HKaplan@acmepacket.com>, <adam@nostrum.com>
X-OriginalArrivalTime: 19 Nov 2010 15:32:21.0113 (UTC) FILETIME=[F4F1EE90:01CB87FE]
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 19 Nov 2010 15:31:38 -0000

Hi,

The objective of draft-mohali-sipcore-reason-extension-application is to know why and, more exactly, which application has influenced the session.
4244bis do not cover the need but is necessary to meet the need.

3 Use-cases for application-specific Reason:
1. in accordance with RFC3326, in a BYE or CANCEL to explain why a session has been released/canceled (general use-case) 
2. in accordance with 4244bis, escaped in the History-Info header (2 sub-cases)
    2.1. When the call is retargeted (R-URI changed), explaining that it is because of an application-specific internal decision.
    2.2. When there is no retargeting (R-URI unchanged), just to mark in the session history that this application has been invocated.

Work on RFC4244bis has to be concluded and this draft has a different scope. I don't see any interaction issues.

Why not finish RFC4244bis and use this draft both to enrich Reason header in general and to meet the needs using History-Info (already covering the use of Reason)?

Hadriel, you said "When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding" 
but the presented draft has really NO link with Call Forwarding (it is an other draft ;-).

Marianne

> -----Message d'origine-----
> De : sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan
> Envoyé : vendredi 12 novembre 2010 04:32
> À : Adam Roach
> Cc : sipcore@ietf.org WG
> Objet : Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
> 
> 
> I'd like a clarification. 
> You said:
> > "limit bis
> > changes to [those necessary to] satisfy target uri requirements."
> 
> 
> If by that you mean literally just to enable GRUU delivery, 
> we've already exceeded that.  You don't need an "mp" tag for 
> that, for example, afaict.
> 
> But I'm also not sure it's fair to be that restrictive in 
> your interpretation of what the bis can change.  Obviously we 
> have to constrain the scope, to actually get anywhere.
> But there's no point in publishing a document if it doesn't 
> solve a problem people actually have, just for the sake of 
> publishing a document. 
> 
> [soapbox]
> An RFC is not an end goal in itself - it's a means to an end, 
> namely for enabling interoperable protocols people will 
> *actually use*.
> [/soapbox]
> (I know we all agree on this, I'm just venting)
> 
> BTW, I'm not sure Marianne's use-case requires *ANY* 
> normative changes to rfc4244bis.  I was just commenting that 
> it would have been nice to really understand if rfc4244bis 
> did not cover it.  This is similar to Cullen's concern about 
> use-cases/application-examples.  We need to make sure the 
> changes we're making are actually useful. (I think they 
> *are*, or are as close as we can get, but that doesn't mean 
> we shouldn't go through the exercise... using H-I just isn't 
> that simple/obvious)
> 
> -hadriel
> 
> On Nov 11, 2010, at 9:53 PM, Adam Roach wrote:
> 
> > [as chair]
> > 
> > On 11/12/10 10:06 AM, Hadriel Kaplan wrote:
> >> When I read Marianne's draft, it sounds like the use-case 
> she's trying to cover is call-forwarding, for things like 
> voicemail systems to be able to detect/process.  So what 
> really confuses me is I thought one of the basic applications 
> 4244bis was trying to enable was exactly that one.  Right?  
> If it's not sufficient to achieve that, I think we've screwed 
> up somewhere... or at least need to make sure it's not 
> something we can fix in 4244bis, because now would be a 
> really good time to fix it.  :)
> > 
> > At IETF 75, when we were discussing the applicability of 
> 4244bis to the 
> > SIPCORE charter (as opposed to simply developing a new 
> document that was 
> > limited to describing how to use 4244 to deliver URI 
> parameters), one of 
> > the rather important points that was made was that we would 
> "limit bis 
> > changes to [those necessary to] satisfy target uri requirements."
> > 
> > If the RAI community at large wants to expand this to 
> include a general 
> > tune-up and/or kitchen-sinking of 4244, then we need to 
> figure out a way 
> > to put the SIPCORE milestone to rest and then send the rest of the 
> > changes to DISPATCH. I have no interest in letting this 
> milestone drag 
> > on as people come up with new things they'd like to see 
> added or changed.
> > 
> > /a
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>