Let's have a discussion to get up to speed on the I-D at 8-9am Thursday in Franciscan D. The Franciscan rooms are close to the breakfast in Yosemite foyer, and breakfast is put out by 7:45 even though it's only officially scheduled for 8. The agenda items I have so far are: --- 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. If there are any other important issues, please bring them to the meeting. Of course, this discussion will continue on the Sipping mailing list. See you tomorrow! Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
