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