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

2. 1 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 2 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 3 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 4 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 5 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Current Framework Updates  Introduced the “Cloning Tree” as a model for System Realization.  Introduced iCal to support scheduling and recurring reservations.

7. 6 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 7 draft-barnes-xcon-framework-02 Mar 8 th, 2005 “New-02” Conferencing System Decomposition Conferencing System Floor Control Client Notification Service Conference Control Client Conference Control Server Call Signaling Client Notification Client Floor Control Server SIP/ PSTN/ H.323 T.120/ Etc. TBD SIP NOTIFY/ Etc. Conferencing Client Foci Conference Object Updated Logical names. Simplified model by logical grouping of data BFCP Data I/F XCON Other

9. 8 draft-barnes-xcon-framework-02 Mar 8 th, 2005 “New-02” Conference Object Type Conference Object Type User Control Interface Mixer Algorithm Inputs And Outputs User’s View Etc. Conference Template Type Conference Description Membership (Roles, Capacity, Names) Signaling (Protocol, Direction, Status) Sidebars (and other attributes) Common Conference Information Type

10. 9 draft-barnes-xcon-framework-02 Mar 8 th, 2005 “New-02” Cloning Tree for System Realization Parent A Conference Object PoliciesPolicies Parent B Conference Object PoliciesPolicies (Created as “Independent from Parent) Child 1 Conference Object PoliciesPolicies Child 2 Conference Object PoliciesPolicies

11. 10 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 11 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Issue – DP 2: Floor Control Model in terms of “Groups of RTP streams”?  DP2 discusses the 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. 12 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 13 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 14 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 15 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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:  Mailing List: concern that don't even know if the device has a screen or not (or a keyboard or not

17. 16 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Issue – DP4: XML Schema Structure Three options: 1. 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. 2. 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. 17 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Issue – DP4: XML Schema Structure - continued 3. 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. 18 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 19 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 20 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 21 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 22 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 23 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Part 2 (Thursday, March 10 th ):  New work items  Agreements/status of Discussion Points  Summary of other open issues  Additional Work items  Way Forward

25. 24 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 25 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 26 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 27 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 28 draft-barnes-xcon-framework-02 Mar 8 th, 2005 Agreed work items/DP status  DP4: XML Schema Structure – 3 options proposed: 1. Option 1: Template at the top level, with Common Conference Information as a subsection. 2. Option 2: Common Conference Information at top 3. Option 3: Template and Common Conference Information are conveyed as two separate objects  No agreement.  Action: Continue discussion on list.

30. 29 draft-barnes-xcon-framework-02 Mar 8 th, 2005  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. Agreed work items/DP status

31. 30 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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. 31 draft-barnes-xcon-framework-02 Mar 8 th, 2005 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.