XCON Framework Overview & Issues Editors: Mary Barnes ( mary.barnes@nortel )

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

2. Overview • Updates since IETF-62 • Summary of Open Issues • Additional Work items • Overview of CCP proposals • Way Forward

3. Updates (-00) • Changes based on mailing list and IETF-62 discussions: • Editorial changes. • Added a new section to discuss Identifiers. • Add “Floor Information” as part of Common Conference Information and added “Floor Control” to Conference Template. • Added subsections discussing CSCP and Netconf as potential conference control protocols. • Added additional examples in section 7, including sidebars.

4. Updates (-00) • DP1: Referring to Sets of Meetings – text updated to reflect consensus: • Functionality is inherently supportable with “cloning tree“ structure and iCal (and should not impact current/planned iCal functionality). • Specifies that there is a single “time” from which other times are derived (subject to system considerations).

5. Updates (-00) • DP3: Querying templates – text updated to reflect consensus: • Need the ability to query a server about a particular template to retrieve a description, with 2 options: • XML Schema - as in current templates draft. This then supplies all relevant information that a client needs. • “Blueprint”, per current FW, which includes a template instantiation with customized values • Description is the same as the XML schema that is registered with IANA. • XCON server “advertises” what it supports to the client; Client retrieves the template from the server itself (and NOT from some centralized repository) • A client would need to query any templates that it doesn't understand THEN make a decision on compatibility. • Interface hints need to be included (e.g. per current template draft).

6. Updates (-01) • Primary changes involved refining and clarifying the terminology and editorial changes to improve readability and precision. • Terminology changes: • Slight modifications (simplifications) to Call (control) signalling, Conference Identifer, Conference Instance, Conference Object. • Renaming of term "Registered Template Definition" to "Registered Conference Document" (per agreement at interim meeting). • Clarified text in section 3 such that it doesn’t read as if the focus perform media mixing. • Re-arranged subsections of Identifier section, adding a Conference Object subsection with a diagram to clarify relationship amongst identifers. • Scheduling future conferences: added discussion of the concept of an infinite series. • Sidebar example: added more explicit references to XCON FW constructs.

7. Updates (-01) • Introduced SOAP as an option for the Conference Control Protocol.

8. Issue – DP4 • DP4: XML Schema Structure – 3 options proposed: • Option 1: Template at the top level, with Common Conference Information as a subsection. • Option 2: Common Conference Information at top • Option 3: Template and Common Conference Information are conveyed as two separate objects • Proposal: Need to work details of CCP proposal(s) to determine optimum approach.

9. Issue – DP5 • DP5: State and Policy Manipulation Protocol(s) • Past mailing list discussion converged to the point that the differentiation between syntactic and semantic is artificial and doesn’t resolve anything. • Proposal put forth that “ semantic model” can also support fundamental syntactic model (for data manipulations). • Four protocols on the table: CPCP, CSCP, CCCP, NetConf • Proposal to use two protocols (CPCP/CSCP or Netconf/CCCP) is not particularly constructive (albeit not impossible). • SOAP put forth as new (5th) protocol proposal.

10. Issues – Identified on mailing list for -01 • Conference policies: not explicitly addressed. • Current text is consistent with WG agreement (at interim and discussed on list) that there isno separation of “policy” from the conference data itself ; it’s all part of the “Conference Object”. • Policy uses ranges to control limits on values • Policy is based on simple list structures (i.e. a list (of clients) per type of data the listed clients have permission to manipulate). • As mentioned in document, if there is a need in the future (non is foreseen for currently envisioned functionality), the specification of such is FFS within XCON. • Proposal: ensure text is consistent and clear. (Note: there is an open issue to add the details of how this policy model is realized within the XCON FW. Perhaps this detail should be in the examples in section 7.)

11. Issues – Identified on mailing list for -01 • Templates vs. Blueprints: appears to be inconsistent distinction between the two within the document. The following had been agreed previously: • Template is associated with a human-readable doc (eg. RFC), with an IANA registry based on a triplet of form: name, RFC, XML schema. • Client can query a conferencing system for a list of templates that the system supports (per discussion of “Blueprints”). • Note: Blueprint is a data object, Template is a “type” • Proposal: remove the parenthetical reference to templates in section 6.3. (Note: paragraph 3 of that section is also using “template” rather than “blueprint”).

12. Issues – Identified on mailing list for -01 • SIPPING vs. XCON Framework. Proposal that major differences SHOULD be resolved. • Key issue is compatibility of sipping-cc-conferencing and sipping-conference-package with XCON model. • Messaging should not change, although model/implementation would change to support additional, new XCON defined functionality. • Proposal: re-review and evaluate specific concerns.

13. Additional work to complete • 6.4: Floor control section: • Current text intended to align terminology/identifiers from BFCP with XCON FW identifiers. • Less detail (security in particular) required. • Complete detail in section 7: • Include functionality such 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.

14. New work identified by Framework • The following items are identified as requiring further specification, in other documents, based upon the current discussion and concepts introduced in the framework: • URI schema(s) for new identifiers. • Mechanism/details for Data Access Rights and Conference Control Limits and Permissions (i.e. “conference policies”) . • Alternative proposal for Floor control based on templates (based on past WG discussions)?

15. DP5: CCP Protocol – Overview of options

16. Way Forward • Need additional mailing list feedback.

17. Back-up • Conferencing System Model diagram • Conference Object Type diagram • Cloning Tree for System Realization

18. Foci Data I/F Conferencing System Decomposition Conferencing System No Changes Conference Object Conference Object Conference Object • Floor • Control • Server • Conference • Control • Server • Notification • Service SIP/ PSTN/ H.323 T.120/ Etc. SIP NOTIFY/ Etc. TBD BFCP XCON Other Conference Control Client Floor Control Client Notification Client Call Signaling Client Conferencing Client

19. Conference Object Type Conference Object Type Common Conference Information Type Conference Description Membership (Roles, Capacity, Names) Signaling (Protocol, Direction, Status) Sidebars (and other attributes) Conference Template Type User Control Interface Mixer Algorithm Inputs And Outputs User’s View Etc.

20. Parent A Conference Object Parent B Conference Object Child 1 Conference Object Child 2 Conference Object Policies Policies Policies Policies Cloning Tree for System Realization (Created as “Independent from Parent)