Title Subtitle

1

XCON WG IETF-62 Meeting Minneapolis, Mar 8th
10th 2005
XCON Framework Overview Issues Editors
Mary Barnes (mary.barnes_at_nortelnetworks.com)
Chris Boulton (cboulton_at_ubiquity.net)
Orit Levin (oritl_at_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 Adams 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 its 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) -gt more work definitely
  required to describe detailed functionality once
  basics are agreed (hopefully today).

8
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
Call Signaling Client
Notification 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
Users View
Etc.
10
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 wont 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 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 dont 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 cant 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
• ltcontrol type "boolean" name"mute"
  default"true" enable"true"/gt
• ltcontrol type"boolean" name"mute"
  default"false" enable"true"/gt
• 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 dont 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 its
  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 doesnt 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 doesnt 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 -gt 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.