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

1. XCON WG IETF-62 Meeting Minneapolis, Mar 8th & 10th 2005 XCON Framework Overview & Issues Editors: Mary Barnes (mary.barnes@nortelnetworks.com) Chris Boulton (cboulton@ubiquity.net) Orit Levin (oritl@microsoft.com)

2. Overview Part 1 – Tuesday (45 min): • Current status of XCON framework document • Data Model derived and tentatively agreed at Interim • Issue Discussion Part 2 – Thursday (15 min) (starts at chart 23): • New work items • Agreements/status of Discussion Points • Summary of other open issues • Additional Work items • Way Forward

3. Current Framework Status • (Another) major re-write from -01 version based on interim meeting discussions and consensus: • Inline with Adam’s summary on 08 Feb 2005. • Simplified (and consistent) terminology: • Remains protocol agnostic in terms of call control signaling. • Defined “Focus” in the context of this framework. • Added new terms: “active conference”, “media graph”, etc. • Removed unused terms: “multimedia stream”, etc. • Use of “Conferencing System” and “Client” rather than “XCON server”, “XCON client”, etc.

4. Current Framework Status • Simplified (and consistent) terminology (continued): • Updated “Template” terminology: • 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” • Note: Discussion Point 3 on list around querying a particular template

5. Current Framework Updates • Simplified Data Model (types and objects): • No 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). • Conference Object Type is comprised of “Common Conference Information” type and “Conference Template”. Supports each of the stages of a conference instance (e.g. “reservation”, “active”, etc.)

6. Current Framework Updates • Introduced the “Cloning Tree” as a model for System Realization. • Introduced iCal to support scheduling and recurring reservations.

7. Current Framework Updates • Incorporated in a bit more background information to set the context. • No duplication of content from SIPPING Conferencing Framework • Section 8 intended to address relationship to SIPPING. • SIP used only as an example protocol, however, objective is to ensure that basic conferencing functionality for SIP is not impacted. • Current version intended to provide the baseline terminology, model and high level interfaces (including protocols) -> more work definitely required to describe detailed functionality once basics are agreed (hopefully today).

8. Foci Data I/F “New-02”Conferencing System Decomposition Conferencing System Updated Logical names. Simplified model by logical grouping of data 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

9. “New-02” 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.

10. Parent A Conference Object Parent B Conference Object Child 1 Conference Object Child 2 Conference Object Policies Policies Policies Policies “New-02” Cloning Tree for System Realization (Created as “Independent from Parent)

11. Issue – DP 1: Referring to Sets of Meetings • Interim agreements reflected in current doc on scheduling a conference: • iCal defined as the required mechanism to be referenced (i.e. XCON won’t define any ical extensions). • iCal object used to describe “time” (eg. Start time, end time) • Makes use of cloning tree model to create the “Conference Object for Reservation”: • Thus, can alter a series by manipulating this Parent Object. • Can manipulate within the range of the series by cloning the children associated within that time range. • DP1 highlights an additional consideration not currently explicitly addressed: • Is it necessary to be able to identify "all future occurrences" of a conference (i.e. “infinite series”) ? • Proposal: Should be inherently supportable with “cloning tree“ structure and iCal (i.e. should not impact current/planned iCal functionality)

12. Issue – DP 2: Floor Control Model in terms of “Groups of RTP streams”? • DP2 discussesthe need to identify bundles of associated RTP streams, possibly at the protocol level, and possibly just as a concept for discussion of the protocols. • Do we need this? • If so, what do we call this? • Is it represented in the protocols? • If it is part of a protocol: • which protocol: • Conference Control Protocol – inside templates? • Inside SDP? • Within BFCP (which is done already)? • how is the grouping defined? • Mailing list feedback indicates, we don’t need this grouping mechanism, but rather can use a stream name specific to a “role”. • Proposal: go forward based on mailing list feedback. Validate approach by working through further detailed flows, etc. with protocols (in section 7).

13. Issue – DP3: Querying Templates • Interim Consensus: Agreement to provide the ability to query a server that implements the XCON protocols to determine which templates it understands. • Additional discussion, but no consensus, around the ability to query a server about a particular template to retrieve a description -- probably an XML document, but possibly in some other form -- of that template. • The idea behind this functionality would be enabling clients to interact with templates that they don't natively understand. • By extracting the variables from the template description and presenting them to the user in some format that allows manipulation of their values, all clients can work with all templates, even those that were not defined when the client was developed. • Is this an important property? • Proposal: Yes, this property is important for templates to remain flexible.

14. Issue – DP3: Querying Templates - continued • What is the format in which the template description should be presented? • Alternative 1: XML Schema - as in current templates draft. This then supplies all relevant information that a client needs. • Alternative 2: “Blueprint”, per current FW, which includes a template instantiation with customized values • Does the client retrieve this description from the server itself, or is there some centralized repository to get these descriptions from? • Mailing list feedback [Cullen]: can’t be from central repository. • Proposal: XCON server advertises exactly what is supported by the server.

15. Issue – DP3: Querying Templates- continued • Can the description be the same as the XML schema that is registered with IANA? • Proposal: Should be the same. • Is the description sent at the same time as the list of templates is sent to the client, or does a client need to explicitly ask about templates that it doesn't understand? • Proposal: A client would need to query any templates that it doesn't understand THEN make a decision on compatibility.

16. Issue – DP3: Querying Templates- continued • If we use the XML schema to describe the template, should we include user interface "hints" that allow clients to intelligently decide whether to display values as (e.g.) a slider versus a knob versus a number that can be typed in? • Proposal: Yes - interface hints need to be included e.g. per current template draft: <control type ="boolean" name="mute" default="true" enable="true"/> <control type="boolean" name="mute" default="false" enable="true"/> • Mailing List: concern that don't even know if the device has a screen or not (or a keyboard or not

17. Issue – DP4: XML Schema Structure Three options: • Template at the top level, with Common Conference Information as a subsection. • Single schema • Requires knowledge of a particular Template schema by the client in order to retrieve any basic information • Requires Navigation of the template to get to common conference information. • Common Conference Information, at top level, contains template information. • Clients don’t need to care about templates for basic conferencing. • Common Conference Information must include an extension point, which complicates XML validation

18. Issue – DP4: XML Schema Structure - continued • Template and Common Conference Information are conveyed as two separate objects: • Separate schema, straightforward validation and easy access to either information • Increases protocol complexity (e.g. multipart mime or separate protocols) • Proposal: option 2 (Editors’ choice) or 3 (if WG prefers).

19. Issue – DP5: State and Policy Manipulation Protocol(s) • Option 1: Syntactic (i.e. basic operations, with variable and data provided upon invocation) • Allows for extensions to data model without impacting protocol • More suitable for Conference Template since it’s intended to be extended. • Server generally has to infer intent from data content rather than via direct signalling • Processing overhead • Interpretation may result in interoperability issues • Poorly suited for “compound operations” such as moving objects

20. Issue – DP5: State and Policy Manipulation Protocol(s) • Option 2: Semantic (i.e. explicit operations) • Efficient Server Implementation • Promise of better interoperability • Extensions to the underlying data model require extensions to the protocol used to manipulate it • More suitable for Common Conference Information since this information is easily scoped by a relatively small number of primitives • Easily extensible under a common protocol infrastructure • Can define data manipulations (syntactic) primitives • Can define opaque stimulus operations • Option 3: Both • Appears to conflict with objective to have a single protocol. • Note, however, that semantic can also support fundamental syntactic model (for data manipulations)

21. Issue – DP5: State and Policy Manipulation Protocol(s) • Mailing List Discussion: • Seemed to converge to the point that the differentiation is artificial and doesn’t resolve anything. • Consistent with the point that semantic model can also support fundamental syntactic model (for data manipulations) • Proposal: Option 2, with the operations to support basic data manipulations (for syntactic operations). • Several protocols put forth: • CPCP, CCCP, CSCP, Netconf • To be discussed on Thursday.

22. Issues – Identified during WG review • Section 4.1: text around Conference Instance mapping to multiple conference objects seems confusing. • Proposal: propose re-wording as later text (in section 5) makes the concept more clear. • Figure 2: show Floors/floor control (as part of Conference Object Type). • Section 4.5: Data Access Rights seems very much like Common Conference Rules. • Editors: we needed to keep the concept of conference policies. There is no longer any central repository per se, but there is a need to have the read/write access rights associated with each object. Permissions are reflected by the simple list structure. • Does this need further discussion/clarification? • Proposal: remove differentiation of layers and clearly describe necessary functionality to support the fundamental access to the data objects and the allowed ranges of the data, list of clients, etc. Include note as to a more general “Rule” mechanism being out of scope and FFS.

23. Issues – Identified during WG review • 6.4: Floor control section – needs additional work. [Note: current text is attempting to align terminology/identifiers from BFCP with XCON FW identifiers] • 6.4.1: User Identifier: • new section is a bit out of context here • details need resolution. • Section 7.1: example is really media manipulation (i.e. section 7.2)

24. Part 2 (Thursday, March 10th): • New work items • Agreements/status of Discussion Points • Summary of other open issues • Additional Work items • Way Forward

25. 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 for Conference Object Identifier • Mechanism/details for Data Access Rights and Conference Control Limits and Permissions (i.e. “conference policies”) . • Alternative proposal for Floor control based on templates? • User Identifier (for Conferencing System) – introduced in section 6.4.1. • new section is a bit out of context here • details need resolution - perhaps documented with the URI schema for Conference Object Identifier) • All these items require further discussion on the list.

26. Agreed work items/DP status • DP1: Referring to Sets of Meetings. • Agreement: Should be inherently supportable with “cloning tree“ structure and iCal (i.e. should not impact current/planned iCal functionality). • Action: Need to ensure that there is a single “time” from which other times are derived (subject to system considerations). • DP2:Floor Control Model in terms of “Groups of RTP streams”? • Agreement: go forward based on mailing list feedback that grouping may not be necessary (i.e. can use a stream name specific to a “role”. ) • Validate approach by working through further detailed flows, etc. with protocols (in section 7).

27. Agreed work items/DP status • DP3: Querying templates Agreements: • 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.

28. Agreed work items/DP status • DP3: Querying templates (continued) Agreements (continued): • 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.

29. Agreed work items/DP status • 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 • No agreement. • Action: Continue discussion on list.

30. Agreed work items/DP status • DP5: State and Policy Manipulation Protocol(s) • Mailing List Discussion seemed to converge to the point that the differentiation between syntactic and semantic is artificial and doesn’t resolve anything • Proposal that “ semantic model” can also support fundamental syntactic model (for data manipulations) • Updates to reflect conclusions to current WG discussions on specific protocol proposals.

31. Additional work to complete • 6.4: Floor control section: • Current text is attempting to align terminology/identifiers from BFCP with XCON FW identifiers. • Needs additional work/cleanup • Complete detail in section 7: • Including functionality such as sidebars, private messages, etc. • Need 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. • One example currently in section 7.1 -> need feedback on this approach or alternatives). • Mailing list: section 7.1 is really section 7.2 (media manipulation). • Add some full physical realization EXAMPLES with a mix of XCON functions and existing protocols?

32. Way Forward • Plans are to update doc based on discussions thus far, meeting conclusions and any additional mailing list feedback. • Submit doc as WG document, planning at least one review cycle prior to Paris.