draft-ietf-xcon-framework-00.txt   draft-ietf-xcon-framework-01.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Expires: October 31, 2005 C. Boulton Expires: January 16, 2006 C. Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
April 29, 2005 July 15, 2005
A Framework and Data Model for Centralized Conferencing A Framework and Data Model for Centralized Conferencing
draft-ietf-xcon-framework-00 draft-ietf-xcon-framework-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 31, 2005. This Internet-Draft will expire on January 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines the framework for Centralized Conferencing This document defines the framework for Centralized Conferencing
(XCON), which is applicable to participants using different call (XCON), which is applicable to participants using different call
control signaling protocols and exchanging media over networks with control signaling protocols and exchanging media over networks with
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 9 4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Common Conference Information . . . . . . . . . . . . . . 11 4.1 Common Conference Information . . . . . . . . . . . . . . 11
4.2 Conference Template . . . . . . . . . . . . . . . . . . . 12 4.2 Conference Template . . . . . . . . . . . . . . . . . . . 12
4.3 Conference policies . . . . . . . . . . . . . . . . . . . 12 4.3 Conference policies . . . . . . . . . . . . . . . . . . . 12
5. XCON Identifiers . . . . . . . . . . . . . . . . . . . . . . . 13 5. XCON Constructs and Identifiers . . . . . . . . . . . . . . . 13
5.1 Conference Object Identifier . . . . . . . . . . . . . . . 13 5.1 Conference Identifier . . . . . . . . . . . . . . . . . . 13
5.2 Conference Identifier . . . . . . . . . . . . . . . . . . 14 5.2 Conference Instance . . . . . . . . . . . . . . . . . . . 13
5.3 Conference User Identifier . . . . . . . . . . . . . . . . 15 5.3 Conference Object . . . . . . . . . . . . . . . . . . . . 14
6. Conferencing System Realization . . . . . . . . . . . . . . . 16 5.3.1 Conference Object Identifier . . . . . . . . . . . . . 16
6.1 Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Conference User Identifier . . . . . . . . . . . . . . . . 17
6.2 Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 6. Conferencing System Realization . . . . . . . . . . . . . . . 18
6.3 Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 6.1 Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 19
6.4 Scheduling a 'Conference Object for Reservation' . . . . . 22 6.2 Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 21
7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 6.3 Advanced Example . . . . . . . . . . . . . . . . . . . . . 22
7.1 Call Control Signalling . . . . . . . . . . . . . . . . . 26 6.4 Scheduling a 'Conference Object for Reservation' . . . . . 24
7.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 26 7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 28
7.3 Conference Control Protocols . . . . . . . . . . . . . . . 26 7.1 Call Control Signalling . . . . . . . . . . . . . . . . . 28
7.3.1 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 28
7.3.2 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3 Conference Control Protocol . . . . . . . . . . . . . . . 28
7.3.3 CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3.1 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.3.4 NETCONF . . . . . . . . . . . . . . . . . . . . . . . 28 7.3.2 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.4 Floor Control . . . . . . . . . . . . . . . . . . . . . . 29 7.3.3 CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 31 7.3.4 NETCONF . . . . . . . . . . . . . . . . . . . . . . . 30
8.1 Participant Manipulations . . . . . . . . . . . . . . . . 31 7.3.5 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2 Media Manipulations . . . . . . . . . . . . . . . . . . . 32 7.4 Floor Control . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 33
8.4 Whispering or Private Messages . . . . . . . . . . . . . . 35 8.1 Participant Manipulations . . . . . . . . . . . . . . . . 33
8.5 Conference Announcements and Recordings . . . . . . . . . 35 8.2 Media Manipulations . . . . . . . . . . . . . . . . . . . 35
9. Relationships between SIPPING and XCON Frameworks . . . . . . 36 8.3 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . 36 8.4 Whispering or Private Messages . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 8.5 Conference Announcements and Recordings . . . . . . . . . 38
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 9. Relationships between SIPPING and XCON Frameworks . . . . . . 38
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . 38
14. Changes since last Version . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
15.1 Normative References . . . . . . . . . . . . . . . . . . . 40 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 41
15.2 Informative References . . . . . . . . . . . . . . . . . . 40 14. Changes since last Version . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . 44 15.1 Normative References . . . . . . . . . . . . . . . . . . . 43
15.2 Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 47
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing This document defines the framework for Centralized Conferencing
(XCON), which is applicable to participants using various call (XCON), which is applicable to participants using various call
signalling protocols (such as SIP, H.323, Jabber, HTML, PSTN, etc.) signalling protocols (such as SIP, H.323, Jabber, HTML, PSTN, etc.)
and exchanging media over networks with potentially different and exchanging media over networks with potentially different
characteristics. characteristics.
The XCON Framework defines the XCON data model, the XCON logical The XCON Framework defines the XCON data model, the XCON logical
skipping to change at page 4, line 46 skipping to change at page 4, line 46
concepts as listed below. concepts as listed below.
Active Conference: The term Active Conference refers to a Conference Active Conference: The term Active Conference refers to a Conference
Object that's been created (for example, using a "blueprint") and Object that's been created (for example, using a "blueprint") and
"activated" via the allocation of its identifiers (i.e. "activated" via the allocation of its identifiers (i.e.
Conference Object Identifier, Conference Identifier) and the Conference Object Identifier, Conference Identifier) and the
associated Focus. associated Focus.
Call (Control) Signalling: The protocol used between a participant Call (Control) Signalling: The protocol used between a participant
and a Focus. In this context, the term "call" means a channel or and a Focus. In this context, the term "call" means a channel or
session used for media streams establishment. Protocol examples session used for media streams establishment. Protocol examples
include SIP, H.323, MSRP, Jabber, HTML and PSTN signalling. This include, but are not limited to, SIP, H.323, MSRP, Jabber, HTML
interface is not limited to the listed protocols, however, other and PSTN signalling. Other than references to general
than references to general functionality required (e.g. functionality required (e.g. establishment and teardown), details
establishment and teardown), details of these protocols are of these protocols are outside the scope of this document.
outside the scope of this document.
Common Conference Information: The data type (i.e. the XML schema) Common Conference Information: The data type (i.e. the XML schema)
which is used to represent the fixed information part of a which is used to represent the fixed information part of a
Conference Object. It includes a common set of definitions for Conference Object. It includes a common set of definitions for
basic conference features, such as conference identifiers, basic conference features, such as conference identifiers,
membership, signalling, capabilities, media, etc. membership, signalling, capabilities, media, etc.
Conference Control Protocol (CCP): A protocol used by clients to Conference Control Protocol (CCP): A protocol used by clients to
manipulate a Conference Object [Section 7.3]. manipulate a Conference Object [Section 7.3].
Conference Factory: A logical entity that, upon request, generates Conference Factory: A logical entity that, upon request, generates
unique URI(s) to identify and represent a conference Focus. The unique URI(s) to identify and represent a conference Focus. The
Conference Factory is typically used in the conference creation Conference Factory is typically used in the conference creation
process via a signalling interface and non-signalling methods such process via a signalling interface and non-signalling methods such
as Conference Control Protocol [Section 7.3] and proprietary as Conference Control Protocol [Section 7.3] and proprietary
mechanisms. mechanisms.
Conference Identifier(ID): The call signalling protocol-specific URI Conference Identifier(ID): The call signalling protocol-specific URI
that uniquely identifies a Conference Instance and a conference that uniquely identifies a conference Focus and its associated
Focus. Conference Instance.
Conference Instance: Represents the internal implementation of a Conference Instance: An instantiation of a Conference Object. The
conference; addressable using the Conference Identifier. There is Conferencing System associates a Conference Instance with the
a one-to-one mapping between a Conference Instance and a Conference Identifier(s). There is a one-to-one mapping between a
conference Focus. Conference Instance and a conference Focus.
Conference Object: A Conference Object is a logical representation of Conference Object: A representation of a conference at a certain
a Conference Instance at a certain stage (e.g. description upon stage (e.g. description upon conference creation, reservation,
conference creation, reservation, activation, etc.), which a activation, etc.), which a Conferencing System maintains in order
Conferencing System maintains in order to describe the system to describe the system capabilities and to provide access to the
capabilities and to provide access to the available services available services provided by the Conferencing System. All
provided by the Conferencing System. All Conference Objects are Conference Objects are of type 'Conference Object Type' which is
of type 'Conference Object Type' which is comprised of two comprised of two distinct sub components; the 'Common Conference
distinct sub components; the 'Common Conference Information' and Information' and the 'Conference Template' (see definitions in
the 'Conference Template' (see definitions in this section for this section for details).
details).
Conference Object Identifier (ID): A [TBD schema name] URI which Conference Object Identifier (ID): A [TBD schema name] URI which
uniquly identifies a Conference Object and is being used by a uniquly identifies a Conference Object and is being used by a
Conference Control Protocol [Section 7.3]. Conference Control Protocol [Section 7.3].
Conference policies: A term which is used to collectively refer to a Conference policies: A term which is used to collectively refer to a
virtual set of rights, permissions and limitations pertaining to virtual set of rights, permissions and limitations pertaining to
operations being performed on a certain Conference Object. The operations being performed on a certain Conference Object. The
term is described in more details in Section 4.3. term is described in more details in Section 4.3.
Conference State: The state of a Conference Instance as represented Conference State: The state of a Conference Instance as represented
using the Conference Package mechanism defined in [11]. using the Conference Package mechanism defined in [11].
Conferencing System: The term used to refer to a conferencing Conferencing System: The term used to refer to a conferencing
skipping to change at page 6, line 34 skipping to change at page 6, line 34
Conference Instance. Conference Instance.
Media Graph: The logical representation of the flow of media for a Media Graph: The logical representation of the flow of media for a
conference. conference.
Media Mixer: A logical entity that has the capability to combine Media Mixer: A logical entity that has the capability to combine
media inputs of the same type (or/and transcode the media) and media inputs of the same type (or/and transcode the media) and
distribute the result(s) to a single or multiple outputs. In this distribute the result(s) to a single or multiple outputs. In this
context, the term "media" means any type of data being delivered context, the term "media" means any type of data being delivered
over the network using appropriate transport means, such as RTP/ over the network using appropriate transport means, such as RTP/
RTCP (defined in RFC 3550[7]), Message Session Relay Protocol RTCP (defined in RFC 3550[7]), Message Session Relay Protocol
(defined in [25]), etc. (defined in [25]), etc.
Registered Template Definition: 'Registered Template Definition' is Registered Conference Document : An official standards document (RFC)
the term used to refer to an official standards document (RFC)
that defines and registers a Conference Template schema with the that defines and registers a Conference Template schema with the
appropriate standards body (IANA). A 'Registered Template appropriate standards body (IANA). A 'Registered Conference
Definition' also includes any complimentary textual information in Document' also includes any complimentary textual information in
relation to the conference template schema and its meaning. relation to the conference template schema and its meaning.
Role: Represents differing membership categories that a conference Role: Represents differing membership categories that a conference
participant can assume within a conference. Each category has a participant can assume within a conference. Each category has a
difference set of conference operations that a participant can difference set of conference operations that a participant can
perform. A default (e.g. Standard Conference Participant) 'Role' perform. A default (e.g. Standard Conference Participant) 'Role'
will always exist which provides a standard user with a set of will always exist which provides a standard user with a set of
basic conference operations. Any user with appropriate basic conference operations. Any user with appropriate
authentication and authorization may assume a role that has a authentication and authorization may assume a role that has a
wider set of conference operations that are otherwise not wider set of conference operations that are otherwise not
available (to a standard Conference Participant) - e.g. A 'Role' available (to a standard Conference Participant) - e.g. A 'Role'
skipping to change at page 9, line 5 skipping to change at page 9, line 5
. | Client | | Client | | Client | | | . . | Client | | Client | | Client | | | .
. +----------------+ +------------+ +----------+ +------------+ . . +----------------+ +------------+ +----------+ +------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
...................................................................... ......................................................................
Figure 1: Conferencing System Logical Decomposition. Figure 1: Conferencing System Logical Decomposition.
The media graph of a conference can be centralized, de-centralized, The media graph of a conference can be centralized, de-centralized,
or any combination of both and potentially differ per media type. In or any combination of both and potentially differ per media type. In
the centralized case, the media sessions are established between the the centralized case, the media sessions are established between a
focus and each one of the participants. In de-centralized (i.e. media mixer controlled by the focus and each one of the participants.
distributed) case, the media graph is a (multicast or multi-unicast) In the de-centralized (i.e. distributed) case, the media graph is a
mesh among the participants. Consequently, the media processing (multicast or multi-unicast) mesh among the participants.
(e.g. mixing) can be performed either by the focus alone or by the Consequently, the media processing (e.g. mixing) can be controlled
participants. The concepts in this framework document clearly map to either by the focus alone or by the participants. The concepts in
a centralized media model. They can also apply to the de-centralized this framework document clearly map to a centralized media model.
media case, however, the details of such are left for future study by The concepts can also apply to the de-centralized media case,
XCON charter. however, the details of such are left for future study by the XCON WG
charter.
Section 4 of this document provides more details on the Conference Section 4 of this document provides more details on the Conference
Object. Section 5 provides an overview of the identifiers necessary Object. Section 5 provides an overview of the identifiers necessary
to address and manage the Conference Objects, Instances and Users to address and manage the Conference Objects, Instances and Users
associated with a Conferencing System. Section 6 of this document associated with a Conferencing System. Section 6 of this document
describes how a Conferencing System is logically built using the describes how a Conferencing System is logically built using the
defined data model and how the Conference Objects are maintained. defined data model and how the Conference Objects are maintained.
Section 7 describes the fundamental conferencing mechanisms and Section 7 describes the fundamental conferencing mechanisms and
provides a high level overview of the XCON protocols. Section 8 then provides a high level overview of the XCON protocols. Section 8 then
provides realizations of various conferencing scenarios, detailing provides realizations of various conferencing scenarios, detailing
skipping to change at page 12, line 26 skipping to change at page 12, line 26
The concept of a "Conference Template" is introduced to abstract the The concept of a "Conference Template" is introduced to abstract the
complexity and the details of the "mixer" and other conferencing complexity and the details of the "mixer" and other conferencing
features and to allow for easy user interface abstraction for features and to allow for easy user interface abstraction for
advanced Conferencing Systems. advanced Conferencing Systems.
Each Conference Template needs to be registered with IANA. The IANA Each Conference Template needs to be registered with IANA. The IANA
registration needs to point to an RFC having the text description of registration needs to point to an RFC having the text description of
the feature behavior and optionally the XML definition allowing the the feature behavior and optionally the XML definition allowing the
feature presentation, configuration, and management. RFCs of this feature presentation, configuration, and management. RFCs of this
kind are referred by XCON documents as a "Registered Template kind are referred by XCON documents as a "Registered Conference
Definitions". Document".
Typically, a conference template would contain the information about Typically, a conference template would contain the information about
the specific media mixing details, the associated client roles and the specific media mixing details, the associated client roles and
the available floor controls. This information would allow the available floor controls. This information would allow
authorized clients to manipulate mixer's behavior and the resultant authorized clients to manipulate mixer's behavior and the resultant
distribution of the media to all or individual participants. By distribution of the media to all or individual participants. By
doing so, a client can change its own state and/or state of other doing so, a client can change its own state and/or state of other
participants in the conference. participants in the conference.
A conference template can also include an abstract user interface A conference template can also include an abstract user interface
skipping to change at page 13, line 19 skipping to change at page 13, line 19
conference object. For example, the "allowed to join" list of conference object. For example, the "allowed to join" list of
participants is consulted to decide who is allowed to join. The participants is consulted to decide who is allowed to join. The
entries in the list can specify the identity of an individual user entries in the list can specify the identity of an individual user
(joe@example.com), a role, a domain (*@example.com), etc. For (joe@example.com), a role, a domain (*@example.com), etc. For
details see [TBD]. details see [TBD].
A more general rule mechanism, beyond the functionality provided by A more general rule mechanism, beyond the functionality provided by
the permissions and limits, is an item for future study for the XCON the permissions and limits, is an item for future study for the XCON
WG. WG.
5. XCON Identifiers 5. XCON Constructs and Identifiers
This section provides details of the identifiers associated with the This section provides details of the identifiers associated with the
XCON constructs (e.g. Conference Object and Conference Instance) and XCON constructs (e.g. Conference Object and Conference Instance) and
the identifiers necessary to address and manage the clients the identifiers necessary to address and manage the clients
associated with a Conferencing System. An overview of the associated with a Conferencing System. An overview of the
allocation, characteristics and functional role of the identifiers is allocation, characteristics and functional role of the identifiers is
provided. provided.
5.1 Conference Object Identifier 5.1 Conference Identifier
The Conference Identifier (ID) is the call signalling protocol-
specific URI that uniquely identifies a Conference Instance and a
conference Focus. The Conference Factory is the logical entity that
generates the unique Conference ID to identify and represent a
conference Focus. The Conference Factory is typically used in the
conference creation process via a signalling interface and non-
signalling methods such as Conference Control Protocol [Section 7.3]
and proprietary mechanisms.
5.2 Conference Instance
A Conference Instance is an internal implementation construct of a
conference, which is accessible by call signalling means, thus no
explicit identifier is required. Note that a Conference Instance can
have more than a single Conference Identifier, for example, for each
call signalling protocol supported. There is a one-to-one mapping
between a Conference Instance and a conference Focus. The Focus is
addressed by explicitly associating unique Conference IDs for each
signalling protocol supported by its Conference Instance.
A single Conference Instance can be internally mapped to a single or
multiple Conference Objects; each of them accessible by a Call
Control protocol.
5.3 Conference Object
A Conference Object is the logical representation of a Conference
Instance at a certain stage, such as a "blueprint" representing a
Conferencing System's capabilities, the data representing a reserved
or scheduled conference, or the conference state during an active
conference. The Conferencing System exposes this data as separate
objects to allow independent access. Consequently, the XCON
specifications allow the association of multiple Conference Objects
with a single Conference Instance.
Figure 3 illustrates the relationships between the Conference
Identifier, the Focus and the Conference Object Identifier within the
context of a logical Conference Instance, with the Conference Object
corresponding to an ongoing conference (i.e. a conference in the
active state). The Conference Object is identified by a single or a
set of call signaling Conference Identifiers, with a one-to-one
mapping, as shown in the figure.
The Conference Objects corresponding to additional conference stages
are addressing using CCP [Section 7.3]. CCP will define the
necessary logical naming conventions for addressing additional
Conference Objects, within the context of the cloning tree concept
introduced in Section 6.
......................................................................
. Conference Instance .
. .
. .
. +---------------------------------------------------+ .
. | Conference Object Identifier | .
. | | .
. | | .
. +---------------------------------------------------+ .
. ^ ^ .
. | | .
. v | .
. ................................................... | .
. . Focus . | .
. . . | .
. . +----------------------------------+ . | .
. . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | .
. . | Conference Identifier (PSTN) | | . | .
. . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | .
. . | |^ | . | .
. . +--------------------------------------+| | . | .
. ............^...............................|.|.... | .
. | | | | .
................|...............................|.|......|............
| | | |
|SIP | | |Conference
| PSTN | |Y |Control
| | | |Protocol
| +---------------+ | |
| | | |
| | | |
v v v v
+----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client |
| 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+
Figure 3: Conference Identifer, Focus, Conference Instance and
Conference Object Identifier Relationships.
5.3.1 Conference Object Identifier
In order to make each Conference Object externally accessible, the In order to make each Conference Object externally accessible, the
Conferencing System allocates a unique URI per distinct Conference Conferencing System allocates a unique URI per distinct Conference
Object in the system, as defined in [ref:TBD]. A Conference Control Object in the system, as defined in [ref:TBD]. A Conference Control
Protocol [as outlined in Section 7.3] can then be used for directly Protocol [as outlined in Section 7.3] can then be used for directly
manipulating a particular Conference Object and for obtaining its manipulating a particular Conference Object and for obtaining its
current state. current state.
The Conference Object URI acts as a top level identifier for an The Conference Object URI acts as a top level identifier for an
'umbrella style' construct within the Conference System for the 'umbrella style' construct within the Conference System for the
purpose of identifying incoming connections for complimentary XCON purpose of identifying incoming connections for complimentary XCON
protocols (e.g. BFCP). This implicit binding provides a structured protocols (e.g. BFCP). This implicit binding provides a structured
mapping of the various XCON protocols with the associated Conference mapping of the various XCON protocols with the associated Conference
Object Identifier. As an example, Figure 3 illustrates how BFCP Object Identifier. As an example, Figure 4 illustrates how BFCP
connections fall under the general Conference Object identifier connections fall under the general Conference Object identifier
umbrella. umbrella.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------+ +--------------+
| |
| |
skipping to change at page 14, line 24 skipping to change at page 16, line 42
| BFCP 'confid' | | BFCP 'confid' |
+-------+-------+ +-------+-------+
| |
| |
+---------------+---------------+ +---------------+---------------+
| | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
|BFCP 'floorid' | |BFCP 'floorid' | |BFCP 'floorid' | |BFCP 'floorid' |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
Figure 3: Conference Object Mapping. Figure 4: Conference Object Mapping.
In Figure 3, the Conference Object Identifier acts as the top level In Figure 4, the Conference Object Identifier acts as the top level
key in the identification process. The BFCP protocol, as defined in key in the identification process. The BFCP protocol, as defined in
[24], defines the 'conf-id' identifier which represents a conference [24], defines the 'conf-id' identifier which represents a conference
instance within Floor Control. BFCP also defines the 'floorid' instance within Floor Control. BFCP also defines the 'floorid'
identifier for specific floors within a Conference instance. When identifier for specific floors within a Conference instance. When
created within the Conference System, the 'conf-id' has a 1:1 mapping created within the Conference System, the 'conf-id' has a 1:1 mapping
to the unique XCON Conference Object Identifier. Using the BFCP to the unique XCON Conference Object Identifier. Using the BFCP
example, the Conference System is able to map the floor request to example, the Conference System is able to map the floor request to
the associated Conference Object. the associated Conference Object.
This umbrella style association can be applied to any supplementary This umbrella style association can be applied to any supplementary
mechanisms that are applied to the XCON model defined in this mechanisms that are applied to the XCON model defined in this
document as long as a unique reference per conference instance is document as long as a unique reference per conference instance is
available that can be mapped to a Conference Object. available that can be mapped to a Conference Object.
[Editor's Note: The URI schema name per TBD must be registered with [Editor's Note: The URI schema name per TBD must be registered with
IANA.] IANA.]
5.2 Conference Identifier 5.4 Conference User Identifier
The Conference Identifier (ID) is the call signalling protocol-
specific URI that uniquely identifies a Conference Instance and a
conference Focus. The Conference Factory is the logical entity that
generates the unique Conference ID to identify and represent a
conference Focus. The Conference Factory is typically used in the
conference creation process via a signalling interface and non-
signalling methods such as Conference Control Protocol [Section 7.3]
and proprietary mechanisms.
A Conference Instance is an internal implementation construct of a
conference, which is accessible by call signalling means, thus no
explicit identifier is required. Note that a Conference Instance can
have more than a single Conference Identifier, for example, for each
call signalling protocol supported. There is a one-to-one mapping
between a Conference Instance and a conference Focus. The Focus is
addressed by explicitly associating unique Conference IDs for each
signalling protocol supported by its Conference Instance.
A single Conference Instance can be internally mapped to a single or
multiple Conference Objects; each of them accessible by a Call
Control protocol. The mapping details are an implementation decision
and out of scope of this framework.
5.3 Conference User Identifier
Section 5.1 discusses the concept of an umbrella mechanism for Section 5.3.1 discusses the concept of an umbrella mechanism for
associating various protocol identifiers with a top level XCON associating various protocol identifiers with a top level XCON
identifier. This section outlines a similar umbrella mechanism for identifier. This section outlines a similar umbrella mechanism for
the purpose of correlating users of supplementary XCON protocols the purpose of correlating users of supplementary XCON protocols
under one universal XCON identity within an XCON Conference System. under one universal XCON identity within an XCON Conference System.
It is important to emphasize that the Conference User Identifier It is important to emphasize that the Conference User Identifier
being described must be in the context of the Conference System. being described must be in the context of the Conference System.
This is due to the requirement for identity of Conference System This is due to the requirement for identity of Conference System
users who may not be participating in a Conference Instance. users who may not be participating in a Conference Instance.
Examples being a non participating 'Floor Control Chair' or 'Media Examples being a non participating 'Floor Control Chair' or 'Media
Policy' Controller. Users can then be associated with Conference Policy' Controller. Users can then be associated with Conference
Objects as defined in Section 5.1. This association enables the Objects as defined in Section 5.3.1. This association enables the
Conference System to associate and enforce user level policies at Conference System to associate and enforce user level policies at
both a system level and Conference Object level. both a system level and Conference Object level.
Each user within a Conference System is allocated a unique Conference Each user within a Conference System is allocated a unique Conference
User Identifier, as defined in [TBD]. This identifier acts as a top User Identifier, as defined in [TBD]. This identifier acts as a top
level identifier, in a similar fashion to that defined for the level identifier, in a similar fashion to that defined for the
Conference Object Identifier described in Section 5.1. User Conference Object Identifier described in Section 5.3.1. User
identifiers defined in other protocols that are used within a identifiers defined in other protocols that are used within a
Conference Instance fall underneath the top level identifier and Conference Instance fall underneath the top level identifier and
enable the Conference System to correlate and map authentication enable the Conference System to correlate and map authentication
under the single user umbrella. under the single user umbrella.
Figure 4 illustrates an example using the Conference User Identifier Figure 5 illustrates an example using the Conference User Identifier
in association with the user identity defined for BFCP and SIP Digest in association with the user identity defined for BFCP and SIP Digest
user identity as defined in RFC3261[4] user identity as defined in RFC3261[4]
+---------------+ +---------------+
| Conference | | Conference |
| User | | User |
| Identifier | | Identifier |
+-------+-------+ +-------+-------+
| |
| |
| |
+---------------+---------------+ +---------------+---------------+
| | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
| BFCP | | SIP Digest | | BFCP | | SIP Digest |
| 'UserID' | | Username | | 'UserID' | | Username |
+---------------+ +-------+-------+ +---------------+ +-------+-------+
Figure 4: Conference Object Mapping. Figure 5: Conference Object Mapping.
Within a Conference System, a user is identified by a single Within a Conference System, a user is identified by a single
Conference User Identifier. Any other XCON mechanisms that contain a Conference User Identifier. Any other XCON mechanisms that contain a
protocol specific user ID can be associated with the 'Conference User protocol specific user ID can be associated with the 'Conference User
Identifier', as illustrated in Figure 4. This mechanism allows Identifier', as illustrated in Figure 5. This mechanism allows
conference systems to manage and relate system wide user identities conference systems to manage and relate system wide user identities
in relation to specific Conference Objects and helps in the in relation to specific Conference Objects and helps in the
enforcement of system wide policies. enforcement of system wide policies.
6. Conferencing System Realization 6. Conferencing System Realization
XCON-compliant implementations can range from systems supporting ad- XCON-compliant implementations can range from systems supporting ad-
hoc conferences, with default behavior only, to sophisticated systems hoc conferences, with default behavior only, to sophisticated systems
with the ability to schedule re-occurring conferences (each with with the ability to schedule re-occurring conferences (each with
distinct characteristics), being integrated with external resource distinct characteristics), being integrated with external resource
skipping to change at page 17, line 26 skipping to change at page 19, line 26
the presented model and doesn't require physical copying of the the presented model and doesn't require physical copying of the
information, etc. information, etc.
Any Conference Object in a Conferencing System is created by either Any Conference Object in a Conferencing System is created by either
being explicitly cloned from an existing parent object or being being explicitly cloned from an existing parent object or being
implicitly cloned from a default system object. This document uses implicitly cloned from a default system object. This document uses
the "cloning" metaphor instead of the "inheritance" metaphor because the "cloning" metaphor instead of the "inheritance" metaphor because
it more closely fits the object replication and extension concept, it more closely fits the object replication and extension concept,
rather than data type re-usage and extension concept. rather than data type re-usage and extension concept.
By default, all the data existing in the parent object is copied to
the newly created object.
The cloning operation needs to specify whether the link between the The cloning operation needs to specify whether the link between the
parent and the child needs to be maintained in the system or not. If parent and the child needs to be maintained in the system or not. If
no link between the parent and the child exists, the objects become no link between the parent and the child exists, the objects become
independent and the rest of the cloning process doesn't apply. independent and are not impacted by any operations on the parent
object nor subject to any limitations of the parent object.
By default, all the data existing in the parent object is copied to
the newly created object.
Once the new object is created, it can be addressed by a unique Once the new object is created, it can be addressed by a unique
Conference Object URI assigned by the system, as described in Conference Object URI assigned by the system, as described in
Section 5.1 Section 5.3.1
By default, the newly created object can expand the data it contains, By default, the newly created object can expand the data it contains,
within the schema types supported by the parent, just as an within the schema types supported by the parent. It can also
independent object can. It can also restrict the read/write access restrict the read/write access to its objects. However, unless the
to its objects, but unlike an independent object, cannot relax it object is independent, it cannot relax the access relative to its
relative to its parents access. parent's access.
Any piece of data in the child object can be independently accessed Any piece of data in the child object can be independently accessed
and, by default, can be independently modified without affecting the and, by default, can be independently modified without affecting the
parent data. parent data.
On the other hand, the parent object can enforce a different policy Unless the object is independent, the parent object can enforce a
by marking certain data elements as "parent enforceable". The values different policy by marking certain data elements as "parent
of these data objects can not be changed by directly accessing the enforceable". The values of these data objects can not be changed by
child object; neither can they be expanded in the child object alone. directly accessing the child object; neither can they be expanded in
the child object alone.
In the future, XCON specifications may introduce logical In the future, XCON specifications may introduce logical
relationships, in addition to the "parent enforceable", between relationships, in addition to the "parent enforceable", between
elements being cloned from one another. elements being cloned from one another.
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | P A R E N T A | | o | P A R E N T A |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
skipping to change at page 18, line 47 skipping to change at page 21, line 4
V V V V
+---+-----------------------+ +---+-----------------------+ +---+-----------------------+ +---+-----------------------+
| p | | | p | | | p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 | | o | C H I L D 1 | | o | C H I L D 2 |
| i | | | l | | | i | | | l | |
| l | C O N F E R E N C E | | i | C O N F E R E N C E | | l | C O N F E R E N C E | | i | C O N F E R E N C E |
| i | | | c | | | i | | | c | |
| c | O B J E C T | | i | O B J E C T | | c | O B J E C T | | i | O B J E C T |
| i | | | e | | | i | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+ +-s-+-----------------------+
Figure 6: The Cloning Tree.
Figure 5: The Cloning Tree.
Using the defined cloning model and its tools, the following sections Using the defined cloning model and its tools, the following sections
show examples of how different XCON-compliant systems can be show examples of how different XCON-compliant systems can be
realized. realized.
6.2 Ad-hoc Example 6.2 Ad-hoc Example
Figure 6 illustrates how an ad-hoc conference can be created and Figure 7 illustrates how an ad-hoc conference can be created and
managed in a conferencing system. managed in a conferencing system.
A client can create a conference by establishing a call control A client can create a conference by establishing a call control
signalling channel with a Conference Factory as specified in signalling channel with a Conference Factory as specified in
Section 5.2. The Conference Factory can internally select one of the Section 5.1. The Conference Factory can internally select one of the
system supported Conference Object blueprints based on the requesting system supported Conference Object blueprints based on the requesting
client privileges and the media lines included in the SDP body. client privileges and the media lines included in the SDP body.
The selected blueprint with its default values is copied by the The selected blueprint with its default values is copied by the
server into a newly created Conference Object, referred to as an server into a newly created Conference Object, referred to as an
'Active Conference'. At this point the Conference Object becomes 'Active Conference'. At this point the Conference Object becomes
independent from its blueprint. A new Conference Object Identifier, independent from its blueprint. A new Conference Object Identifier,
a new Conference Identifier and a new focus are allocated by the a new Conference Identifier and a new focus are allocated by the
server. server.
skipping to change at page 20, line 30 skipping to change at page 22, line 30
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | A C T I V E | | o | A C T I V E |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | | | i | |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 6: Conference Ad-hoc Creation and Lifetime. Figure 7: Conference Ad-hoc Creation and Lifetime.
6.3 Advanced Example 6.3 Advanced Example
Figure 7 illustrates how a recurring conference can be specified Figure 8 illustrates how a recurring conference can be specified
according to system capabilities, scheduled, reserved, and managed in according to system capabilities, scheduled, reserved, and managed in
a conferencing system. a conferencing system.
Firstly, a client would query a Conferencing System for its Firstly, a client would query a Conferencing System for its
capabilities. This can be done by requesting a list of the capabilities. This can be done by requesting a list of the
Conference Object "blueprints" (or templates) the system supports. Conference Object "blueprints" (or templates) the system supports.
Each blueprint can contain a specific combination of capabilities and Each blueprint can contain a specific combination of capabilities and
limitations of the conference server in terms of supported media limitations of the conference server in terms of supported media
types (audio, video, text, or combinations of these), participant types (audio, video, text, or combinations of these), participant
roles, maximum number of participants of each role, availability of roles, maximum number of participants of each role, availability of
skipping to change at page 22, line 45 skipping to change at page 24, line 45
+-+-+---V-------------------+ | | +-+-+---V-------------------+ | |
| p | | | | | p | | | |
| o | C O N F E R E N C E | | | | o | C O N F E R E N C E | | |
| l | | | | | l | | | |
| i | O C C U R R E N C E | | | | i | O C C U R R E N C E | | |
| c | | | | | c | | | |
| i | | |-+ | i | | |-+
| e | |-+ | e | |-+
+-s-+-----------------------+ +-s-+-----------------------+
Figure 7: Advanced Conference Definition, Creation, and Lifetime. Figure 8: Advanced Conference Definition, Creation, and Lifetime.
6.4 Scheduling a 'Conference Object for Reservation' 6.4 Scheduling a 'Conference Object for Reservation'
Scheduling conferences forms an important part of the Conferencing Scheduling conferences forms an important part of the Conferencing
System solution. The concept of an individual Conference Instance System solution. The concept of an individual Conference Instance
and its relationship to a specific Conference Object is introduced in and its relationship to a specific Conference Object is introduced in
Section 5.2. A basic Conference Instance represents a single Section 5.2 and Section 5.3. A basic Conference Instance represents
occurrence that has a specified 'start' and 'end' time, with the a single occurrence that has a specified 'start' and 'end' time, with
times being specified relative to a single specified 'fixed' time the times being specified relative to a single specified 'fixed'
(e.g. 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system time (e.g. 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
considerations . In most advanced conferencing solutions it is considerations . In most advanced conferencing solutions it is
possible to not only schedule an individual conference instance, but possible to not only schedule an individual conference instance, but
also schedule a series of related conferences (e.g. A weekly meeting also schedule a series of related conferences (e.g. A weekly meeting
that starts on Thursday at 09.00 GMT). that starts on Thursday at 09.00 GMT).
To be able to achieve such functionality, a Conferencing System needs To be able to achieve such functionality, a Conferencing System needs
to be able to appropriately schedule and maintain Conference to be able to appropriately schedule and maintain Conference
Instances that form part of a recurring conference schedule. The Instances that form part of a recurring conference schedule. The
mechanism proposed in this document makes use of the 'Internet mechanism proposed in this document makes use of the 'Internet
Calendaring and Scheduling Core Object' specification defined in Calendaring and Scheduling Core Object' specification defined in
RFC2445[8] in union with the concepts introduced in Section 4 for the RFC2445[8] in union with the concepts introduced in Section 4 for the
purpose of achieving advanced conference scheduling capability. purpose of achieving advanced conference scheduling capability.
Figure 8 illustrates a simplified view of a Client interacting with a Figure 9 illustrates a simplified view of a Client interacting with a
Conference System. The Client is using the Conference Control Conference System. The Client is using the Conference Control
Protocol (Section 7.3) to add a new Conference Instance to the Protocol (Section 7.3) to add a new Conference Instance to the
Conference System by interfacing with the Conference Control Server. Conference System by interfacing with the Conference Control Server.
A Conference Control Protocol request contains a valid 'Conference A Conference Control Protocol request contains a valid 'Conference
Object for Reservation' and reference by value to an 'iCal' object Object for Reservation' and reference by value to an 'iCal' object
which contains scheduling information about the conference instance which contains scheduling information about the conference instance
(e.g. start time, end time). (e.g. start time, end time).
+--------------+ +-------Conferencing System-----------------+ +--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | | | Generic ICAL | | |
skipping to change at page 24, line 41 skipping to change at page 26, line 41
| |
| |
Conference Control| Conference Control|
Protocol | Protocol |
| |
+-------------+ +-------------+
| Conferencing| | Conferencing|
| Client | | Client |
+-------------+ +-------------+
Figure 8: Resource Scheduling Figure 9: Resource Scheduling
A successful creation of a Conference Instance using the Conference A successful creation of a Conference Instance using the Conference
Control Protocol results in a new 'Conference Object for Control Protocol results in a new 'Conference Object for
Reservation'. A Conference Control Protocol request is validated, Reservation'. A Conference Control Protocol request is validated,
including the associated iCal object, and the resultant 'Conference including the associated iCal object, and the resultant 'Conference
Object for Reservation' is created. The Conference Object is Object for Reservation' is created. The Conference Object is
uniquely represented within the Conference System by Conference uniquely represented within the Conference System by Conference
Object Identifier (e.g. xcon:hd87928374) as discussed in Object Identifier (e.g. xcon:hd87928374) as discussed in
Section 5.1. The unique URI is returned to the client and can be Section 5.3. The unique URI is returned to the client and can be
used to reference the 'Conference Object for Reservation' used to reference the 'Conference Object for Reservation'
representation if any future manipulations are required (e.g. Alter representation if any future manipulations are required (e.g. Alter
start time) using a Conference Control Protocol. start time) using a Conference Control Protocol.
The previous example explains how a client creates a basic The previous example explains how a client creates a basic
'Conference Object for Reservation' using an iCal reference in 'Conference Object for Reservation' using an iCal reference in
association with a Conference Control Protocol. Figure 8 can also be association with a Conference Control Protocol. Figure 9 can also be
applied when explaining how a series of Conferences are scheduled in applied when explaining how a series of Conferences are scheduled in
the system. The description is almost identical with the exception the system. The description is almost identical with the exception
that the iCal definition that is included in a Conference Control that the iCal definition that is included in a Conference Control
Request represents a series of recurring Conference Instances (e.g. Request represents a series of recurring Conference Instances (e.g.
conference start time, end time, occur weekly). The Conference conference start time, end time, occur weekly). The Conference
system will treat this request the same as the first example. The system will treat this request the same as the first example. The
protocol request will be validated, along with the associated iCal protocol request will be validated, along with the associated iCal
object, and the 'Conference Object for Reservation' will be created. object, and the 'Conference Object for Reservation' will be created.
The 'Conference Object for Reservation' and the Conference Object ID The 'Conference Object for Reservation' and the Conference Object ID
created for this example represent the entire series of recurring created for this example represent the entire series of recurring
Conference Instances rather than a single Conference. If the client Conference Instances rather than a single Conference. If the client
uses the Conference Object ID provided and a Conference Control uses the Conference Object ID provided and a Conference Control
Protocol to adjust the 'Conference Object for Reservation', every Protocol to adjust the 'Conference Object for Reservation', every
Conference Instance in the series will be altered, including all Conference Instance in the series will be altered. This includes all
future occurrences. future occurrences, such as a conference scheduled as an infinite
series, subject to the limitations of the available calendaring
interface.
A Conferencing System that supports the scheduling of a series of A Conferencing System that supports the scheduling of a series of
Conference Instances should also be able to support manipulation Conference Instances should also be able to support manipulation
within a series range. A good example might be that a 'Conference within a series range. A good example might be that a 'Conference
Object for Reservation' has been scheduled to occur every Monday at Object for Reservation' has been scheduled to occur every Monday at
09.00 GMT. For the next three weeks only, the meeting has been 09.00 GMT. For the next three weeks only, the meeting has been
altered to occur at 10.00 GMT in an alternative venue. With altered to occur at 10.00 GMT in an alternative venue. With
Figure 8 in mind, the client will construct a Conference Control Figure 9 in mind, the client will construct a Conference Control
request whose purpose is to modify the existing 'Conference Object request whose purpose is to modify the existing 'Conference Object
for Reservation' representing the recurring Conference Instance. The for Reservation' representing the recurring Conference Instance. The
Client will include the Conference Object ID provided by the Client will include the Conference Object ID provided by the
Conference System to explicitly reference the 'Conference Object for Conference System to explicitly reference the 'Conference Object for
Reservation' within the Conference System. A Conference Control Reservation' within the Conference System. A Conference Control
request will contain all the required changes to the 'Conference request will contain all the required changes to the 'Conference
Object for Reservation'(e.g. Change of venue). The Conference Object for Reservation'(e.g. Change of venue). The Conference
System matches the incoming request to the existing 'Conference System matches the incoming request to the existing 'Conference
Object for Reservation' but identifies that the associated iCal Object for Reservation' but identifies that the associated iCal
object only refers to a range of the existing series. The Conference object only refers to a range of the existing series. The Conference
skipping to change at page 26, line 39 skipping to change at page 28, line 41
A Conferencing System is responsible for implementing a Conference A Conferencing System is responsible for implementing a Conference
Notification Service. The Conference Notification Service provides Notification Service. The Conference Notification Service provides
updates about the Conference Instance state to authorized parties updates about the Conference Instance state to authorized parties
(e.g. participants) according to [11]. (e.g. participants) according to [11].
The Conference User Identifier and associated Role are used by the The Conference User Identifier and associated Role are used by the
conferencing system to filter the notifications such that they conferencing system to filter the notifications such that they
contain only information that is allowed to be sent to that user. contain only information that is allowed to be sent to that user.
7.3 Conference Control Protocols 7.3 Conference Control Protocol
The XCON working group will develop a protocol or a set of protocols The XCON working group charter includes the development of a protocol
for controlling the state of a Conference Object and for retrieving or a set of protocols for controlling the state of a Conference
its state. The nature of this protocol is currently under discussion Object and for retrieving its state. The nature of this protocol is
in the XCON working group. The proposals span from data manipulation currently under discussion in the XCON working group. The proposals
(management-like) protocols to semantic-oriented. Several of the span from data manipulation (management-like) protocols (CPCP and
proposed protocols are detailed in the sections below. Among other NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the
mentioned candidates are SOAP and HTML FORMS. The following proposed protocols are in the sections below. The following
paragraphs summarize the fundamental issues around the selection of paragraphs summarize the fundamental issues around the selection of
the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG
mailing list]. mailing list].
It is recognized that semantic manipulations make for a cleaner It is recognized that semantic manipulations make for a cleaner
protocol design, with the disadvantage that extensions to the protocol design, with the disadvantage that extensions to the
underlying data model require extensions to the protocol used to underlying data model require extensions to the protocol used to
manipulate it. Syntactic manipulations allow for extensions to the manipulate it. Syntactic manipulations allow for extensions to the
data model without requiring protocol extensions, with the data model without requiring protocol extensions, with the
disadvantage that the server generally has to infer intent from data disadvantage that the server generally has to infer intent from data
skipping to change at page 27, line 23 skipping to change at page 29, line 24
It is worth noting that one portion of the data to be manipulated, It is worth noting that one portion of the data to be manipulated,
the Common Conference Information, will not be extended, and would the Common Conference Information, will not be extended, and would
naturally lend itself to semantic manipulation. Another part of the naturally lend itself to semantic manipulation. Another part of the
data, the Conference Template, is intended to be extended, and would data, the Conference Template, is intended to be extended, and would
naturally lend itself to syntactic manipulation. However, there has naturally lend itself to syntactic manipulation. However, there has
been a stated desire to use a single protocol (and presumably a been a stated desire to use a single protocol (and presumably a
single mode of operation within this protocol) to manipulate all single mode of operation within this protocol) to manipulate all
conference object state (common and template). conference object state (common and template).
The third statement in the paragraph above makes the first two The third statement in the paragraph above makes the first two
solution options mutually exclusive; the XCON working group needs to solution options mutually exclusive. A proposal was made that by
determine which of the three statements above is least important to allowing more than one protocol, a hybrid approach could be taken
the working group. such that CPCP and CSCP can both be used, since they are based on
other protocols that are likely to be supported by the clients (XCAP
and BFCP, respectively). However, the very rough consensus of the WG
supports a single protocol for Conference Control and SOAP has most
recently been put forth as that protocol. A basic overview of SOAP
in the context of Conference control is provided in Section 7.3.5
7.3.1 CPCP 7.3.1 CPCP
A Conference Policy Control Protocol (CPCP) is a data manipulation A Conference Policy Control Protocol (CPCP) is a data manipulation
protocol being proposed as a standard means of storing and protocol being proposed as a standard means of storing and
manipulating the conference policy. According to CPCP, the manipulating the conference policy. According to CPCP, the
conference policy is comprised of the rules associated with a conference policy is comprised of the rules associated with a
specific Conference Instance. Requirements for the CPCP are defined specific Conference Instance. Requirements for the CPCP are defined
in the CPCP Requirements document [13]. The Conference Policy in the CPCP Requirements document [13]. The Conference Policy
Control Protocol document [17] defines the XML Schema for the Control Protocol document [17] defines the XML Schema for the
skipping to change at page 29, line 13 skipping to change at page 31, line 17
interface (API). interface (API).
NETCONF is proposed as the mechanism for object content manipulation NETCONF is proposed as the mechanism for object content manipulation
and state retrieval for the XCON data. NETCONF provides a flexible and state retrieval for the XCON data. NETCONF provides a flexible
configuration retrieval mechanism, with extensibility. It allows for configuration retrieval mechanism, with extensibility. It allows for
incremental configuration and commits. NETCONF supports stored incremental configuration and commits. NETCONF supports stored
configurations (e.g. for startup, running, etc.). It also supports configurations (e.g. for startup, running, etc.). It also supports
XPath and subtree filtering. With NETCONF, there are no constraints XPath and subtree filtering. With NETCONF, there are no constraints
on the configuration content. on the configuration content.
7.3.5 SOAP
The SOAP protocol is fundamentally an XML messaging scheme, capable
of supporting remote procedure calls. SOAP defines a simple message
format composed of a "header" and a "body" contained within an
"envelope". The "header" contains meta-information relating to the
message, and can be used to indicate such things as store-and-forward
behaviour or transactional characteristics. In addition, SOAP
encoding is optimized for ease of automated deserialization.
SOAP is proposed as the mechanism for object content manipulation and
state retrieval for the XCON data. In general, SOAP is a good fit
for Conference Control, essentially because of its remote procedure
call characteristics and its inherently synchronous and client-driven
nature.
7.4 Floor Control 7.4 Floor Control
[Editor's Note: This text still requires further updating to reflect [Editor's Note: This text still requires further updating to reflect
new model and pending new WG agreements. Amongst the things TODO new model and pending new WG agreements. Amongst the things TODO
are: are:
1. Need to be able to fetch from the Conference Object the 1. Need to be able to fetch from the Conference Object the
credentials required for BFCP. This includes the conference id, user credentials required for BFCP. This includes the conference id, user
id, and password. id, and password.
skipping to change at page 30, line 9 skipping to change at page 32, line 29
access to additional information. This information associates Floor access to additional information. This information associates Floor
Control interactions with the appropriate Floor instance. Once a Control interactions with the appropriate Floor instance. Once a
connection has been established and authenticated (see [16] for connection has been established and authenticated (see [16] for
authentication details), a specific floor control message requires authentication details), a specific floor control message requires
detailed information to uniquely identify a user, a floor and a detailed information to uniquely identify a user, a floor and a
conference. This information, defined in the next set of bullet conference. This information, defined in the next set of bullet
points, can be obtained using methods such as negotiation using the points, can be obtained using methods such as negotiation using the
SDP offer/answer exchange on the signalling interface with the focus: SDP offer/answer exchange on the signalling interface with the focus:
o Conference Object ID - Each Conference Object has a unique o Conference Object ID - Each Conference Object has a unique
identifier per Section 5.1, obtained from the Conference server, identifier per Section 5.3.1, obtained from the Conference
which MUST be included in all Floor messages. When the SDP model server, which MUST be included in all Floor messages. When the
is used as described in [24] this identifier maps to the 'confid' SDP model is used as described in [24] this identifier maps to the
SDP attribute. 'confid' SDP attribute.
o Conference User Identifier - Each user has a unique identifier o Conference User Identifier - Each user has a unique identifier
within the Conference Object per Section 5.3, obtained from the within the Conference Object per Section 5.4, obtained from the
Conference server, which MUST be included in all Floor messages. Conference server, which MUST be included in all Floor messages.
When using SDP offer/answer exchange to negotiate a Floor control When using SDP offer/answer exchange to negotiate a Floor control
connection with the focus using the call control signalling connection with the focus using the call control signalling
interface, the unique conference identifier is contained in the interface, the unique conference identifier is contained in the
'userid' SDP attribute, as defined in [24] 'userid' SDP attribute, as defined in [24]
o Floor ID - A media session with a Conferencing System can have any o Floor ID - A media session with a Conferencing System can have any
number of 'Floors' (0 or more) that are represented by a unique number of 'Floors' (0 or more) that are represented by a unique
identifier within the Conference Instance (as represented by identifier within the Conference Instance (as represented by
Conference ID). When using SDP offer/answer exchange to negotiate Conference ID). When using SDP offer/answer exchange to negotiate
a Floor control connection with the focus using the call control a Floor control connection with the focus using the call control
skipping to change at page 31, line 38 skipping to change at page 34, line 8
For example, "Conferencing for SIP User Agents" [15] shows how SIP For example, "Conferencing for SIP User Agents" [15] shows how SIP
with REFER can be used to achieve this functionality. with REFER can be used to achieve this functionality.
In order to perform richer conference control a user client needs to In order to perform richer conference control a user client needs to
implement a conference control protocol client. By using a implement a conference control protocol client. By using a
conference control protocol, the client can affect its own state, conference control protocol, the client can affect its own state,
state of other participants, and state of various resources (such as state of other participants, and state of various resources (such as
media mixers) which may indirectly affect the state of any of the media mixers) which may indirectly affect the state of any of the
conference participants. conference participants.
Figure 10 provides an example of one client "Alice" impacting the Figure 11 provides an example of one client "Alice" impacting the
state of another client "Bob". This example assumes an established state of another client "Bob". This example assumes an established
conference. In this example, "Alice" wants to add "Bob" to the conference. In this example, "Alice" wants to add "Bob" to the
conference. conference.
It should be noted that not all entities impacted by the request are It should be noted that not all entities impacted by the request are
shown in the diagram (e.g. Focus), but rather the emphasis is on the shown in the diagram (e.g. Focus), but rather the emphasis is on the
new entities introduced by XCON. new entities introduced by XCON.
+--------------------------------+ +--------------------------------+
| Conference System | | Conference System |
skipping to change at page 32, line 25 skipping to change at page 34, line 37
"Bud" | ' ' '| "Bud" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ | | Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
"Bob" "Bob"
Figure 9: Client Manipulation of Conference - Add a party Figure 10: Client Manipulation of Conference - Add a party
Upon receipt of the Conference Control Protocol request to "add" a Upon receipt of the Conference Control Protocol request to "add" a
party ("Bob") in the specific conference as identified by the party ("Bob") in the specific conference as identified by the
Conference Object ID, the Conference System ensures that "Alice" has Conference Object ID, the Conference System ensures that "Alice" has
the appropriate authority based on the policies associated with that the appropriate authority based on the policies associated with that
specific Conference Object to perform the operation. The Conference specific Conference Object to perform the operation. The Conference
System must also determine whether "Bob" is already a user of this System must also determine whether "Bob" is already a user of this
Conference System or whether he is a new user. Conference System or whether he is a new user.
If "Bob" is a new user for this conference system, a Conference User If "Bob" is a new user for this conference system, a Conference User
skipping to change at page 33, line 16 skipping to change at page 35, line 31
sending re-INVITE with new SDP content using SIP only. This kind of sending re-INVITE with new SDP content using SIP only. This kind of
operations is called "1st party signalling" and they do not affect operations is called "1st party signalling" and they do not affect
the state of other participants in the conference. the state of other participants in the conference.
In order to perform richer conference control a user client needs to In order to perform richer conference control a user client needs to
implement a conference control protocol client. By using a implement a conference control protocol client. By using a
conference control protocol, the client can manipulate the state of conference control protocol, the client can manipulate the state of
various resources, such as media mixers, which may indirectly affect various resources, such as media mixers, which may indirectly affect
the state of any of the conference participants. the state of any of the conference participants.
Figure 10 provides an example of one client "Alice" impacting the Figure 11 provides an example of one client "Alice" impacting the
media state of another client "Bob". This example assumes an media state of another client "Bob". This example assumes an
established conference. In this example, the Client, "Alice" whose established conference. In this example, the Client, "Alice" whose
Role is "moderator" of the conference, wants to mute "Bob" on a Role is "moderator" of the conference, wants to mute "Bob" on a
medium-size multi-party conference, as his device is not muted (and medium-size multi-party conference, as his device is not muted (and
he's obviously not listening to the call) and background noise in he's obviously not listening to the call) and background noise in
his office environment is disruptive to the conference. his office environment is disruptive to the conference.
It should be noted that only entities impacted by the request are It should be noted that only entities impacted by the request are
shown in the diagram (e.g. there is no Focus shown). shown in the diagram (e.g. there is no Focus shown).
skipping to change at page 34, line 4 skipping to change at page 36, line 23
| +-----------+ +-------+ || | +-----------+ +-------+ ||
| |"Alice"| || | |"Alice"| ||
| ' ' '| | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| || | |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ || | Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | || +--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+| | |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ | | Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+ +--------+ +--------------------------------+
Figure 10: Client Manipulation of Conference - Mute a party
Figure 11: Client Manipulation of Conference - Mute a party
Upon receipt of the Conference Control Protocol request to "mute" a Upon receipt of the Conference Control Protocol request to "mute" a
party ("Bob") in the specific conference as identified by the party ("Bob") in the specific conference as identified by the
Conference Object ID, the Conference Server ensures that "Alice" has Conference Object ID, the Conference Server ensures that "Alice" has
the appropriate authority based on the policies associated with that the appropriate authority based on the policies associated with that
specific Conference Object to perform the operation. "Bob's" status specific Conference Object to perform the operation. "Bob's" status
is marked as "recvonly" and the Conference Template of the Conference is marked as "recvonly" and the Conference Template of the Conference
Object (if included) is updated to reflect that "Bob's" media is not Object (if included) is updated to reflect that "Bob's" media is not
to be "mixed" with the conference media. to be "mixed" with the conference media.
Depending upon the policies, other participants (including "Bob") may Depending upon the policies, other participants (including "Bob") may
be notified of this change via the Conference Notification Service. be notified of this change via the Conference Notification Service.
8.3 Sidebar Manipulations 8.3 Sidebar Manipulations
A sidebar can be viewed as a separate Conference instance that only A sidebar can be viewed as a separate Conference instance that only
exits within the context of a parent Conference instance. Although exists within the context of a parent Conference instance. Although
viewed as an independent Conference instance, it can not exist viewed as an independent Conference instance, it can not exist
without a parent. A Sidebar is created using the same mechanisms without a parent. A Sidebar is created using the same mechanisms
employed for a standard conference. A Conference object representing employed for a standard conference as described in Section 6.1 A
a Sidebar is created using the mechanism defined in this document. Conference object representing a Sidebar is created by cloning the
Once created and instantiated with relevant information, a Conference parent associated with the existing conference, copying the
System manages and enforces appropriate localized restrictions on the information from the parent and updating any information specific to
Sidebar Conference Object e.g. No members from outside the parent the sidebar. A Sidebar Conference Object is implicitly linked to the
conference instance can not join, Sidebar conference can not exist if parent Conference Object (i.e. it is not an independent object). A
parent Conference is terminated etc. A Sidebar Conference Object is Conference System manages and enforces the parent and appropriate
implicitly linked to the parent Conference Object. The Sidebar localized restrictions on the Sidebar Conference Object (e.g. No
mechanism uses the umbrella approach for association of XCON members from outside the parent conference instance can join, Sidebar
Conference Object Identifiers as introduced in other sections of this conference can not exist if parent Conference is terminated, etc.).
document. The Sidebar mechanism uses the umbrella approach for association of
XCON Conference Object Identifiers as introduced in other sections of
this document.
+--------------+ +--------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------+ +--------------+
| |
| |
| |
+---------------------+---------------------+ +---------------------+---------------------+
| | | | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar | | Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference | | Conference | | Conference | | Conference |
| Object | | Object | | Object | | Object | | Object | | Object |
| Identifier | | Identifier | | Identifier | | Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+ +-------+-------+ +-------+-------+ +---------------+
Figure 11: Conference Object Mapping. Figure 12: Conference Object Mapping.
Figure 11 illustrates the relationship between a Conference Object Figure 12 illustrates the relationship between a Conference Object
and associated Sidebar Conference Objects within a Conference System. and associated Sidebar Conference Objects within a Conference System.
Each Sidebar Conference Object has a unique Conference Object Each Sidebar Conference Object has a unique Conference Object
Identifier as described in Section 5.1. The main Conference Object Identifier as described in Section 5.3.1. The main Conference Object
Identifier acts as a top level identifier for associated Sidebars. Identifier acts as a top level identifier for associated Sidebars.
A sidebar Conference Object Identifier follows many of the concepts A sidebar Conference Object Identifier follows many of the concepts
outlined in the Cloning tree model described in Section 6.1. A outlined in the Cloning tree model described in Section 6.1. A
Sidebar Conference Object contains a subset of members from the Sidebar Conference Object contains a subset of members from the
original Conference object. Properties of the Sidebar Conference original Conference object. Properties of the Sidebar Conference
Object can be manipulated by a Conference Control Protocol Object can be manipulated by a Conference Control Protocol
(Section 7.3 using the unique Conference Object identifier for the (Section 7.3 using the unique Conference Object identifier for the
sidebar. It is also possible for the top level Conference Object to sidebar. It is also possible for the top level Conference Object to
enforce policy on the Sidebar Object (similar to parent enforceable enforce policy on the Sidebar Object (similar to parent enforceable
skipping to change at page 38, line 39 skipping to change at page 40, line 49
center conference situations. center conference situations.
11. IANA Considerations 11. IANA Considerations
This is an informational draft, with no IANA considerations required. This is an informational draft, with no IANA considerations required.
12. Acknowledgements 12. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal, Cullen
Cullen Jennings for providing input for the "Security Considerations" Jennings for providing input for the "Security Considerations"
section. section and Keith Lantz for his careful reviews and constructive
input.
13. Open Issues 13. Open Issues
Several open issues are identified in the body of the document. This Several open issues are identified in the body of the document. This
list is intended as a summary to facilitate the tracking of open list is intended as a summary to facilitate the tracking of the
issues that require WG input. primary open issues that require WG input.
1. DP4. Object Schema structure and Template definition. 1. DP4. Object Schema structure and Template definition.
Clarification of Templates versus Blueprints and details of XML Clarification of Templates versus Blueprints and details of XML
schema. schema.
2. DP5. CCP Protocol. 2. DP5. CCP Protocol.
14. Changes since last Version 14. Changes since last Version
Changes from WG 00 to 01::
- Section 2 (Conventions and Terminology). Slight modifications to
definitions of Call (control) signalling, Conference Identifer,
Conference Instance, Conference Object.
- Section 2 (Conventions and Terminology).Renaming of term
"Registered Template Definition" to "Registered Conference Document"
(per agreement at interim meeting).
- Section 3 (Next to the last paragraph on the media model).
Clarified the text such that it doesn't read that the focus performs
media mixing. Changed "focus" to "media mixer controlled by the
focus" in the 2nd sentence and "performed" to "controlled" in the
4th.
- Section 5. Rearranged the sub-sections a bit for better flow.
First describe the Conference ID, then the Conference Instance,
followed by the Conference Object, with the Conference Object
Identifer described in a subsection of the Conference Object
section. Added a diagram showing the relationship between Conference
Identifer/Focus and Conference Object Identifier, within the context
of a Conference Instance to the Conference Object section.
- Section 6.1 (Cloning Tree). Rewording to clarify which operations
apply to independent objects (and non-independent).
- Section 6.3 (Advanced Example). Added additional text with regards
to future conferences, introducing the concept of infinite series
(which would be limited by calendaring interface).
- Section 7.3 (Conference Control Protocol). Updated to include
reference to SOAP option.
- Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit
about the XCON FW constructs used.
Changes from individual 02 to WG 00: Changes from individual 02 to WG 00:
- few minor editorial changes - few minor editorial changes
- Section 2. Removed second sentence of definition of Conference - Section 2. Removed second sentence of definition of Conference
ID, as that's now included/described in context in new Identifier ID, as that's now included/described in context in new Identifier
section. section.
- Section 3. Clarified that TBD in Figure 1 is "Conference Control - Section 3. Clarified that TBD in Figure 1 is "Conference Control
Protocol" (per Keith's comment to be more explicit). Protocol" (per Keith's comment to be more explicit).
skipping to change at page 40, line 49 skipping to change at page 43, line 51
[7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[8] Dawson, F. and Stenerson, D., "Internet Calendaring and [8] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445, Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998. November 1998.
[9] Rosenberg, J., "A Framework for Conferencing with the Session [9] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-04 (work in draft-ietf-sipping-conferencing-framework-05 (work in
progress), February 2005. progress), May 2005.
[10] Levin, O. and R. Even, "High Level Requirements for Tightly [10] Levin, O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing", Coupled SIP Conferencing",
draft-ietf-sipping-conferencing-requirements-01 (work in draft-ietf-sipping-conferencing-requirements-01 (work in
progress), October 2004. progress), October 2004.
[11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-10 (work in progress), draft-ietf-sipping-conference-package-12 (work in progress),
March 2005. July 2005.
[12] Schulzrinne, H., "Requirements for Floor Control Protocol", [12] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-03 (work in progress), draft-ietf-xcon-floor-control-req-03 (work in progress),
January 2005. January 2005.
[13] Koskelainen, P. and H. Khartabil, "Requirements for Conference [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference
Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
progress), August 2004. progress), August 2004.
[14] Even, R. and N. Ismail, "Conferencing Scenarios", [14] Even, R. and N. Ismail, "Conferencing Scenarios",
draft-ietf-xcon-conference-scenarios-04 (work in progress), draft-ietf-xcon-conference-scenarios-04 (work in progress),
April 2005. April 2005.
[15] Johnston, A. and O. Levin, "Session Initiation Protocol Call [15] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-06 (work in progress), draft-ietf-sipping-cc-conferencing-07 (work in progress),
November 2004. June 2005.
[16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-03 (work in progress), January 2005. draft-ietf-xcon-bfcp-04 (work in progress), May 2005.
[17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", [17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004. draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[18] Khartabil, H., "An Extensible Markup Language (XML) [18] Khartabil, H., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usages for Conference Configuration Access Protocol (XCAP) Usages for Conference
Policy Manipulation and Conference Policy Privelges Policy Manipulation and Conference Policy Privelges
Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress), Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress),
October 2004. October 2004.
skipping to change at page 42, line 30 skipping to change at page 45, line 30
[25] Campbell, B., "The Message Session Relay Protocol", [25] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress), draft-ietf-simple-message-sessions-10 (work in progress),
February 2005. February 2005.
[26] Jennings, C. and A. Roach, "Conference State Change Protocol [26] Jennings, C. and A. Roach, "Conference State Change Protocol
(CSCP)", draft-jennings-xcon-cscp-00 (work in progress), (CSCP)", draft-jennings-xcon-cscp-00 (work in progress),
February 2005. February 2005.
[27] Enns, R., "NETCONF Configuration Protocol", [27] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-06 (work in progress), April 2005. draft-ietf-netconf-prot-07 (work in progress), June 2005.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2380 Performance Drive 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/