[Sipping] Design meeting for draft-ietf-sipping-profile-datasets
"Dale Worley" <dworley@nortel.com> Tue, 24 March 2009 22:45 UTC
Return-Path: <dworley@nortel.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9EA28C0D0 for <sipping@core3.amsl.com>; Tue, 24 Mar 2009 15:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.67
X-Spam-Level:
X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 zQIgudGI1yAs for <sipping@core3.amsl.com>; Tue, 24 Mar 2009 15:45:11 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 01FE43A6A1A for <sipping@ietf.org>; Tue, 24 Mar 2009 15:45:10 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2OMk0q05179 for <sipping@ietf.org>; Tue, 24 Mar 2009 22:46:00 GMT
Received: from [47.141.31.139] ([47.141.31.139]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 18:45:58 -0400
From: Dale Worley <dworley@nortel.com>
To: SIPPING <sipping@ietf.org>
Content-Type: text/plain
Organization: Nortel Networks
Date: Tue, 24 Mar 2009 18:45:57 -0400
Message-Id: <1237934757.443.10.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Mar 2009 22:45:58.0827 (UTC) FILETIME=[4CCB47B0:01C9ACD2]
Subject: [Sipping] Design meeting for draft-ietf-sipping-profile-datasets
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 24 Mar 2009 22:45:12 -0000
Now that I have taken over the editorship of draft-ietf-sipping-profile-datasets, I would like to have an informal face-to-face design meeting to discuss (or perhaps, to inform myself) regarding what seem to be open technical issues in that draft. Will people who are at the IETF and interested in this work please reply to me (privately) and give when they are available for a face-to-face meeting? Thanks, Dale Agenda: --- Should a profile schema include the merge rule? If so, how are they specified? --- Can a single UA load multiple datasets of the same type? (e.g., to configure multiple lines on a phone) --- Supporting range/set values, which involves (1) how do we specify the allowed value set, and (2) can we do so generically (i.e., providing a general range/set-of construction to be applied to a datum type to be specified later) --- Schema language to specify data ranges, i.e., XML Schema Language vs. Relax NG. But note that Relax NG seems to delegate atomic types to XML Schema Language. --- Versioning. Proposal: Extensions are done by constructing an extension profile namespace. Thus, an "extended" data is composed of 2 datasets, the unextended dataset and the extended one. This makes it clear what the fallback behaviors/values are, but means that values in the extension dataset may explicitly modify or override the base dataset. Or should we do it differently, by adding elements to a top-level XML element? --- Visibility/modifiability attribute --- Local modifiability (see Hutton review) This is an additional, local dataset! Needs to be handled as such. Unfortunately, there are both user and admin components to this dataset. --- draft-ietf-sipping-media-policy-dataset-07 as an example profile schema: Considerable parts of a session-policy aren't part of the dataset. I guess that they can be ignored. But that means that the schema should note that they are non-normative documentation.