Title Subtitle

1

XCON WG IETF-64 Meeting Vancouver, November 2005
XCON Framework Overview Issues Editors
Mary Barnes (mary.barnes_at_nortel.com)
Chris Boulton (cboulton_at_ubiquity.net)
Orit Levin (oritl_at_microsoft.com)
2
Overview

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

3
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.

4
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.

5
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).

6
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.

7
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.

8
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.

9
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

10
DP5 CCP Protocol Overview of options
11
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.
12
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.

13
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)?

14
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.