XCON WG
IETF-62 Meeting
Minneapolis, Mar 8th & 10th 2005
XCON Framework
Overview & Issues
Editors: Mary Barnes ([email protected])
Chris Boulton ([email protected])
Orit Levin ([email protected])
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
Mar 8th, 2005
draft-barnes-xcon-framework-02
1
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
2
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
Mar 8th, 2005
draft-barnes-xcon-framework-02
3
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.)
Mar 8th, 2005
draft-barnes-xcon-framework-02
4
Current Framework Updates
 Introduced the “Cloning Tree” as a model for
System Realization.
 Introduced iCal to support scheduling and recurring
reservations.
Mar 8th, 2005
draft-barnes-xcon-framework-02
5
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).
Mar 8th, 2005
draft-barnes-xcon-framework-02
6
“New-02” Conferencing System Decomposition
Conferencing System
Conference Object
Updated Logical names.
Simplified model by
logical grouping of data
Conference Object
Conference Object
Floor
Control
Server
Conference
Control
Server
Data I/F
XCON
Other
TBD
BFCP
Conference
Control
Client
Mar 8th,Conferencing
2005
Floor
Control
Client
Client
Foci
SIP/
PSTN/
H.323
T.120/
Call Etc.
Signaling
Client
draft-barnes-xcon-framework-02
Notification
Service
SIP NOTIFY/
Etc.
Notification
Client
7
“New-02” Conference Object Type
C o n f e r e n c e
O b j e c t
T y p e
Common Conference Information Type
Conference Description
Membership (Roles, Capacity, Names)
Signaling (Protocol, Direction, Status)
Sidebars (and other attributes)
Conference Template Type
User
Control
Interface
Mar 8th, 2005
Mixer
Algorithm
Inputs
And
Outputs
User’s
View
draft-barnes-xcon-framework-02
Etc.
8
“New-02” Cloning Tree for System Realization
P
o
l
i
c
i
e
s
Parent A
Conference
Object
(Created as “Independent from Parent)
P
o
l
i
c
i
e
s
Parent B
Conference
Object
P
o
l
i
c
i
e
s
P
o
l
i
c
i
e
s
Mar 8th, 2005
draft-barnes-xcon-framework-02
Child 1
Conference
Object
Child 2
Conference
Object
9
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)
Mar 8th, 2005
draft-barnes-xcon-framework-02
10
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).
Mar 8th, 2005
draft-barnes-xcon-framework-02
11
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
12
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
13
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
14
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
Mar 8th, 2005
draft-barnes-xcon-framework-02
15
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
Mar 8th, 2005
draft-barnes-xcon-framework-02
16
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).
Mar 8th, 2005
draft-barnes-xcon-framework-02
17
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
Mar 8th, 2005
draft-barnes-xcon-framework-02
18
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)
Mar 8th, 2005
draft-barnes-xcon-framework-02
19
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:
Mar 8th, 2005

CPCP, CCCP, CSCP, Netconf

To be discussed on Thursday.
draft-barnes-xcon-framework-02
20
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
21
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:

Mar 8th, 2005

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)
draft-barnes-xcon-framework-02
22
Part 2 (Thursday, March 10th):
 New work items
 Agreements/status of Discussion Points
 Summary of other open issues
 Additional Work items
 Way Forward
Mar 8th, 2005
draft-barnes-xcon-framework-02
23
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
24
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).
Mar 8th, 2005
draft-barnes-xcon-framework-02
25
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
26
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
27
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
28
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
29
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?
Mar 8th, 2005
draft-barnes-xcon-framework-02
30
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.
Mar 8th, 2005
draft-barnes-xcon-framework-02
31