XCON WG IETF-64 Meeting XCON Framework Overview & Issues Vancouver, November 2005 XCON Framework Overview & Issues Editors: Mary Barnes (mary.barnes@nortel.com) Chris Boulton (cboulton@ubiquity.net) Orit Levin (oritl@microsoft.com)

Overview Updates since IETF-63 Summary of Open Issues Additional Work items Overview of CCP proposals Way Forward

Updates (-02) Primary changes involved refining and clarifying the terminology and editorial changes to improve readability and precision. Terminology changes: Moved terminology after the Overview section Slight modifications (simplifications) to many of the definitions including: Call control signaling, Conference identifier, conference instance (removed the separate section on this term in section 4), conference object. Added definitions for: Conference reservation, conference blueprint Removed use of “XCON” as qualifier and replaced with more specific terms such as “Centralized Conferencing”.

Updates (-02) Terminology changes (continued): Expanded detail on identifiers in an appendix, condensing the descriptions in the main body of the document. Removed use of the term “umbrella” with regards to the identifiers. Simplified the terminology in system realization section: Removed use of term conference occurrence. Removed incorrect references that implied that a conference blueprint was the same as a conference template.

Updates (-02) Cloning Tree model changes/clarifications: Added a bit of explanation as to the intent of the cloning tree model - it's not implementation binding, but rather to illustrate the data model and context for the protocol interactions. Removed the term copying altogether. Cloning is the model and the idea is that the cloned object contains data identical to the parent when it was created (whether it gets "copied" or whatever from the parent is an implementation issue). Introduce the blueprint concept in prior to its implied usage. Removed the usage of the term occurrence (which is just a child reservation).

Updates (-02) 6.4: Floor control section: Simplified the text relating framework defined identifiers to BFCP identifiers (removed bulleted list). Moved detail on security to security section. Added additional example in section 7, including conference creation. Security section: Divided into sub-sections and incorporated floor control details.

Updates (-02) - Issues resolved Conference policies: not explicitly addressed. Current text is consistent with WG agreement (at interim and discussed on list) that there is no separation of “policy” from the conference data itself: Policy uses ranges to control limits on values explicitly defined with the “conference object” Policy is based on simple list structures (i.e. a list (of clients) per type of data the listed clients have permission to manipulate). Policy in terms of read/write access to objects is an implementation detail – logically based on using the simple list structures. As mentioned in document, if there is a need in the future (none is foreseen for currently envisioned functionality), the specification of such is FFS.

Issue – DP4 DP4: XML Schema Structure – 2 approaches put forth: 1) Create a new namespace (e.g. common-conference-info or xcon-conference-info) incorporating all the conferencing elements needed to facilitate data manipulation protocols that operate on the conference object. 2) Use the conference-info namespace and schema in the sipping conferencing package and propose conference package extensions.

Issue – DP5 DP5: State and Policy Manipulation Protocol(s) Four protocols on the table: CPCP, CSCP, CCCP, CCMP CPCP – based on XCAP CSCP – based on BFCP CCCP – new protocol CCMP – based on SOAP

DP5: CCP Protocol – Overview of options Attribute CPCP CSCP CCCP Netconf CCMP Based on XML Yes. No (binary, but could use a converted XML schema) (WSDL – could be derived from XML) Existing Protocol Yes (XCAP) Yes (extends BFCP) No. Yes (uses SOAP) Event notification mechanism (although not shown in -03) (use SIP mechanism) Compact Efficient TBD Easy to Implement

Issue – DP5: State and Policy Manipulation Protocol No explicit requirements for the protocol. SIPPING conferencing requirements and scenarios define the scope. Potential derived requirements: Reuse existing protocol where possible? Same protocol for both common conference information and template? Could we make progress by abandoning or enforcing derived requirements? Additional discussion on Wed.

Additional work to complete Definitions for sidebar and whisper. Complete detail in section 7: Add detailed example for Sidebar section. Add additional examples: Include functionality such as private messages, etc. Add additional scenarios/flows to highlight how the XCON functional elements work together and more importantly how a UA interfaces to the elements to achieve the desired functionality.

New work identified by Framework The following additional items are identified as requiring further specification, in other documents, based upon the current discussion and concepts introduced in the framework: URI schemas for new conference object and conference user identifiers (using current text in the appendix) . Alternative proposal for Floor control based on templates (based on past WG discussions)?

Way Forward Need additional mailing list feedback on open issues. Once general direction on open issues is agreed, should be able to complete Framework document.