Re: [Sip] INFO Framework - one pakage per INFO

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 28 November 2008 17:38 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF99E3A69EE; Fri, 28 Nov 2008 09:38:31 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFE43A692B for <sip@core3.amsl.com>; Fri, 28 Nov 2008 09:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level:
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599]
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 oEKqWm7kukEx for <sip@core3.amsl.com>; Fri, 28 Nov 2008 09:38:29 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DDF313A68A5 for <SIP@ietf.org>; Fri, 28 Nov 2008 09:38:28 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 28 Nov 2008 12:36:56 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 28 Nov 2008 12:36:56 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Eric Burger <eburger@standardstrack.com>
Date: Fri, 28 Nov 2008 12:35:58 -0500
Thread-Topic: [Sip] INFO Framework - one pakage per INFO
Thread-Index: AclRXq4sWLTtyFgvSX2nz1sHJaAYQAAASqUQAAWxlQA=
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31374B1F09C@mail>
References: <94081CC4-F9BE-4651-BE3D-9D5CEDC3CA8D@standardstrack.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F98E@esealmw113.eemea.ericsson.se> <F779DAF0-507D-4BB0-BA8C-C687F1C7BB30@standardstrack.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F9E2@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF05C0F9E2@esealmw113.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: SIP List <SIP@ietf.org>
Subject: Re: [Sip] INFO Framework - one pakage per INFO
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I think I was one of the people at the meeting who argued against it, so I'll talk turkey:

INFO is in wide use today, and it works(!), with barely any interop problems.

IMHO, the requirements driving the INFO packages draft was to solve two specific problems with current INFO:
1) Negotiation/advertisement of INFO uses, so that a UA is not "surprised" when it gets an INFO, and we don't need system configuration for every UA we talk to for what it can do.  Configuration on a system-wide basis is one thing, but configuration per far-end is *really* bad.
2) Indication of what the use is for the INFO message that is sent, so that one can receive the INFO method without ambiguity as to its purpose.

Those are the only things that drove a new draft, AFAIK.  Anything else is basically gravy.

We also had consensus (I think) a while back that the only chance we have to make people use this draft instead of current INFO was to:
a) Keep it simple.
b) Keep it simple.
c) Keep it simple.

So ISTM we don't have room for gravy - we need to focus on slice of the pie that we care about.  We need to keep the weight off the draft by sticking to the meat of the problems being solved, without stuffing in extra capabilities and by skipping the extra portions.  If we pile on more features, and mash in scenarios not covered by current INFO, there's little chance current systems/implementers will digest this thing and we'll end up with a dead duck instead.  So I was one of the people that cried fowl at the last meeting, and suggested we scrape the extras off our plate so we can serve up a draft people can really swallow.  Otherwise they'll continue doing what they're doing now.  We can shop around for more features the day after the draft is done, by putting extras in packages - but having people buy into those is only possible if we make the base draft cheap to implement now.

-hadriel

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
> Christer Holmberg
> Sent: Friday, November 28, 2008 8:48 AM
>
> Hi,
>
> If there is no technical reason I don't see why we again shall make a
> restriction which we later may "suffer" from.
>
> Regards,
>
> Christer
>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip