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