draft-ietf-xcon-common-data-model-25.txt   draft-ietf-xcon-common-data-model-26.txt 
XCON O. Novo XCON O. Novo
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: October 17, 2011 D. Morgan Expires: October 21, 2011 D. Morgan
Fidelity Investments Fidelity Investments
J. Urpalainen J. Urpalainen
Nokia Nokia
April 15, 2011 April 19, 2011
Conference Information Data Model for Centralized Conferencing (XCON) Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-25.txt draft-ietf-xcon-common-data-model-26.txt
Abstract Abstract
[RFC5239] defines the idea of a centralized conferencing (XCON) as an [RFC5239] defines the idea of a centralized conferencing (XCON) as an
association of participants with a central focus. The state of a association of participants with a central focus. The state of a
conference is represented by a conference object. This document conference is represented by a conference object. This document
defines an Extensible Markup Language (XML)-based conference defines an Extensible Markup Language (XML)-based conference
information data model to be used for conference objects. A information data model to be used for conference objects. A
conference information data model is designed to convey information conference information data model is designed to convey information
about the conference and about participation in the conference. The about the conference and about participation in the conference. The
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 17, 2011. This Internet-Draft will expire on October 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 27 skipping to change at page 5, line 27
conference during each of its various stages (e.g., created/creation, conference during each of its various stages (e.g., created/creation,
reserved/reservation, active/activation, completed/completion). A reserved/reservation, active/activation, completed/completion). A
conference object can be manipulated using a conference control conference object can be manipulated using a conference control
protocol at a conference server. The conference object represents a protocol at a conference server. The conference object represents a
particular instantiation of a conference information data model. particular instantiation of a conference information data model.
Consequently, conference objects use the XML format defined in this Consequently, conference objects use the XML format defined in this
document. document.
A conference object contains the core information of a conference A conference object contains the core information of a conference
(i.e., capabilities, membership, call control signaling, media, etc.) (i.e., capabilities, membership, call control signaling, media, etc.)
and specifies by whom, and in which way that information can be and specifies by whom, and in which way, that information can be
manipulated. manipulated.
Figure 1 shows the logical functional elements of a conference server Figure 1 shows the logical functional elements of a conference server
as defined by the Centralized Conferencing Framework [RFC5239]. They as defined by the Centralized Conferencing Framework [RFC5239]. They
are a Conference Control Server, a Floor Control Server, a number of are a Conference Control Server, a Floor Control Server, a number of
Foci, and a Notification Service. A conference control protocol Foci, and a Notification Service. A conference control protocol
provides the interface between a conference control client and the provides the interface between a conference control client and the
conference control server. A floor control protocol (e.g., BFCP conference control server. A floor control protocol (e.g., BFCP
[RFC4582]) provides the interface between a floor control client and [RFC4582]) provides the interface between a floor control client and
the floor control server. A call signaling protocol (e.g., SIP, the floor control server. A call signaling protocol (e.g., SIP,
skipping to change at page 11, line 22 skipping to change at page 11, line 22
whole. The <users> element contains a set of <user> child whole. The <users> element contains a set of <user> child
elements, each describing a single participant in the conference. elements, each describing a single participant in the conference.
o If a participant in the main conference joins a sidebar, a new o If a participant in the main conference joins a sidebar, a new
element is created in the conference referenced from the element is created in the conference referenced from the
<sidebars-by-ref> element or under one of the <sidebars-by-val> <sidebars-by-ref> element or under one of the <sidebars-by-val>
elements. elements.
Note that some of the elements described above such <conference- Note that some of the elements described above such <conference-
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by- info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
val> are not defined in the data model but are defined in the data val> are not defined in the data model in this specification but are
format of [RFC4575]. We describe them here because they are part of defined in the data format of [RFC4575]. We describe them here
the basic structure of the data model. because they are part of the basic structure of the data model.
4. Data Model Definition 4. Data Model Definition
The following non-normative diagram shows the structure of conference The following non-normative diagram shows the structure of conference
object documents. The operator "!" preceding an element indicates object documents. The operator "!" preceding an element indicates
that the element is mandatory in the data model. The operator "*" that the element is mandatory in the data model. The operator "*"
following an element indicates that the element is introduced and following an element indicates that the element is introduced and
defined in this document. That is, elements without a "*" have defined in this document. That is, elements without a "*" have
already been defined in [RFC4575]. already been defined in [RFC4575].
skipping to change at page 15, line 20 skipping to change at page 15, line 20
| | | | | |
| ... ... | ... ...
Figure 3: Non-normative diagram Figure 3: Non-normative diagram
The following sections describe these elements in detail. The full The following sections describe these elements in detail. The full
Relax NG schema is provided Section 5. Relax NG schema is provided Section 5.
4.1. <conference-info> 4.1. <conference-info>
A conference object document begins with the root element tag A conference object document begins with the root element
<conference-info>, which is defined in [RFC4575]. The <conference- <conference-info>, which is defined in [RFC4575]. The <conference-
info> attributes are described in [RFC4575]. Note that the info> attributes are described in [RFC4575]. Note that the
<conference-info> element does not have the attributes 'state' and <conference-info> element does not have the attributes 'state' and
'version' defined in [RFC4575] for this element because these 'version' defined in [RFC4575] for this element because these
attributes only apply to notification mechanisms. attributes only apply to notification mechanisms.
In addition, [RFC4575] defines an 'entity' attribute that contains In addition, [RFC4575] defines an 'entity' attribute that contains
the conference object identifier (XCON-URI) that identifies the the conference object identifier (XCON-URI) that identifies the
conference being described in the document. conference being described in the document.
skipping to change at page 17, line 29 skipping to change at page 17, line 29
the conference. The iCalendar object components are defined in the conference. The iCalendar object components are defined in
[RFC5545]. [RFC5545].
o <mixing-start-offset>: The <mixing-start-offset> child element o <mixing-start-offset>: The <mixing-start-offset> child element
specifies when the conference media mixing starts before the specifies when the conference media mixing starts before the
conference starts. If the <mixing-start-offset> element is not conference starts. If the <mixing-start-offset> element is not
present, it indicates that the conference media mixing starts present, it indicates that the conference media mixing starts
immediately. The <mixing-start-offset> has the mandatory immediately. The <mixing-start-offset> has the mandatory
'required-participant' attribute. This attribute contains one of 'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator", the following values: "none", "administrator", "moderator",
"user", "observer", and "participant". The roles semantic "user", "observer", and "participant". The roles' semantic
definition is out of the scope of this document and is subject to definitions are out of the scope of this document and is subject
future policy documents. More values can be specified in the to future policy documents. More values can be specified in the
future. The 'required-participant' attribute allows a privileged future. The 'required-participant' attribute allows a privileged
user to define when media mixing starts based on the latter of the user to define when media mixing starts based on the latter of the
mixing start time, and the time the first participant arrives. If mixing start time, and the time the first participant arrives. If
the value is set to "none'", mixing starts according to the mixing the value is set to "none'", mixing starts according to the mixing
start time. start time.
o <mixing-end-offset>: The <mixing-end-offset> child element o <mixing-end-offset>: The <mixing-end-offset> child element
specifies the time a conference media mixing stops after the specifies the time conference media mixing stops after the
conference stops. If the <mixing-end-offset> element is not conference stops. If the <mixing-end-offset> element is not
present, it indicates that the conference occurrence is not present, it indicates that the conference occurrence is not
bounded. The <mixing-end-offset> element has the mandatory bounded. The <mixing-end-offset> element has the mandatory
'required-participant' attribute. This attribute contains one of 'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator", the following values: "none", "administrator", "moderator",
"observer", "user", and "participant". More values can be "observer", "user", and "participant". More values can be
specified in the future. The 'required-participant' attribute specified in the future. The 'required-participant' attribute
allows a privileged user to define when media mixing ends based on allows a privileged user to define when media mixing ends based on
the earlier of the <mixing-end-offset>, and the time the last the earlier of the <mixing-end-offset>, and the time the last
participant leaves. If the value is set to "none", mixing stops participant leaves. If the value is set to "none", mixing stops
skipping to change at page 19, line 32 skipping to change at page 19, line 32
o The <display-text> element is described in section 5.3.4 of o The <display-text> element is described in section 5.3.4 of
[RFC4575]. [RFC4575].
o The <status> element is described in section 5.3.4 of [RFC4575]. o The <status> element is described in section 5.3.4 of [RFC4575].
o The child element <mixing-mode> describes a default scheduling o The child element <mixing-mode> describes a default scheduling
policy by which the mixer will build the outgoing stream from the policy by which the mixer will build the outgoing stream from the
incoming streams. Note that this policy is different than the incoming streams. Note that this policy is different than the
policy describing the floors for each media. The <mixing-mode> policy describing the floors for each media. The <mixing-mode>
child element MUST contain one and only one of the "Moderator- child element MUST contain one and only one of the "Moderator-
controlled", "FCFS", and "Automatic" values indicating the default controlled", "FCFS", and "Automatic" values, indicating the
algorithm to use with every media stream. The "Moderator- default algorithm to use with every media stream. The "Moderator-
controlled" value indicates that the moderator of the conference, controlled" value indicates that the moderator of the conference,
controls the media stream policy. The "FCFS" value indicates a controls the media stream policy. The "FCFS" value indicates a
'first-come-first-served' policy. The "Automatic" value means the 'first-come-first-served' policy. The "Automatic" value means the
mixer choose the best scheduling policy for the conference. mixer choose the best scheduling policy for the conference.
o The <codecs> element specifies the allowed codecs in the o The <codecs> element specifies the allowed codecs in the
conference. It has an attribute 'decision' that specifies if the conference. It has an attribute 'decision' that specifies if the
focus decides the common codec automatically or needs the approval focus decides the common codec automatically or needs the approval
of the moderator of the conference ("automatic", "moderator- of the moderator of the conference ("automatic", "moderator-
controlled"). The <codecs> element contains <codec> elements. A controlled"). The <codecs> element contains <codec> elements. A
skipping to change at page 22, line 38 skipping to change at page 22, line 38
The <active> child element is explained in [RFC4575], section 5.5.2. The <active> child element is explained in [RFC4575], section 5.5.2.
4.4.4. <locked> 4.4.4. <locked>
The <locked> child element is explained in [RFC4575], section 5.5.3. The <locked> child element is explained in [RFC4575], section 5.5.3.
4.5. <floor-information> 4.5. <floor-information>
The <floor-information> element contains the <conference-ID>, <allow- The <floor-information> element contains the <conference-ID>, <allow-
floor-events>, <floor-request-handling>, and <conference-floor- floor-events>, <floor-request-handling>, and <conference-floor-
policy> child elements. Other elements from different namespaces MAY policy> child elements. The absence of this element from an XML
be present for the purposes of extensibility. The absence of this document indicates that the conference does not have a floor.
element from an XML document indicates that the conference does not
have a floor.
4.5.1. <conference-ID> 4.5.1. <conference-ID>
The <conference-ID> represents a conference instance within floor The <conference-ID> represents a conference instance within floor
control. When BFCP serves as the floor control protocol, the control. When BFCP serves as the floor control protocol, the
<conference-ID> is a 32-bit BFCP conference identifier defined in <conference-ID> is a 32-bit BFCP conference identifier defined in
[RFC4582] section 5.1. Note that when created within the [RFC4582] section 5.1. Note that when created within the
conferencing system, there is a 1:1 mapping between this conferencing system, there is a 1:1 mapping between this
<conference-ID> and the unique conference object Identifier (XCON- <conference-ID> and the unique conference object Identifier (XCON-
URI). URI).
skipping to change at page 25, line 34 skipping to change at page 25, line 34
conference that controls how users are authenticated into the conference that controls how users are authenticated into the
conference, using a mechanism of the conference's choosing. Since a conference, using a mechanism of the conference's choosing. Since a
variety of signaling protocols are possible, a variety of variety of signaling protocols are possible, a variety of
authentication mechanism - determined by every individual conference authentication mechanism - determined by every individual conference
servers - may need to be mapped from the different protocols. The servers - may need to be mapped from the different protocols. The
specific types of authentication mechanism are beyond the scope of specific types of authentication mechanism are beyond the scope of
this document. The list of possible values are: this document. The list of possible values are:
o "closedAuthenticated": A 'closedAuthenticated' policy MUST have o "closedAuthenticated": A 'closedAuthenticated' policy MUST have
each conference participant in the allowed users list (listed each conference participant in the allowed users list (listed
under the <allowed-users-list> XML element) with each participant under the <allowed-users-list> element) with each participant
being sufficiently (up to local policy) authenticated. Conference being sufficiently (up to local policy) authenticated. Conference
join requests for users not in the allowed users list or join requests for users not in the allowed users list or
participants not authenticated should be rejected unless a <join- participants not authenticated should be rejected unless a <join-
handling> action of 'confirm' is selected in which case the user handling> action of 'confirm' is selected in which case the user
is placed on a pending list as indicated earlier. A is placed on a pending list as indicated earlier. A
'closedAuthenticated' policy MUST NOT include a <deny-users-list>. 'closedAuthenticated' policy MUST NOT include a <deny-users-list>.
If <deny-users-list> appears in the data model, it MUST be If <deny-users-list> appears in the data model, it MUST be
ignored. ignored.
o "openAuthenticated": An 'openAuthenticated' policy requires each o "openAuthenticated": An 'openAuthenticated' policy requires each
skipping to change at page 53, line 24 skipping to change at page 53, line 25
A given conferencing system usually supports different protocols in A given conferencing system usually supports different protocols in
order to implement different functions (e.g., SIP for session control order to implement different functions (e.g., SIP for session control
and BFCP for floor control). Each of these protocols may use their and BFCP for floor control). Each of these protocols may use their
own authentication mechanism. In cases where a user is authenticated own authentication mechanism. In cases where a user is authenticated
using multiple authentication mechanisms, it is up to the using multiple authentication mechanisms, it is up to the
conferencing system to map all the different authentications to the conferencing system to map all the different authentications to the
same user. Discussing the specifics of different authentication same user. Discussing the specifics of different authentication
mechanism is beyond the scope of this document. mechanism is beyond the scope of this document.
Futhermore, users may use different namespaces to access to a Furthermore, users may use different identifiers to access to a
conference as explained in Section 4.6.5. These different namespaces conference as explained in Section 4.6.5. These different namespaces
can be associated with a unique conference user identifier (XCON- can be associated with a unique conference user identifier (XCON-
USERID). A mapping database is used to map all these authenticated USERID). A mapping database is used to map all these authenticated
user namespaces to the XCON-USERID. There are several threats user namespaces to the XCON-USERID. There are several threats
against this database. In order to minimize these threats, the against this database. In order to minimize these threats, the
administrator of the conferencing system MUST ensure that only administrator of the conferencing system MUST ensure that only
authorized users can connect to this database (e.g., by using access authorized users can connect to this database (e.g., by using access
control rules). In particular, the integrity of the database MUST be control rules). In particular, the integrity of the database MUST be
protected against unauthorized modifications. Generic security protected against unauthorized modifications. Generic security
considerations for usage of URIs are discussed in [RFC3986]. There considerations for usage of URIs are discussed in [RFC3986]. There
 End of changes. 13 change blocks. 
21 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/