[Sipping] FW: Progressing draft-ietf-sipping-media-policy-dataset

"Worley, Dale R (Dale)" <dworley@avaya.com> Tue, 31 May 2011 19:34 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882D1E06A8; Tue, 31 May 2011 12:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.293
X-Spam-Level:
X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDOhDlveQdz9; Tue, 31 May 2011 12:34:18 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 84E87E0681; Tue, 31 May 2011 12:34:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYBAOlB5U3GmAcF/2dsb2JhbABTl06OU3erFQKbGYYeBJUqils
X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="249136622"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 May 2011 15:34:15 -0400
X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="628083057"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2011 15:34:15 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 31 May 2011 15:34:14 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "rai@ietf.org" <rai@ietf.org>, "sipping@ietf.org" <sipping@ietf.org>
Date: Tue, 31 May 2011 15:33:35 -0400
Thread-Topic: Progressing draft-ietf-sipping-media-policy-dataset
Thread-Index: AcwPqcuH73yCHEGRRY6ypTrFrigFEABRGpg1A7ba+HQ=
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222907E97C@DC-US1MBEX4.global.avaya.com>
References: <4DA40B86.5060905@ericsson.com>, <4DBFE77A.4010303@ericsson.com> <CD5674C3CD99574EBA7432465FC13C1B22246BD463@DC-US1MBEX4.global.avaya.com>, <4DC8EE2C.6010409@ericsson.com> <CD5674C3CD99574EBA7432465FC13C1B22246BD479@DC-US1MBEX4.global.avaya.com>, <4DCA3507.9020708@ericsson.com>, <CD5674C3CD99574EBA7432465FC13C1B22246BD491@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22246BD491@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Sipping] FW: Progressing draft-ietf-sipping-media-policy-dataset
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2011 19:34:18 -0000

From: Worley, Dale R (Dale)
Sent: Thursday, May 12, 2011 5:56 PM
To: Gonzalo Camarillo
Subject: RE: Progressing draft-ietf-sipping-media-policy-dataset

I just ran into something I had overlooked.  I've been taking the Abstract seriously when it says "It can be used to describe the properties of a specific SIP session or to define policies that are then applied to different SIP sessions."  That is, I've assumed that a session-policy is sort of a generic session-info whose <stream>s show what sorts of <stream>s are permitted in a conforming session-info.  This is what lead to the "implicit Boolean logic" message.

But when I look at the examples, I see that session-policy and session-info documents have completely different structure.  The session-policy is a collection of elements, each of which specifies a particular restriction on conforming session-info's.  And in particular, a session-policy does not contain stream elements.

A certain amount of my editing has been driven by this misconception, although I don't think it would take much work to reverse those edits.

The high-level question is whether we want to stay with the original scheme, where session-policy's have a distinctly different structure, or whether we want to go with my misconception, where session-policy are template session-info documents.

The original scheme would be easier for people to understand and thus to implement, but it has the limitation that one has to specifically define an element to represent every restriction that anyone will want to use.  The "new" scheme requires more abstract thought, but it automatically provides ways to make restrictions in every feature that can be expressed in a session-info, and so extensions of the data set require less design, and the processing code can be written in a more generic way.

What do you think?

Dale