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

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 19 November 2010 16:02 UTC

Return-Path: <mary.ietf.barnes@gmail.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 A3DF43A6860 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 08:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level:
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 k6XbKG6y9Nwy for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 08:02:11 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4F6A53A680B for <sipcore@ietf.org>; Fri, 19 Nov 2010 08:02:11 -0800 (PST)
Received: by gyb13 with SMTP id 13so24780gyb.31 for <sipcore@ietf.org>; Fri, 19 Nov 2010 08:03:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JRLJPt63c8x0a0kAZk4U3DyuaV5YTjnfUKypaWhSmZo=; b=HcrPIVSqYk2lNU34pP6hI06Hb+Q4gK5bnmHKOjrtFknRItvcaNh7/dyOqNomfCPcpp SYx3a7UUmzD+heHi+W6p4yoOk5w/ROyAG2sbarO05Jjro9t64W6+UuMk1fnr4nrV9q3R n0XQ0ZeRogf6fRK0mbcPizMkqfB0GJtrYtGt8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dY7asFhafLv7mU6ZjOGz/L3AQtTCzyHiRk0Rw/Nj8JPwBNvGsuhp6v0pEz/C514qB2 gXHxo8SbUlqChZj/QAcd92tJvYXvUAnrZ7VAjR12WUe2275ain9U4vy9KiHTMC8lCtyp atGs7avRgz7UTCzXOrNsehHENj4q35nLcFM4A=
MIME-Version: 1.0
Received: by 10.151.51.15 with SMTP id d15mr3953568ybk.33.1290182580745; Fri, 19 Nov 2010 08:03:00 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Fri, 19 Nov 2010 08:03:00 -0800 (PST)
In-Reply-To: <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com>
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CDCAC2F.2090904@nostrum.com> <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com>
Date: Fri, 19 Nov 2010 10:03:00 -0600
Message-ID: <AANLkTimaxuGASKdCN-NhX=Egw1VExxwSy5GmKPMD0cLr@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary=0015174c0e046bbca604956a0a65
Cc: "sipcore@ietf.org WG" <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 16:02:12 -0000

Response inline below [MB].

Mary.

On Thu, Nov 11, 2010 at 9:32 PM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote;wrote:

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

[MB] Correct, I also do not believe that Marianne's use cases require
normative changes to RFC 4244bis, which is really agnostic in terms of the
Reason header value.  I can certainly see that History-Info header provides
necessary functionality for the use case, however, the use cases also
require extensions to Reason header values that are normative.  For this
same reason, we are removing the sub-addressing use case since it requires
new functionality beyond what is provided by 4244bis.  [/MB]

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