XCON O. Novo
Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson
Expires: October 29, 2011 D. Morgan
Fidelity Investments
J. Urpalainen
Nokia
April 27, 2011
Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-27.txt
Abstract
[RFC5239] defines the idea of a centralized conferencing (XCON) as an
association of participants with a central focus. The state of a
conference is represented by a conference object. This document
defines an Extensible Markup Language (XML)-based conference
information data model to be used for conference objects. A
conference information data model is designed to convey information
about the conference and about participation in the conference. The
conference information data model defined in this document
constitutes an extension of the data format specified in the Session
Initiation Protocol (SIP) Event Package for Conference State
[RFC4575].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 29, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Novo, et al. Expires October 29, 2011 [Page 1]
Internet-Draft Data Model Schema April 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Novo, et al. Expires October 29, 2011 [Page 2]
Internet-Draft Data Model Schema April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 8
3.3. The Conference Object Identifier . . . . . . . . . . . . . 8
3.3.1. Conference Object URI Definition . . . . . . . . . . . 10
3.3.2. Normalization and Conference Object URI Comparison . . 10
3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 10
4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 11
4.1. <conference-info> . . . . . . . . . . . . . . . . . . . . 15
4.2. <conference-description> . . . . . . . . . . . . . . . . . 15
4.2.1. <language> . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. <display-text> . . . . . . . . . . . . . . . . . . . . 16
4.2.3. <subject> . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. <free-text> . . . . . . . . . . . . . . . . . . . . . 16
4.2.5. <keywords> . . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 16
4.2.7. <cloning-parent> . . . . . . . . . . . . . . . . . . . 16
4.2.8. <sidebar-parent> . . . . . . . . . . . . . . . . . . . 16
4.2.9. <conference-time> . . . . . . . . . . . . . . . . . . 17
4.2.10. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 18
4.2.11. <service-uris> . . . . . . . . . . . . . . . . . . . . 18
4.2.12. <maximum-user-count> . . . . . . . . . . . . . . . . . 19
4.2.13. <available-media> . . . . . . . . . . . . . . . . . . 19
4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 22
4.4.1. <allow-conference-event-subscription> . . . . . . . . 22
4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 22
4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 22
4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 22
4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 22
4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 23
4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 23
4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 23
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 24
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 25
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 26
4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 27
4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 27
4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 28
4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 29
4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 29
4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 29
Novo, et al. Expires October 29, 2011 [Page 3]
Internet-Draft Data Model Schema April 2011
4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 29
4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 29
4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 29
4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 30
4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 30
4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 30
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 31
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 32
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 32
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 43
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 54
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 54
9.3. Conference Object Identifier Registration . . . . . . . . 55
9.4. Conference User Identifier Registration . . . . . . . . . 56
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.1. Normative References . . . . . . . . . . . . . . . . . . . 57
11.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 58
Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95
Novo, et al. Expires October 29, 2011 [Page 4]
Internet-Draft Data Model Schema April 2011
1. Introduction
There is a core data set of conference information that is utilized
in any conference, independent of the specific conference media.
This core data set called the 'conference information data model' is
defined in this document using an Extensible Markup Language (XML)-
based. The conference information data model defined in this
document is logically represented by the conference object.
Conference objects are a fundamental concept in Centralized
Conferencing, as described in the Centralized Conferencing Framework
[RFC5239]. A conference object contains data that represents a
conference during each of its various stages (e.g., created/creation,
reserved/reservation, active/activation, completed/completion). A
conference object can be manipulated using a conference control
protocol at a conference server. The conference object represents a
particular instantiation of a conference information data model.
Consequently, conference objects use the XML format defined in this
document.
A conference object contains the core information of a conference
(i.e., capabilities, membership, call control signaling, media, etc.)
and specifies by whom, and in which way, that information can be
manipulated.
Figure 1 shows the logical functional elements of a conference server
as defined by the Centralized Conferencing Framework [RFC5239]. They
are a Conference Control Server, a Floor Control Server, a number of
Foci, and a Notification Service. A conference control protocol
provides the interface between a conference control client and the
conference control server. A floor control protocol (e.g., BFCP
[RFC4582]) provides the interface between a floor control client and
the floor control server. A call signaling protocol (e.g., SIP,
H.323, Q.931, ISUP, etc.) provides the interface between a call
signaling client and a Focus. A notification protocol (e.g., SIP-
based event notifications [RFC3265]) provides the interface between
the conferencing client and the Notification Service. Within a
conference, the conference control server, floor control server, and
focus can modify the information in the conference object.
Novo, et al. Expires October 29, 2011 [Page 5]
Internet-Draft Data Model Schema April 2011
...............................................................
. Conferencing Server .
. +---------------------------------------------------+ .
. | C o n f e r e n c e o b j e c t | .
. +-+--------------------------------------------------+| .
. | C o n f e r e n c e o b j e c t || .
. +-+---------------------------------------------------+|| .
. | C o n f e r e n c e o b j e c t ||| .
. | +--------------------------------------------------+||| .
. | | Conference Information Data Model |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference description (times, duration) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Host information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference state | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Floor information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Membership (users, capacity) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Sidebars, Etc. | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Etc. | |||| .
. | | +----------------------------------------------+ |||+ .
. | +--------------------------------------------------+|+ .
. +----^------------------^-------------^--------|------+ .
. | | | | .
. +------v-------+ +--------v-----+ +-----v-+ +----v-------+ .
. | Conference | | Floor | | | | | .
. | Control | | Control | |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-----^--------+ +---^----------+ +-^-----+ +------------+ .
........|..............|..............|..........|.............
|Conference |Floor |Call |Notification
|Control |Control |Signaling |Protocol
|Protocol |Protocol |Protocol |
........v..............v..............v..........v.............
. C o n f e r e n c i n g C l i e n t .
...............................................................
Figure 1: Conference Server Architecture
Novo, et al. Expires October 29, 2011 [Page 6]
Internet-Draft Data Model Schema April 2011
The Session Initiation Protocol (SIP) Event Package for Conference
State, specified in [RFC4575], already defines a data format for
conferences. However, that model is SIP specific and lacks elements
related to some of the functionality defined by the Centralized
Conferencing Framework [RFC5239] (e.g., floor control). The data
model defined in this document constitutes a superset of the data
format defined in [RFC4575]. The result is a data format that
supports more call signaling protocols besides SIP and that covers
all the functionality defined in the Centralized Conferencing
Framework [RFC5239].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology defined in the Centralized
Conferencing Framework [RFC5239], the SIPPING conferencing framework
[RFC4353] and the BFCP (Binary Floor Control Protocol) specification
[RFC4582]. Readers of this document should be familiar with the
terminology used in those documents.
3. Overview
The data model specified in this document is the result of extending
the data format defined in [RFC4575] with new elements. Examples of
such extensions include scheduling elements, media control elements,
floor control elements, non-SIP URIs, and addition of localization
extensions to text elements. This data model can be used by
conference servers providing different types of basic conferences.
It is expected that this data model can be further extended with new
elements in the future in order to implement additional advanced
features.
3.1. Data Model Format
A conference object document is an XML [W3C.REC-xml-20081126]
document. Conference object documents MUST be based on Extensible
Markup Language (XML) 1.0 and SHOULD be encoded using UTF-8.
The normative description of the syntax of the conference object
document, for use by implementors of parsers and generators, is found
in the RelaxNG schema provided in Section 5. Compliant messages MUST
meet the requirements of that schema.
Novo, et al. Expires October 29, 2011 [Page 7]
Internet-Draft Data Model Schema April 2011
3.2. Data Model Namespace
This specification defines a new namespace specification for
identifying the elements defined in the data model. This namespace
is as follows:
urn:ietf:params:xml:ns:xcon-conference-info
3.3. The Conference Object Identifier
The conference object identifier (XCON-URI) can be viewed as a key to
accessing a specific conference object. It can be used, for
instance, by the conference control protocol to access, manipulate
and delete a conference object. A conference object identifier is
provided to the conferencing client by the conference notification
service or through out-of-band mechanisms (e.g. E-Mail).
A conferencing system may maintain a relationship between the
conference object identifiers and the identifiers associated with
each of the complementary centralized conferencing protocols (e.g.,
call signaling protocols, BFCP, etc.). To facilitate the maintenance
of these relationships, the conference object identifier acts as a
top level identifier within the conferencing system for the purpose
of identifying the interfaces for these other protocols. This
implicit binding provides a structured mapping of the various
protocols with the associated conference object Identifier. Figure 2
illustrates the relationship between the identifiers used for the
protocols and the general conference object identifier (XCON-URI).
Novo, et al. Expires October 29, 2011 [Page 8]
Internet-Draft Data Model Schema April 2011
+--------------------------+
| Conference |
| Object |
| Identifier |
+--------------------------+
| xcon:Ji092i@example.com |
+------+-------------------+
|
|
|
+-----------------+---------------+
| |
+-----------+-----------+ +----------+---------+
| CSP Conference IDs | |BFCP 'Conference ID'|
+-----------------------+ +--------------------+
| h323:i092@example.com | | i092 |
| tel:+44(0)2920930033 | +----------+---------+
| sip:i092@example.com | |
+-----------------------+ +-------+--------+
| BFCP 'Floor ID'|
+----------------+
| 543 |
| 236 |
+----------------+
Figure 2: Conference Object Mapping
In Figure 2, the conference object identifier acts as the top level
key in the identification process. The call signaling protocols have
an associated conference user identifier, often represented in the
form of URIs. The binary floor control protocol, as defined in
[RFC4582], defines the 'conference ID' identifier which represents a
conference instance within floor control. When created within the
conferencing system, the 'conference ID' has a 1:1 mapping to the
unique conference object Identifier(XCON-URI). Operations associated
with the conference control protocols are directly associated with
the conference object, thus the primary identifier associated with
these protocols is the conference object identifier(XCON-URI). The
mappings between additional protocols/interface is not strictly 1:1
and does allow for multiple occurrences. For example, multiple call
signaling protocols will each have a representation that is
implicitly linked to the top level conference object identifier e.g.
H323 and SIP URIs that represent a conference instance. It should be
noted that a conferencing system is free to structure such
relationships as required and this information is just included as a
guideline that can be used.
Further elements can be added to the tree representation in Figure 2
Novo, et al. Expires October 29, 2011 [Page 9]
Internet-Draft Data Model Schema April 2011
to enable a complete representation of a conference instance within a
conferencing system.
3.3.1. Conference Object URI Definition
XCON-URI = "xcon" ":" [conf-object-id "@"] host
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host and unreserved are defined in RFC3986[RFC3986]
XCON-URI is a URI conference identifier and even though its
construction is similar to a URL, in this case, the XCON-URI can not
be resolved to addresses and/or ports.
3.3.2. Normalization and Conference Object URI Comparison
In order to facilitate the comparison of the XCON-URI identifiers,
all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a
character-by-character basis as prescribed by RFC3986, Section 6.2.1.
The host construction, as defined in RFC3986 can take the form of an
IP address, which is not conventionally compared on a character-by-
character basis. The host part of an XCON-URI serves only as an
identifier; that is, it is never used as an address. The character-
by-character comparison still applies.
3.4. Data Model Structure
The information in this data model is structured in the following
manner. All the information related to a conference is contained in
a <conference-info> element. The <conference-info> element contains
the following child elements:
o The <conference-description> element describes the conference as a
whole. It has, for instance, information about the URI of the
conference, maximum users allowed in the conference, media
available in the conference, or the time the conference will
start.
o The <host-info> element contains information about the entity
hosting the conference (e.g., its URI).
Novo, et al. Expires October 29, 2011 [Page 10]
Internet-Draft Data Model Schema April 2011
o The <conference-state> element informs the subscribers about the
changes in the overall conference information.
o The <floor-information> element contains information about the
status of the different floors in the conference.
o The <users> element describes the membership information as a
whole. The <users> element contains a set of <user> child
elements, each describing a single participant in the conference.
o If a participant in the main conference joins a sidebar, a new
element is created in the conference referenced from the
<sidebars-by-ref> element or under one of the <sidebars-by-val>
elements.
Note that some of the elements described above such <conference-
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
val> are not defined in the data model in this specification but are
defined in the data format of [RFC4575]. We describe them here
because they are part of the basic structure of the data model.
4. Data Model Definition
The following non-normative diagram shows the structure of conference
object documents. The operator "!" preceding an element indicates
that the element is mandatory in the data model. The operator "*"
following an element indicates that the element is introduced and
defined in this document. That is, elements without a "*" have
already been defined in [RFC4575].
!<conference-info>
|
|--!<conference-description>
| |--<language>*
| |--<display-text>
| |--<subject>
| |--<free-text>
| |--<keywords>
| |--<allow-sidebars>*
| |--<cloning-parent>*
| |--<sidebar-parent>*
| |--<conference-time>*
| | |--<entry>*
| | | |--<base>*
| | | |--<mixing-start-offset>*
| | | |--<mixing-end-offset>*
| | | |--<can-join-after-offset>*
Novo, et al. Expires October 29, 2011 [Page 11]
Internet-Draft Data Model Schema April 2011
| | | |--<must-join-before-offset>*
| | | |--<request-user>*
| | | |--<notify-end-of-conference>*
| | | |--<allowed-extend-mixing-end-offset>*
| | ...
| |--<conf-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | | |--<conference-password>*
| | ...
| |--<service-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | ...
| |--<maximum-user-count>
| | ...
| |--<available-media>
| | |--!<entry>
| | | |--<display-text>
| | | |--<type>
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<codecs>*
| | | | |--<codec>*
| | | | | |--<subtype>*
| | | | |--<codec>*
| | | | | |--<subtype>*
| | | | ...
| | | |--<controls>*
| | | | |--<mute>*
| | | | |--<gain>*
| | | | ...
| | |--<entry>
| | | |--<display-text>
| | | |--<type>
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<codecs>*
| | | | |--<codec>*
| | | | | |--<subtype>*
| | | | |--<codec>*
| | | | | |--<subtype>*
| | | | ...
| | | |--<controls>*
Novo, et al. Expires October 29, 2011 [Page 12]
Internet-Draft Data Model Schema April 2011
| | | | |--<pause-video>*
| | | | |--<video-layout>*
| | | | ...
| | ...
|
|--<host-info>
| |--<display-text>
| |--<web-page>
| |--<uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| ...
|--<conference-state>
| |--<allow-conference-event-subscription>*
| |--<user-count>
| |--<active>
| |--<locked>
|
|--<floor-information>*
| |--<conference-ID>*
| |--<allow-floor-events>*
| |--<floor-request-handling>*
| |--<conference-floor-policy>*
| | |--<floor>*
| | | |--!<media-label>*
| | | |--!<algorithm>*
| | | |--<max-floor-users>*
| | | |--<moderator-id>*
| | | ...
| | ...
|
|--!<users>
| |--<join-handling>*
| |--<user-admission-policy>*
| |--<allowed-users-list>*
| | |--<target>*
| | |
| | |--<persistent-list>*
| | | |--<user>*
| | | | |-- <email>*
| |
| |--<deny-users-list>*
| |
| |--<user>
| | |--<display-text>
| | |--<associated-aors>
| | |--<provide-anonymity>*
Novo, et al. Expires October 29, 2011 [Page 13]
Internet-Draft Data Model Schema April 2011
| | |--<roles>
| | | |
| | | ...
| | |--<languages>
| | |--<cascaded-focus>
| | |--<allow-refer-users-dynamically>*
| | |--<allow-invite-users-dynamically>*
| | |--<allow-remove-users-dynamically>*
| | |--!<endpoint>
| | | |--<display-text>
| | | |--<referred>
| | | |--<status>
| | | |--<joining-method>
| | | |--<joining-info>
| | | |--<disconnection-method>
| | | |--<disconnection-info>
| | | |--<media>
| | | | |--<type>
| | | | |--<display-text>
| | | | |--<label>
| | | | |--<src-id>
| | | | |--<status>
| | | | |--<to-mixer>*
| | | | | |--<floor>*
| | | | | |--<controls>*
| | | | | | |--<mute>*
| | | | | | |--<gain>*
| | | | | | ...
| | | | |--<from-mixer>*
| | | | | |--<floor>*
| | | | | |--<controls>*
| | | | | | |--<pause-video>*
| | | | | | ...
| | | | ...
| | | |--<call-info>
| | | | |--<sip>
| | | | | |--<display-text>
| | | | | |--<call-id>
| | | | | |--<from-tag>
| | | | | |--<to-tag>
| ... ...
|--<sidebars-by-ref>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
Novo, et al. Expires October 29, 2011 [Page 14]
Internet-Draft Data Model Schema April 2011
| ...
|--<sidebars-by-val>
| |--<entry>
| | |
| | ...
| |--<entry>
| | |
| ... ...
Figure 3: Non-normative diagram
The following sections describe these elements in detail. The full
Relax NG schema is provided Section 5.
4.1. <conference-info>
A conference object document begins with the root element
<conference-info>, which is defined in [RFC4575]. The <conference-
info> attributes are described in [RFC4575]. Note that the
<conference-info> element does not have the attributes 'state' and
'version' defined in [RFC4575] for this element because these
attributes only apply to notification mechanisms.
In addition, [RFC4575] defines an 'entity' attribute that contains
the conference object identifier (XCON-URI) that identifies the
conference being described in the document.
The <conference-info> element contains the <conference-description>,
<host-info>, <conference-state>, <floor-information>, <users>,
<sidebars-by-ref>, and <sidebars-by-val> child elements. All these
elements, except <floor-information>, are defined in [RFC4575]. A
conference document MUST at least include the <conference-
description> and <users> child elements.
4.2. <conference-description>
The <conference-description> element, which is defined in [RFC4575],
describes the conference as a whole. It SHOULD have an attribute
'lang' to specify the language used in the contents of this element.
It is comprised of <language>, <display-text>, <subject>, <free-
text>, <keywords>, <allow-sidebars>, <cloning-parent>, <sidebar-
parent>, <conference-time>, <conf-uris>, <service-uris>, <maximum-
user-count>, and <available-media>.
The following sections describe these elements in more detail. Other
child elements MAY be defined in the future to extend the
<conference-description> element.
Novo, et al. Expires October 29, 2011 [Page 15]
Internet-Draft Data Model Schema April 2011
4.2.1. <language>
The <language> element indicates the predominant language that is
expected to be employed within a conference. The possible values of
this element are the values of the 'Subtag' column of the [RFC5646]
defined in IANA [IANA-Lan]. This element does not enforce the
language of the conference, but only informs the participants about
the desirable language that they should use in the conference.
Participants are free to switch to other languages if they like.
4.2.2. <display-text>
The <display-text> element is described in section 5.3 of [RFC4575].
4.2.3. <subject>
The <subject> element is described in section 5.3 of [RFC4575].
4.2.4. <free-text>
The <free-text> element is described in section 5.3 of [RFC4575].
4.2.5. <keywords>
The <keywords> element is described in section 5.3 of [RFC4575].
4.2.6. <allow-sidebars>
The <allow-sidebars> element represents a boolean value. If set to
TRUE, the conference is allowed to create sidebar conferences. If
absent, or set to FALSE, the conference can not create sidebar
conferences.
4.2.7. <cloning-parent>
When the <cloning-parent> is present, it indicates that the
conference object is a child of a parent conference. The <cloning-
parent> element contains the conference object Identifier (XCON-URI)
(different from the main XCON-URI) of the parent.
4.2.8. <sidebar-parent>
When the <sidebar-parent> is present, it indicates that the
conference object represents a sidebar of another conference. The
<sidebar-parent> element contains the conference object Identifier
(XCON-URI) (different from the main XCON-URI) of the parent.
Novo, et al. Expires October 29, 2011 [Page 16]
Internet-Draft Data Model Schema April 2011
4.2.9. <conference-time>
The <conference-time> element contains the information related to
conference time, policy, and duration of a conference. The
<conference-time> element contains one or more <entry> elements each
defining the time and policy information specifying a single
conference occurrence. The <conference-time> element differs from
the iCalendar objects [RFC5545] in the possibility to define
different policies (<can-join-after-offset>, <must-join-before-
offset>) for the same conference at different times.
Every <entry> element contains the following child elements:
o <base>: The <base> child element specifies the iCalendar object of
the conference. The iCalendar object components are defined in
[RFC5545].
o <mixing-start-offset>: The <mixing-start-offset> child element
specifies when the conference media mixing starts before the
conference starts. If the <mixing-start-offset> element is not
present, it indicates that the conference media mixing starts
immediately. The <mixing-start-offset> has the mandatory
'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator",
"user", "observer", and "participant". The roles' semantic
definitions are out of the scope of this document and is subject
to future policy documents. More values can be specified in the
future. The 'required-participant' attribute allows a privileged
user to define when media mixing starts based on the latter of the
mixing start time, and the time the first participant arrives. If
the value is set to "none'", mixing starts according to the mixing
start time.
o <mixing-end-offset>: The <mixing-end-offset> child element
specifies the time conference media mixing stops after the
conference stops. If the <mixing-end-offset> element is not
present, it indicates that the conference occurrence is not
bounded. The <mixing-end-offset> element has the mandatory
'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator",
"observer", "user", and "participant". More values can be
specified in the future. The 'required-participant' attribute
allows a privileged user to define when media mixing ends based on
the earlier of the <mixing-end-offset>, and the time the last
participant leaves. If the value is set to "none", mixing stops
according to the <mixing-end-offset>. If the conference policy
was modified so that last privileged user is now a normal
conference participant, and the conference requires a privileged
Novo, et al. Expires October 29, 2011 [Page 17]
Internet-Draft Data Model Schema April 2011
user to continue; that conference MUST terminate.
o <can-join-after-offset>: An administrator can indicate the time
when users can join a conference by populating the <can-join-
after-offset> element.
o <must-join-before-offset>: An administrator can define the time
after which new users are not allowed to join the conference
anymore.
o <request-user>: It defines the time when users or resources on the
<allowed-users-list> are requested to join the conference by using
the <request-users> element.
o <notify-end-of-conference>: The <notify-end-of-conference> element
defines in seconds when the system MUST send a notification when
the end of the conference is approaching. If the <notify-end-of-
conference> element is not present, it indicates that the system
does not notify the users when the end of the conference is
approaching.
o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
end-offset> element indicates if the conference is allowed to be
extended. It has a boolean value.
4.2.10. <conf-uris>
The <conf-uris> element contains the identifiers to be used in order
to access the conference by different signaling means. This element
contains a set of <entry> child elements - each containing a new
element, <conference-password>. This element contains the
password(s) of the conference, for instance, PSTN conference will
store the 'PIN code' in this element. All the other <conf-uris>
child element are described in section 5.3.1 of [RFC4575].
The schema in Section 5 allows <conference-password> to appear
anywhere uris-type is expanded. This document only provides meaning
for <conference-password> appearing as a descendent of the <conf-
uris> element. Future standardization may give meaning to
<conference-password> appearing in other elements of type uris-type.
In the absence of such standardization, <conference-password> MUST
NOT appear in elements of type uris-type other than <conf-uris>.
4.2.11. <service-uris>
The <service-uris> describes auxiliary services available for the
conference. The <service-uris> element is described in section 5.3.2
of [RFC4575].
Novo, et al. Expires October 29, 2011 [Page 18]
Internet-Draft Data Model Schema April 2011
4.2.12. <maximum-user-count>
The <maximum-user-count> contains the overall number of users allowed
to join the conference. Note that this value is set by an
administrator and can reflect any local policies such as network
consumption, CPU processing power, and licensing rules.
4.2.13. <available-media>
The <available-media> element consists of a sequence of <entry> child
elements. Each <entry> element contain the 'label' attribute that is
the media stream identifier assigned by the conferencing server. The
attribute 'label' is described in [RFC4575], section 5.3.4. Each
<entry> element contains the following child elements:
o The <type> element is described in section 5.3.4 of [RFC4575].
o The <display-text> 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
policy by which the mixer will build the outgoing stream from the
incoming streams. Note that this policy is different than the
policy describing the floors for each media. The <mixing-mode>
child element MUST contain one and only one of the "Moderator-
controlled", "FCFS", and "Automatic" values, indicating the
default algorithm to use with every media stream. The "Moderator-
controlled" value indicates that the moderator of the conference,
controls the media stream policy. The "FCFS" value indicates a
'first-come-first-served' policy. The "Automatic" value means the
mixer choose the best scheduling policy for the conference.
o The <codecs> element specifies the allowed codecs in the
conference. It has an attribute 'decision' that specifies if the
focus decides the common codec automatically or needs the approval
of the moderator of the conference ("automatic", "moderator-
controlled"). The <codecs> element contains <codec> elements. A
<codec> element can have the attribute 'name' and 'policy'. The
'name' attribute is a codec identifier assigned by the
conferencing server. The 'policy' attribute contains the policy
for that codec (allowed, or disallowed). The <codec> element has
the child element <subtype> which stores the codec's name. The
possible values of this element are the values of the 'subtype'
column of the RTP Payload Format media types per [RFC4855] defined
in IANA [IANA]. It is expected that future conferencing
specifications will define corresponding schema extensions, as
Novo, et al. Expires October 29, 2011 [Page 19]
Internet-Draft Data Model Schema April 2011
appropriate.
o The <controls> element contains the basic audio and video global
control elements for a conference. These controls are sufficient
for the majority of basic conferences. If the conference server
wants to support more advanced controls, then it is RECOMMENDED
that an extension to the data model be used. In the <controls>
element the schema is extensible, hence new control types can be
added in the future. So moderator controls that affect all media
output would go under the <available-media> element. The
following controls elements are defined for <controls>:
* The <mute> element is used in conjunction with an audio stream
to cease transmission of any audio from the associated stream.
That means that for the entire duration where mute is
applicable, all current and future participants of the
conference are muted and will not receive any audio. It has a
"boolean" value. If this control is not specified, access to
the control is not available to the client.
* The <pause-video> element is used in conjunction with a video
stream to cease transmission of associated media. It has a
"boolean" value. If this control is not specified, the access
to the control is not available to the client.
* The <gain> element is used in conjunction with a media output
stream to indicate the amount of amplification of an audio
stream. The value is an integer number that ranges from -127
to 127. If this control is not specified, access to the
control is not available to the client.
* The <video-layout> element is used in conjunction with a video
stream to specify how the video streams (of participants) are
viewed by each participant. Only one layout type can be
specified for each output stream. If there are fewer
participants than panels in the specified layout, then blanking
(black screen) MAY be mixed into the stream on the behalf of
the missing input streams. If unspecified, the <video-layout>
default type SHOULD be "single-view". The <video-layout> types
are as follows, although any number of custom layouts may be
specified in future extensions:
+ single-view: Only one stream is presented by the focus to
all participants in one panel.
+ dual-view: This dual view option will present the video
side-by-side in 2 panels and not alter the aspect ratio of
the streams. This will require the focus to introduce
Novo, et al. Expires October 29, 2011 [Page 20]
Internet-Draft Data Model Schema April 2011
blanking on parts of the overall image as viewed by the
participants.
+ dual-view-crop: This side-by-side layout option instructs
the focus to alter the aspect ratio of the streams (alter-
aspect-ratio=TRUE) so that blanking is not necessary. The
focus handles the cropping of the streams.
+ dual-view-2x1: This layout option instructs the focus to
place one stream above the other, in essence with two rows
and one column. In this option the aspect ratio is not
altered and blanking is introduced.
+ dual-view-2x1-crop: This layout option also instructs the
focus to place one stream above the other, in essence with
two rows and one column. In this option the aspect ratio is
altered and the video streams are cropped.
+ quad-view: Four equal-sized panels in a 2x2 layout is
presented by the focus to all participants. Typically the
aspect ratio of the streams are maintained (alter-aspect-
ratio= FALSE).
+ multiple-3x3: Nine equal-sized panels in a 3x3 layout is
presented by the focus to all participants. Typically the
aspect ratio of the streams are preserved.
+ multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is
presented by the focus to all participants. Typically the
aspect ratio of the streams are preserved.
+ multiple-5x1: This option refers to a 5x1 layout where one
panel will occupy 4/9 of the mixed video stream while the
others will each occupy 1/9 of the stream. Typically the
aspect ratio of the streams is preserved.
+ automatic: This option allows the focus to add panels as
streams are added.
4.3. <host-info>
The <host-info> element contains information about the entity hosting
the conference. This information is usually set before conference
activation, and is rarely changed during the conference lifetime.
The <host-info> element and its child elements are described in
[RFC4575], section 5.4. Future extensions to the <host-info> element
may define new values.
Novo, et al. Expires October 29, 2011 [Page 21]
Internet-Draft Data Model Schema April 2011
4.4. <conference-state>
The <conference-state> is introduced in [RFC4575]. The <conference-
state> element contains the <allow-conference-event-subscription>,
<user-count>, <active>, and <locked> child elements.
4.4.1. <allow-conference-event-subscription>
The <allow-conference-event-subscription> element represents a
boolean action. If set to TRUE, the focus is instructed to allow the
subscription to conference state events, such as 'SIP Event Package
for Conference State' [RFC4575]. If set to FALSE, the subscription
to conference state events MUST be rejected. If this element is
undefined it has a default value of TRUE, causing the subscription to
conference state events to be accepted.
4.4.2. <user-count>
The <user-count> child element is explained in [RFC4575], section
5.5.1.
4.4.3. <active>
The <active> child element is explained in [RFC4575], section 5.5.2.
4.4.4. <locked>
The <locked> child element is explained in [RFC4575], section 5.5.3.
4.5. <floor-information>
The <floor-information> element contains the <conference-ID>, <allow-
floor-events>, <floor-request-handling>, and <conference-floor-
policy> child elements. The absence of this element from an XML
document indicates that the conference does not have a floor.
4.5.1. <conference-ID>
The <conference-ID> represents a conference instance within floor
control. When BFCP serves as the floor control protocol, the
<conference-ID> is a 32-bit BFCP conference identifier defined in
[RFC4582] section 5.1. Note that when created within the
conferencing system, there is a 1:1 mapping between this
<conference-ID> and the unique conference object Identifier (XCON-
URI).
Novo, et al. Expires October 29, 2011 [Page 22]
Internet-Draft Data Model Schema April 2011
4.5.2. <allow-floor-events>
The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject
the subscription. If this element is undefined, it has a default
value of FALSE, causing the subscription to floor control events to
be rejected.
A conference participant can subscribe himself to a floor control
event in two different ways: one method is using an offer/answer
exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters
in the SDP ([RFC4583]), the other method is a general authorization
mechanism described in section 9 of [RFC4582] and in [RFC5018].
Future documentation may define additional connection mechanisms.
4.5.3. <floor-request-handling>
The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request
to a floor within a conference. This element defines values of:
o "block": This action instructs the focus to deny the floor
request. This action is the default action taken in the absence
of any other actions.
o "confirm": This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further allow
or deny the floor. The algorithms used are outside the scope of
this document.
Note that this section discusses floor control information,
therefore, the value "block" in a <floor-request-handling> element is
not related with the "block" value in the <join-handling> element
(see Section 4.6).
4.5.4. <conference-floor-policy>
The <conference-floor-policy> element has one or more <floor> child
elements. Every <floor> child elements has an attribute 'id' which
uniquely identifies a floor within a conference. In the case of BFCP
[RFC4582], the 'id' attribute corresponds to the floor-id identifier
defined in [RFC4582] section 5.2.2.
o <media-label>: Every floor is identified for one or more mandatory
<media-label> element. If the <available-media> information is
included in the conference document, the value of this element
Novo, et al. Expires October 29, 2011 [Page 23]
Internet-Draft Data Model Schema April 2011
MUST be equal to the 'label' value of the corresponding media
stream <entry> in the <available-media> container. The number of
those elements indicates how many floors the conference can have.
A floor can be used for one or more media types;
o <algorithm>: A floor can be controlled using many algorithms; the
mandatory <algorithm> element MUST be set to any of the
"moderator-controlled", "FCFS" or "random" values indicating the
algorithm. The "Moderator-controlled" value indicates that the
moderator of the conference controls the floor. The "FCFS" value
states for 'first-come-first-served' floor control.
o <max-floor-users>: The <max-floor-users> child element in the
<floor> element is optional and, if present, dictates the maximum
number of users who can have the floor at one time.
o <moderator-id>: The optional <moderator-id> indicates the 'User
ID' of the moderator(s). It MUST be set if the element
<algorithm> is set to "Moderator-controlled" value. When the
floor is created within the conferencing system, the XCON-User
identifier MAY be used as the moderator-id. In the case of BFCP
as the floor control protocol, the <moderator-id> is defined in
[RFC4582] section 3. Note that [RFC4582] refers to the moderator
role as a 'floor chair'.
4.6. <users>
The <users> element is described in [RFC4575] and contains the <join-
handling>, <user-admission-policy>, <allowed-users-list> and <deny-
users-list> defined in this document and <user> child elements
defined in [RFC4575]. Note that the <users> element does not have
the attribute 'state' defined in [RFC4575] for this element because
this attribute only applies to notification mechanisms. The
following sections describe these elements in more detail. Other
child elements and attributes can be used to extend <users> in the
future.
4.6.1. <join-handling>
The <join-handling> element defines the actions used by the
conference focus to control conference participation. This element
defines the action that the focus is to take when processing a
particular request to join a conference. This element defines values
of:
o "block": This action instructs the focus to deny access to the
conference. This action is the default action taken in the
absence of any other actions.
Novo, et al. Expires October 29, 2011 [Page 24]
Internet-Draft Data Model Schema April 2011
o "confirm": This action instructs the focus to place the
participant on a pending list (e.g., by parking the call on a
music-on-hold server), awaiting moderator input for further
actions.
o "allow": This action instructs the focus to accept the conference
join request and grant access to the conference within the
instructions specified in the transformations of this rule.
o "authenticate": This action instructs the focus that the user has
to provide a combination of username/password.
o "directed-operator": This action instructs the focus to direct the
user to an operator.
4.6.2. <user-admission-policy>
The <user-admission-policy> is an element that lets an organizer (or
a participant with appropriate rights) choose a policy for the
conference that controls how users are authenticated into the
conference, using a mechanism of the conference's choosing. Since a
variety of signaling protocols are possible, a variety of
authentication mechanism - determined by every individual conference
servers - may need to be mapped from the different protocols. The
specific types of authentication mechanism are beyond the scope of
this document. The list of possible values are:
o "closedAuthenticated": A 'closedAuthenticated' policy MUST have
each conference participant in the allowed users list (listed
under the <allowed-users-list> element) with each participant
being sufficiently (up to local policy) authenticated. Conference
join requests for users not in the allowed users list or
participants not authenticated should be rejected unless a <join-
handling> action of 'confirm' is selected in which case the user
is placed on a pending list as indicated earlier. A
'closedAuthenticated' policy MUST NOT include a <deny-users-list>.
If <deny-users-list> appears in the data model, it MUST be
ignored.
o "openAuthenticated": An 'openAuthenticated' policy requires each
conferencing participant to be sufficiently authenticated.
Typically this implies that anyone capable of authenticating with
the conferencing system may join the conference. The
'openAuthenticated' policy permits the specification of "banned"
conferencing participants. Such banned users are prevented from
re-joining the conference until they have been un-banned. An
'openAuthenticated' policy SHOULD have a deny users list (listed
under the <deny-users-list> XML element) to support banning of
Novo, et al. Expires October 29, 2011 [Page 25]
Internet-Draft Data Model Schema April 2011
conferencing participants from a conference. An
'openAuthenticated' policy MUST NOT include an <allowed-users-
list>. If <allowed-users-list> appears in the data model, it MUST
be ignored.
o "anonymous": An 'anonymous' policy allows any join requests in and
is the least restrictive policy. An 'anonymous' policy MUST NOT
include either an <allowed-users-list> or a <deny-users-list>. If
any of these lists appear in the data model, they MUST be ignored.
In all other cases, the appearance of an <allowed-users-list> and
<deny-users-list> MUST be ignored, except as otherwise described in a
future specification. Future specifications describing the use of
these lists must provide clear guidance on how to process the lists
when they occur concurrently, especially when both lists contain the
same user. For example, such specification could disallow both list
from appearing at the same time similar to user-admission-policy
values defined in this document.
4.6.3. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs
(e.g. xcon-userid defined in Section 4.6.5), roles (defined in
Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus
uses to determine who can join the conference, who can be invited to
join a conference, or who the focus needs to "refer to" the
conference. The <allowed-users-list> element includes zero or more
<target> child elements. This child element includes the mandatory
'uri' attribute and the mandatory 'method' attribute. The same 'uri'
attribute with different method values can appear in the list more
than once.
The 'method' attribute is a list with the following values:
o "dial-in": The value "dial-in" is used by the focus to determine
who can join the conference.
o "dial-out": The value "dial-out" contains a list of resources that
the focus will initiate a session with.
o "refer": The value "refer" is used by the focus to determine the
resources that the focus needs to "refer to" the conference. In
SIP, this is achieved by the focus sending a REFER request to
those potential participants. In a different paradigm, this could
also mean that the focus sends an SMS or an email to the referred
user. This list can be updated during the conference lifetime so
it can be used for mid-conference refers as well.
Novo, et al. Expires October 29, 2011 [Page 26]
Internet-Draft Data Model Schema April 2011
The "refer" value differs from the "dial-out" in that the resources
on the "refer" value are expected to initiate the session
establishment toward the focus themselves. It is also envisioned
that different users will have different access rights to those lists
and therefore a separation between the two is needed.
The <allowed-users-list> element has a <persistent-list> child
element as well. Some chatroom systems allow -- and some require --
registration of detailed information about a user before they are
allowed to join a chatroom. The <persistent-list> child element
stores persistent information about users who are not actively part
of an ongoing chatroom session. The <persistent-list> element stores
the following information:
o user: The <user> element stores the name, nickname, the conference
user identifier (XCON-USERID) and email address of a user. It has
three attributes: 'name', 'nickname' and 'id' and an <email>
element. Future extensions to this schema may define new elements
for the <user> element.
Future extensions to this schema may define new elements for the
<target> element.
4.6.4. <deny-users-list>
The <deny-users-list> child element contains a list of user URIs
(e.g. SIP URI, xcon-userid defined in Section 4.6.5), roles (defined
in Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus
uses to determine who has been 'banned' from the conference. Such
banned users are prevented from re-joining the chatroom until they
have been un-banned.
4.6.5. <user> and Its <user> Sub-elements
The element <user> is described in [RFC4575] and describes a single
participant in the conference. The <user> element has an attribute
'entity'. Note that the <user> element does not have the attribute
'state' defined in [RFC4575] for this element because this attribute
only applies to notifications mechanism.
The attribute 'entity' contains a unique conference user identifier
(XCON-USERID) within the scope of the conference. The URI format of
this identifier is as follow:
XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*unreserved
Novo, et al. Expires October 29, 2011 [Page 27]
Internet-Draft Data Model Schema April 2011
[unreserved is defined in RFC3986]
In order to facilitate the comparison of the XCON-USERID identifiers,
all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a
character-by-character basis as prescribed by RFC3986, Section 6.2.1.
Other user identifiers can be associated with this conference user
identifier and enable the conferencing system to correlate and map
these multiple authenticated user identities to a single global user
identifier. Figure 4 illustrates an example using the conference
user identifier in association with the user identity defined for
BFCP, SIP, and H323 user identity. It should be noted that a
conferencing system is free to structure such relationships as
required and this information is just included as a guideline.
+----------------+
| Conference |
| User |
| Identifier |
+----------------+
|xcon-userid:John|
+-------+--------+
|
|
|
+----------------------+-------------------------+
| | |
+-------+--------+ +-----------+-----------+ +-----------+-----------+
| BFCP User ID | | SIP User URI | | H323 User URI |
+----------------+ +-----------------------+ +-----------------------+
| 543 | |sip:851221@example.com | |h323:taeduk@example.com|
+----------------+ +-----------------------+ +-----------------------+
Figure 4: Conference User Mapping
The element <user> element contains the <display-text>, <associated-
aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
<allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
<allow-remove-users-dynamically>, and <endpoint>. The following
sections describe these elements in more detail.
4.6.5.1. <display-text>
The <display-text> child element is explained in [RFC4575], section
5.6.1.
Novo, et al. Expires October 29, 2011 [Page 28]
Internet-Draft Data Model Schema April 2011
4.6.5.2. <associated-aors>
The <associated-aors> child element is explained in [RFC4575],
section 5.6.2.
4.6.5.3. <provide-anonymity>
The <provide-anonymity> element specifies what level of anonymity the
server should provide to the user. In this case, the focus provides
to the rest of the participants an anonymous identity for that user,
for example anonymousX, or it does not provide any information for
that user such that other users can not see he is a participant in
the conference. This element only affects the way the user
information is provided to the other participants. The real user
information is stored in the data model but SHOULD NOT be provided to
the other participants of the conference. This can be achieved by
using the <provide-anonymity> element. This element has three
values: 'private', 'semi-private' and 'hidden'. The 'private' value
specifies that this user is completely anonymous in the conference.
'semi-private' value specifies that this user is anonymous to all
users who have not been granted permission to see him. 'hidden' value
specifies that other users can not see this participant in the
conference.
4.6.5.4. <roles>
A role provides the context for the set of conference operations that
a participant can perform. This element can contain one or more of
the following values: "administrator", "moderator", "user",
"participant", "observer", and "none". A role of "none" indicates
that any role is assigned; The roles semantic definition is out of
the scope of this document and is subject to future policy documents.
This element can be extended with new roles in future documents.
4.6.5.5. <languages>
The <languages> child element is explained in [RFC4575], section
5.6.4.
4.6.5.6. <cascaded-focus>
The <cascaded-focus> child element is explained in [RFC4575], section
5.6.5.
4.6.5.7. <allow-refer-users-dynamically>
The <allow-refer-users-dynamically> element represents a boolean
value. If set to TRUE, a participant is allowed to instruct the
Novo, et al. Expires October 29, 2011 [Page 29]
Internet-Draft Data Model Schema April 2011
focus to refer a user to the conference without modifying the
<allowed-users-list> (in SIP terms, a participant is allowed to send
a REFER request [RFC3515] to the focus which results in the focus
sending a REFER request to the user the referrer wishes to join the
conference). If set to FALSE, the refer request is rejected. If
this element is undefined it has a value of FALSE, causing the refer
to be rejected.
4.6.5.8. <allow-invite-users-dynamically>
The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the
focus to invite a user to the conference without modifying the
<allowed-users-list> list (in SIP terms, a participant is allowed to
send a REFER request [RFC3515] to the focus which results in the
focus sending an INVITE request to the user the referrer wishes to
join the conference). If set to FALSE, the refer request is
rejected. If this element is undefined it has a value of FALSE,
causing the refer to be rejected.
4.6.5.9. <allow-remove-users-dynamically>
The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the
focus to remove a user from the conference without modifying the
ruleset (in SIP terms, a participant is allowed to send a REFER
request [RFC3515] to the focus which results in the focus sending an
BYE request to the user the referrer wishes to leave the conference).
If set to FALSE, the refer request is rejected. If this element is
undefined it has a value of FALSE, causing the refer to be rejected.
4.6.5.10. <endpoint>
The <endpoint> child element is identical to the element with the
same name in [RFC4575] except that the 'state' attribute is not
included. The 'state' attribute only applies to notification
mechanisms. The <endpoint> element can provide the desired level of
detail about the user's devices and their signaling sessions taking
part in the conference.
The <endpoint> element has the following child elements: <display-
text>, <referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>,and <call-
info>. All the <endpoint> child elements are defined in [RFC4575]
with the exception of the <to-mixer> element, and the <from-mixer>
element.
The <endpoint>/<media> element has two other child elements defined
Novo, et al. Expires October 29, 2011 [Page 30]
Internet-Draft Data Model Schema April 2011
in this document, the <to-mixer>, and the <from-mixer>:
o <from-mixer>, <to-mixer>: These are controls that apply to a
user's media stream being sent from the mixer to the participants
endpoint or to the mixer from the participants endpoint. The <to-
mixer> element details properties associated with the incoming
streams to the mixer (streams sent to the mixer from the
participant). The <from-mixer> element details properties
associated with the outgoing streams from the mixer (sent from the
mixer to the participant). Both of these elements have the
attribute 'name'. The 'name' attribute has the values "VideoIn",
"VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and
"AudioOut" media streams detail properties associated with the
outgoing video and audio from the mixer. The "VideoIn" and
"AudioIn" media stream details properties associated with the
incoming video and audio to the mixer. Both of these elements can
have the <floor> child element defined:
* The <floor> element refers to the floor assigned to a certain
participant in the conference. If a participant, for instance,
needs to talk in the conference, it first needs to get the
floor from the chair of the conference. The <floor> element
has an attribute 'id' which uniquely identifies a floor within
a conference. The 'id' attribute corresponds to the floor-id
identifier defined in [RFC4582] section 5.2.2. The <floor>
element has a "Boolean" value. A value of FALSE indicates that
this user does not hold the floor in this moment. If this
control is not specified, this user SHOULD NOT specify the
floor option.
The <to-mixer> and <from-mixer> elements can have the <controls>
child element:
* Controls that apply to a specific user would appear under the
<controls> element.
o More values can be defined in the future.
4.7. <sidebars-by-ref>
The <sidebars-by-ref> element contains a set of <entry> child
elements. This element is described in [RFC4575], 5.9.1. Note that
the <sidebars-by-ref> element does not have the attribute 'state'
defined in [RFC4575] for this element because this attribute only
applies to notifications mechanism.
Novo, et al. Expires October 29, 2011 [Page 31]
Internet-Draft Data Model Schema April 2011
4.8. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. This
element is described in [RFC4575], 5.9.2. Note that the <sidebars-
by-val> element does not have the attribute 'state' defined in
[RFC4575] for this element because this attribute only applies to
notifications mechanism.
5. RELAX NG Schema
In accordance with the Centralized Conferencing Framework document
[RFC5239], the Conference Object is a logical representation of a
conference instance. The conference information schema contains core
information that is utilized in any conference. It also contains the
variable information part of the Conference Object.
The normative schema is backwards compatible with [RFC5239], in other
words, valid [RFC5239] instance documents are also valid according to
this RELAX NG schema [RELAX]. In addition to approximately similar
RELAX NG [RELAX] definitions of [RFC5239], this schema contains
extension elements in the
"urn:ietf:params:xml:ns:xcon-conference-info" namespace.
default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"
start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
attribute entity { text }
& anyAttribute
& conference-description-type?
& element host-info { host-type }?
& element conference-state { conference-state-type }?
& element users { users-type }?
& element sidebars-by-ref { uris-type }?
& element sidebars-by-val { sidebars-by-val-type }?
& element xcon:floor-information { floor-information-type }?
& anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
element conference-description {
attribute xml:lang { xsd:language }?
& anyAttribute
& element display-text { text }?
& element subject { text }?
Novo, et al. Expires October 29, 2011 [Page 32]
Internet-Draft Data Model Schema April 2011
& element free-text { text }?
& element keywords {
list { xsd:string* }
}?
& element conf-uris { uris-type }?
& element service-uris { uris-type }?
& element maximum-user-count { xsd:int }?
& element available-media { conference-media-type }?
& element xcon:language { xsd:language }?
& element xcon:allow-sidebars { xsd:boolean }?
& element xcon:cloning-parent { xsd:anyURI }?
& element xcon:sidebar-parent { xsd:anyURI }?
& element xcon:conference-time { conferencetime-type }?
& anyElement*
}
# HOST TYPE
host-type =
element display-text { text }?
& element web-page { xsd:anyURI }?
& element uris { uris-type }?
& anyElement*
& anyAttribute
# CONFERENCE STATE TYPE
conference-state-type =
anyAttribute
& element user-count { xsd:unsignedInt }?
& element active { xsd:boolean }?
& element locked { xsd:boolean }?
& element xcon:allow-conference-event-subscription { xsd:boolean }?
& anyElement*
# CONFERENCE MEDIA TYPE
conference-media-type =
anyAttribute
& element entry { conference-medium-type }*
& anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
attribute label { text }
& anyAttribute
& element display-text { text }?
& element type { text }?
& element status { media-status-type }?
& element xcon:mixing-mode { mixing-mode-type }?
& element xcon:codecs { codecs-type }?
& element xcon:controls { control-type }?
& anyElement*
# URIs TYPE
uris-type =
Novo, et al. Expires October 29, 2011 [Page 33]
Internet-Draft Data Model Schema April 2011
anyAttribute
& element entry { uri-type }*
& anyElement*
# URI TYPE
uri-type =
element uri { xsd:anyURI }
& element display-text { text }?
& element purpose { text }?
& element modified { execution-type }?
& element xcon:conference-password { text }*
& anyElement*
& anyAttribute
# USERS TYPE
users-type =
anyAttribute
& element user { user-type }*
& element xcon:join-handling { join-handling-type }?
& element xcon:user-admission-policy { user-admission-policy-type }?
& element xcon:allowed-users-list { allowed-users-list-type }?
& element xcon:deny-users-list { deny-user-list-type }?
& anyElement*
# USER TYPE
user-type =
attribute entity { xsd:anyURI }
& anyAttribute
& element display-text { text }?
& element associated-aors { uris-type }?
& element roles {
element entry { single-role-type }+
}?
& element languages {
list { xsd:language }
}?
& element cascaded-focus { xsd:anyURI }?
& element endpoint { endpoint-type }*
& element xcon:provide-anonymity { provide-anonymity-type }?
& element xcon:allow-refer-users-dynamically { xsd:boolean }?
& element xcon:allow-invite-users-dynamically { xsd:boolean }?
& element xcon:allow-remove-users-dynamically { xsd:boolean }?
& anyElement*
# ENDPOINT TYPE
endpoint-type =
attribute entity { text }
& anyAttribute
& element display-text { text }?
& element referred { execution-type }?
& element status { endpoint-status-type }?
& element joining-method { joining-type }?
Novo, et al. Expires October 29, 2011 [Page 34]
Internet-Draft Data Model Schema April 2011
& element joining-info { execution-type }?
& element disconnection-method { disconnection-type }?
& element disconnection-info { execution-type }?
& element media { media-type }*
& element call-info { call-type }?
& anyElement*
# ENDPOINT STATUS TYPE
endpoint-status-type =
"pending"
| "dialing-out"
| "dialing-in"
| "alerting"
| "on-hold"
| "connected"
| "muted-via-focus"
| "disconnecting"
| "disconnected"
| free-text-extension
# JOINING TYPE
joining-type =
"dialed-in" | "dialed-out" | "focus-owner" | free-text-extension
# DISCONNECTION TYPE
disconnection-type =
"departed" | "booted" | "failed" | "busy" | free-text-extension
# EXECUTION TYPE
execution-type =
element when { xsd:dateTime }?
& element reason { text }?
& element by { xsd:anyURI }?
& anyAttribute
# CALL TYPE
call-type =
element sip { sip-dialog-id-type }
& anyElement*
& anyAttribute
# SIP DIALOG ID TYPE
sip-dialog-id-type =
element display-text { text }?
& element call-id { text }
& element from-tag { text }
& element to-tag { text }
& anyElement*
& anyAttribute
# MEDIA TYPE
media-type =
attribute id { xsd:int }
& anyAttribute
& element display-text { text }?
Novo, et al. Expires October 29, 2011 [Page 35]
Internet-Draft Data Model Schema April 2011
& element type { text }?
& element label { text }?
& element src-id { text }?
& element status { media-status-type }?
& element xcon:to-mixer { mixer-type }?
& element xcon:from-mixer { mixer-type }?
& anyElement*
# MEDIA STATUS TYPE
media-status-type =
"recvonly"
| "sendonly"
| "sendrecv"
| "inactive"
| free-text-extension
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
anyAttribute
& element entry { conference-type }*
& anyElement*
# CONFERENCE TIME
conferencetime-type =
anyAttribute
& element xcon:entry {
element xcon:base { text },
element xcon:mixing-start-offset {
time-type,
attribute required-participant { single-role-type },
anyAttribute
}?,
element xcon:mixing-end-offset {
time-type,
attribute required-participant { single-role-type },
anyAttribute
}?,
element xcon:can-join-after-offset { time-type }?,
element xcon:must-join-before-offset { time-type }?,
element xcon:request-user { time-type }?,
element xcon:notify-end-of-conference { xsd:int }?,
element xcon:allowed-extend-mixing-end-offset { xsd:boolean }?,
anyElement*
}*
# TIME TYPE
time-type = xsd:dateTime { pattern = ".+T.+Z.*" }
# SINGLE ROLE TYPE
single-role-type =
xsd:string "none"
| xsd:string "administrator"
| xsd:string "moderator"
Novo, et al. Expires October 29, 2011 [Page 36]
Internet-Draft Data Model Schema April 2011
| xsd:string "user"
| xsd:string "observer"
| xsd:string "participant"
| free-text-extension
# MIXING MODE TYPE
mixing-mode-type =
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "automatic"
| free-text-extension
# CODECS TYPE
codecs-type =
attribute decision { decision-type }
& anyAttribute
& element xcon:codec { codec-type }*
& anyElement*
# CODEC TYPE
codec-type =
attribute name { text }
& attribute policy { policy-type }
& anyAttribute
& element xcon:subtype { text }?
& anyElement*
# DECISION TYPE
decision-type =
xsd:string "automatic"
| xsd:string "moderator-controlled"
| free-text-extension
# POLICY TYPE
policy-type =
xsd:string "allowed" | xsd:string "disallowed" | free-text-extension
# CONTROL TYPE
control-type =
anyAttribute
& element xcon:mute { xsd:boolean }?
& element xcon:pause-video { xsd:boolean }?
& element xcon:gain { gain-type }?
& element xcon:video-layout { video-layout-type }?
& anyElement*
# GAIN TYPE
gain-type = xsd:int { minInclusive = "-127" maxInclusive = "127" }
# VIDEO LAYOUT TYPE
video-layout-type =
xsd:string "single-view"
| xsd:string "dual-view"
| xsd:string "dual-view-crop"
| xsd:string "dual-view-2x1"
| xsd:string "dual-view-2x1-crop"
Novo, et al. Expires October 29, 2011 [Page 37]
Internet-Draft Data Model Schema April 2011
| xsd:string "quad-view"
| xsd:string "multiple-3x3"
| xsd:string "multiple-4x4"
| xsd:string "multiple-5x1"
| xsd:string "automatic"
| free-text-extension
# FLOOR INFORMATION TYPE
floor-information-type =
anyAttribute
& element xcon:conference-ID { xsd:unsignedLong }?
& element xcon:allow-floor-events { xsd:boolean }?
& element xcon:floor-request-handling { floor-request-type }?
& element xcon:conference-floor-policy { conference-floor-policy }?
& anyElement*
# FLOOR REQUEST TYPE
floor-request-type =
xsd:string "block" | xsd:string "confirm" | free-text-extension
# CONFERENCE FLOOR POLICY
conference-floor-policy =
anyAttribute
& element xcon:floor {
attribute id { text }
& anyAttribute
& element xcon:media-label { xsd:nonNegativeInteger }+
& element xcon:algorithm { algorithm-type }?
& element xcon:max-floor-users { xsd:nonNegativeInteger }?
& element xcon:moderator-id { xsd:nonNegativeInteger }?
& anyElement*
}+
# ALGORITHM POLICY
algorithm-type =
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "random"
| free-text-extension
# USERS ADMISSION POLICY
user-admission-policy-type =
xsd:string "closedAuthenticated"
| xsd:string "openAuthenticated"
| xsd:string "anonymous"
| free-text-extension
# JOIN HANDLING TYPE
join-handling-type =
xsd:string "block"
| xsd:string "confirm"
| xsd:string "allow"
| xsd:string "authenticate"
| xsd:string "directed-operator"
Novo, et al. Expires October 29, 2011 [Page 38]
Internet-Draft Data Model Schema April 2011
| free-text-extension
# DENY USERLIST
deny-user-list-type =
anyAttribute
& element xcon:target {
attribute uri { xsd:anyURI },
anyAttribute
}*
& anyElement*
# ALLOWED USERS LIST TYPE
allowed-users-list-type =
anyAttribute
& element xcon:target { target-type }*
& element xcon:persistent-list { persistent-list-type }?
& anyElement*
# PERSISTENT LIST TYPE
persistent-list-type =
element xcon:user {
attribute name { text }
& attribute nickname { text }
& attribute id { text }
& anyAttribute
& element xcon:e-mail { text }*
& anyElement*
}*
& anyElement*
# TARGET TYPE
target-type =
attribute uri { xsd:anyURI },
attribute method { method-type },
anyAttribute
# METHOD TYPE
method-type =
xsd:string "dial-in"
| xsd:string "dial-out"
| xsd:string "refer"
| free-text-extension
# ANONYMITY TYPE
provide-anonymity-type =
"private" | "semi-private" | "hidden" | free-text-extension
# MIXER TYPE
mixer-type =
attribute name { mixer-name-type }
& anyAttribute
& element xcon:controls { control-type }*
& element xcon:floor {
attribute id { text },
anyAttribute,
Novo, et al. Expires October 29, 2011 [Page 39]
Internet-Draft Data Model Schema April 2011
xsd:boolean
}*
& anyElement*
# MIXER NAME TYPE
mixer-name-type =
"VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension
# FREE TEXT EXTENSION
#
free-text-extension = text
# *********************************
# EXTENSIBILITY OF THE SCHEMA
# *********************************
# EXTENSIBILITY ELEMENTS
#
anyElement =
element * - (conference-description
| host-info
| conference-state
| users
| sidebars-by-ref
| sidebars-by-val
| display-text
| subject
| free-text
| keywords
| conf-uris
| service-uris
| maximum-user-count
| available-media
| web-page
| uris
| uri
| user-count
| active
| locked
| entry
| type
| status
| purpose
| modified
| user
| associated-aors
| roles
Novo, et al. Expires October 29, 2011 [Page 40]
Internet-Draft Data Model Schema April 2011
| languages
| cascaded-focus
| endpoint
| referred
| joining-method
| joining-info
| disconnection-method
| disconnection-info
| media
| call-info
| when
| reason
| by
| sip
| call-id
| from-tag
| to-tag
| label
| src-id
| xcon:conference-password
| xcon:mixing-mode
| xcon:codecs
| xcon:controls
| xcon:language
| xcon:allow-sidebars
| xcon:cloning-parent
| xcon:sidebar-parent
| xcon:allow-conference-event-subscription
| xcon:to-mixer
| xcon:provide-anonymity
| xcon:allow-refer-users-dynamically
| xcon:allow-invite-users-dynamically
| xcon:allow-remove-users-dynamically
| xcon:from-mixer
| xcon:join-handling
| xcon:user-admission-policy
| xcon:allowed-users-list
| xcon:deny-users-list
| xcon:floor-information
| xcon:conference-time
| xcon:provide-anonymity
| xcon:floor
| xcon:entry
| xcon:mixing-start-offset
| xcon:mixing-end-offset
| xcon:can-join-after-offset
| xcon:must-join-before-offset
| xcon:request-user
Novo, et al. Expires October 29, 2011 [Page 41]
Internet-Draft Data Model Schema April 2011
| xcon:notify-end-of-conference
| xcon:allowed-extend-mixing-end-offset
| xcon:codec
| xcon:subtype
| xcon:mute
| xcon:pause-video
| xcon:gain
| xcon:video-layout
| xcon:conference-ID
| xcon:allow-floor-events
| xcon:floor-request-handling
| xcon:conference-floor-policy
| xcon:media-label
| xcon:algorithm
| xcon:max-floor-users
| xcon:moderator-id
| xcon:target
| xcon:persistent-list
| xcon:e-mail
| xcon:user) { anyExtension }
anyExtension =
(attribute * { text }
| any)*
any =
element * {
(attribute * { text }
| text
| any)*
}
# EXTENSIBILITY ATTRIBUTES
#
anyAttribute =
attribute * - (xml:lang
| entity
| required-participant
| label
| decision
| name
| policy
| uri
| method
| id
| nickname) { text }*
Novo, et al. Expires October 29, 2011 [Page 42]
Internet-Draft Data Model Schema April 2011
6. XML Schema Extensibility
The Conference Information Data Model defined in this document is
meant to be extensible toward specific application domains. Such
extensions are accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. The
IETF MAY extend the data model schema with unqualified attributes or
extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace"
in the future. Other instances are free to define extension elements
or attributes under other namespaces.
Elements or attributes from unknown namespaces MUST be ignored.
7. XML Example
The following is an example of a conference information document.
The conference starts on October 17, 2007, at 10:30 AM in New York
City and finishes the same day at 12:30 PM every week. In this
example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Sidebars are
allowed in this conference and ,consequently, there is one sidebar in
the conference. In addition, Alice and Carol are using a floor in
the main conference to manage the audio and video resources. At the
moment, Alice is assigned to use the floor.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="conference123@example.com">
<!--
CONFERENCE DESCRIPTION
-->
<conference-description xml:lang="en-us">
<display-text>Discussion of Formula-1 racing</display-text>
<subject>Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
<keywords>Formula-1 cars</keywords>
<!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<conf-uris>
<entry>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
Novo, et al. Expires October 29, 2011 [Page 43]
Internet-Draft Data Model Schema April 2011
<xcon:conference-password
>5678</xcon:conference-password>
</entry>
<entry>
<uri>http://www.example.com/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>50</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<available-media>
<entry label="10234">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<xcon:mixing-mode>automatic</xcon:mixing-mode>
<xcon:codecs decision="automatic">
<xcon:codec name="122" policy="allowed">
<xcon:subtype>PCMU</xcon:subtype>
</xcon:codec>
</xcon:codecs>
<xcon:controls>
<xcon:mute>true</xcon:mute>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</entry>
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<xcon:mixing-mode>automatic</xcon:mixing-mode>
<xcon:codecs decision="automatic">
<xcon:codec name="123" policy="allowed">
<xcon:subtype>H.263</xcon:subtype>
Novo, et al. Expires October 29, 2011 [Page 44]
Internet-Draft Data Model Schema April 2011
</xcon:codec>
</xcon:codecs>
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</entry>
</available-media>
<xcon:language>En-us</xcon:language>
<xcon:allow-sidebars>true</xcon:allow-sidebars>
<!--
CONFERENCE TIME
-->
<xcon:conference-time>
<xcon:entry>
<xcon:base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20071003T140728Z
UID:20071003T140728Z-345FDA-carol@example.com
ORGANIZER:MAILTO:carol@example.com
DTSTART:20071017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20071217T163000Z
END:VEVENT
END:VCALENDAR</xcon:base>
<xcon:mixing-start-offset
required-participant="moderator"
>2007-10-17T14:29:00Z</xcon:mixing-start-offset>
<xcon:mixing-end-offset
required-participant="participant"
>2007-10-17T16:31:00Z</xcon:mixing-end-offset>
<xcon:must-join-before-offset
>2007-10-17T15:30:00Z
</xcon:must-join-before-offset>
</xcon:entry>
</xcon:conference-time>
</conference-description>
<!--
HOST INFO
Novo, et al. Expires October 29, 2011 [Page 45]
Internet-Draft Data Model Schema April 2011
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page>
<uris>
<entry>
<uri>sip:alice@example.com</uri>
</entry>
<entry>
<uri>sip:carol@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
<xcon:allow-conference-event-subscription
>true</xcon:allow-conference-event-subscription>
</conference-state>
<!--
USERS
-->
<users>
<!--
USER BOB
-->
<user entity="xcon-userid:bob534">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com">
Novo, et al. Expires October 29, 2011 [Page 46]
Internet-Draft Data Model Schema April 2011
<display-text>Bob's Laptop</display-text>
<referred>
<when>2007-10-17T14:00:00Z</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2007-10-17T14:00:00Z</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
<xcon:provide-anonymity
>semi-private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>false</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>false</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>false</xcon:allow-remove-users-dynamically>
Novo, et al. Expires October 29, 2011 [Page 47]
Internet-Draft Data Model Schema April 2011
</user>
<!--
USER ALICE
-->
<user entity="xcon-userid:alice334">
<display-text>Alice Kay</display-text>
<associated-aors>
<entry>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>moderator</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:35:08Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
Novo, et al. Expires October 29, 2011 [Page 48]
Internet-Draft Data Model Schema April 2011
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
<xcon:floor id="345">true</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user>
<!--
USER CAROL
-->
<user entity="xcon-userid:carol233">
<display-text>Carol More</display-text>
<associated-aors>
<entry>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>administrator</entry>
</roles>
Novo, et al. Expires October 29, 2011 [Page 49]
Internet-Draft Data Model Schema April 2011
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:30:05Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
Novo, et al. Expires October 29, 2011 [Page 50]
Internet-Draft Data Model Schema April 2011
<sip>
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
<xcon:floor id="345">false</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user>
<xcon:join-handling>allow</xcon:join-handling>
<xcon:user-admission-policy
>openAuthenticated</xcon:user-admission-policy>
<!--
ALLOWED USERS LIST
-->
<xcon:allowed-users-list>
<xcon:target uri="sip:bob@example.com"
method="dial-out"/>
<xcon:target uri="sip:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
<xcon:target uri="sip:john@example.com"
method="refer"/>
</xcon:allowed-users-list>
<!--
DENY USERS LIST
-->
<xcon:deny-users-list>
<xcon:target uri="sip:charlie@example.com"/>
</xcon:deny-users-list>
</users>
<!--
SIDEBARS BY REFERENCE
-->
Novo, et al. Expires October 29, 2011 [Page 51]
Internet-Draft Data Model Schema April 2011
<sidebars-by-ref>
<entry>
<uri>xcon:conf223</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="conf223">
<users>
<user entity="xcon-userid:bob534"/>
<user entity="xcon-userid:carol233"/>
</users>
</entry>
</sidebars-by-val>
<!--
FLOOR INFORMATION
-->
<xcon:floor-information>
<xcon:conference-ID>567</xcon:conference-ID>
<xcon:allow-floor-events>true</xcon:allow-floor-events>
<xcon:floor-request-handling
>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="345">
<xcon:media-label>10234</xcon:media-label>
<xcon:media-label>10235</xcon:media-label>
<xcon:algorithm
>moderator-controlled</xcon:algorithm>
<xcon:max-floor-users>1</xcon:max-floor-users>
<xcon:moderator-id>234</xcon:moderator-id>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters.
8. Security Considerations
There are numerous security considerations for this document. This
section discusses them. Overall, the security considerations for
Novo, et al. Expires October 29, 2011 [Page 52]
Internet-Draft Data Model Schema April 2011
authentication (Section 11) and the Security and Privacy of Identity
(Section 11.2) described in the centralized conferencing framework
[RFC5239] applies to this document.
This specification defines a data model for conference objects.
Different conferencing systems may use different protocols to provide
access to these conference objects. This section contains general
security considerations for the conference objects and for the
protocols. The specification of each particular protocol needs to
discuss how the specific protocol meets the security requirements
provided in this section.
A given conferencing system usually supports different protocols in
order to implement different functions (e.g., SIP for session control
and BFCP for floor control). Each of these protocols may use their
own authentication mechanism. In cases where a user is authenticated
using multiple authentication mechanisms, it is up to the
conferencing system to map all the different authentications to the
same user. Discussing the specifics of different authentication
mechanism is beyond the scope of this document.
Furthermore, users may use different identifiers to access to a
conference as explained in Section 4.6.5. These different namespaces
can be associated with a unique conference user identifier (XCON-
USERID). A mapping database is used to map all these authenticated
user namespaces to the XCON-USERID. There are several threats
against this database. In order to minimize these threats, the
administrator of the conferencing system MUST ensure that only
authorized users can connect to this database (e.g., by using access
control rules). In particular, the integrity of the database MUST be
protected against unauthorized modifications. Generic security
considerations for usage of URIs are discussed in [RFC3986]. There
is no other encoding considerations for XCON-USERID or XCON-URI not
discussed in RFC 3986 [RFC3986].
The confidentiality of the database SHOULD be protected from
unauthorized users, given that the data model contains a set of
sensitive elements (e.g., passwords). Therefore, in addition to
implementing access control, as discussed above, it is RECOMMENDED
that administrators of conferencing systems only provide access to
the database over encrypted channels (e.g., using TLS encryption) in
order to avoid eavesdroppers. Administrators of conferencing systems
SHOULD also avoid disclosing information to unauthorized parties when
a conference is being cloned or when a sidebar is being created. For
example, an external sidebar as defined in [RFC5239], section 9.4.2,
may include participants who were not authorized for the parent
conference.
Novo, et al. Expires October 29, 2011 [Page 53]
Internet-Draft Data Model Schema April 2011
The security considerations for authentication (Section 11.1)
described in the centralized conferencing framework [RFC5239] also
apply to this document. Similarly, the security considerations for
authorization (Section 5.2) described in the Session Initiation
Protocol (SIP) REFER Method [RFC3515] apply to this document as well.
9. IANA Considerations
9.1. Relax NG Schema Registration
This specification registers a schema. The schema can be found
as the sole content of Section 5.
URI: urn:ietf:params:xml:schema:xcon-conference-info
Registrant Contact: IETF XCON working group,
<xcon@ietf.org>, Oscar Novo
<Oscar.Novo@ericsson.com>
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 5. Its first line is
default namespace = "urn:ietf:params:xml:ns:conference-info"
and its last line is
anyAttribute = attribute * - (xml:lang | entity
| required-participant | label | decision | name
| policy | uri | method | id | nickname) { text }*
9.2. XML Namespace Registration
Novo, et al. Expires October 29, 2011 [Page 54]
Internet-Draft Data Model Schema April 2011
This section registers a new XML namespace.
URI: urn:ietf:params:xml:ns:xcon-conference-info
Registrant Contact: IETF XCON working group,
<xcon@ietf.org>, Oscar Novo
<Oscar.Novo@ericsson.com>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title> Centralized Conferencing Namespace</title>
</head>
<body>
<h1>Namespace for Centralized Conferencing</h1>
<h2>urn:ietf:params:xml:ns:xcon-conference-info</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
9.3. Conference Object Identifier Registration
The IANA is requested to register the following URI scheme
under the Permanent URI Schemes registry.
XCON-URI = "xcon" ":" [conf-object-id "@"] host
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host and unreserved are defined in [RFC3986]
Novo, et al. Expires October 29, 2011 [Page 55]
Internet-Draft Data Model Schema April 2011
URI scheme name: xcon
Status: permanent
URI scheme syntax: see Section 3.3.1.
URI schema semantics: see Section 3.3
Encoding considerations: see Section 8
Intended usage: see Section 3.3
Applications and/or protocols that use this URI scheme name:
Centralized Conferencing systems
Interoperability considerations: none
Security considerations: see Section 8
Relevant publications: Conference Information Data Model for
Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com>
9.4. Conference User Identifier Registration
The IANA is requested to register the following URI scheme
under the Permanent URI Schemes registry.
XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*unreserved
unreserved is defined in [RFC3986]
URI scheme name: xcon-userid
Status: permanent
URI scheme syntax: see Section 4.6.5
URI schema semantics: see Section 4.6.5
Encoding considerations: see Section 8
Intended usage: see Section 4.6.3 and 4.6.5
Applications and/or protocols that use this URI scheme name:
Centralized Conferencing systems.
Interoperability considerations: none
Security considerations: see Section 8
Relevant publications: Conference Information Data Model for
Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com>
Novo, et al. Expires October 29, 2011 [Page 56]
Internet-Draft Data Model Schema April 2011
10. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We
would like to thank Orit Levin, Roni Even, Adam Roach, Mary Barnes,
Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen,
Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy, Richard Barnes,
and Henning Schulzrinne for their comments. Also, we would like to
thank Mary Barnes, and Chris Boulton for letting us use the
conference and user identifier information of their xcon drafts.
Last but not least, we would like to express our gratitude to all
those reviewers for their invaluable contribution: Simon Pietro
Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia, Mary Barnes,
Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and Ben Campbell.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
Novo, et al. Expires October 29, 2011 [Page 57]
Internet-Draft Data Model Schema April 2011
11.2. Informative References
[IANA] "IANA registry for RTP Payload Types"
"http://www.iana.org/assignments/rtp-parameters".
[IANA-Lan]
"IANA Language Subtag Registry"
"http://www.iana.org/assignments/
language-subtag-registry".
[RELAX] "RELAX NG Home Page" "http://relaxng.org/".
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5018] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[W3C.REC-xml-20081126]
Yergeau, F., Sperberg-McQueen, C., Paoli, J., Maler, E.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8" ?>
<grammar
ns="urn:ietf:params:xml:ns:conference-info"
Novo, et al. Expires October 29, 2011 [Page 58]
Internet-Draft Data Model Schema April 2011
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<element name="conference-info">
<ref name="conference-type"/>
</element>
</start>
<!--
CONFERENCE TYPE
-->
<define name="conference-type">
<interleave>
<attribute name="entity">
<text/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<ref name="conference-description-type"/>
</optional>
<optional>
<element name="host-info">
<ref name="host-type"/>
</element>
</optional>
<optional>
<element name="conference-state">
<ref name="conference-state-type"/>
</element>
</optional>
<optional>
<element name="users">
<ref name="users-type"/>
</element>
</optional>
<optional>
<element name="sidebars-by-ref">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="sidebars-by-val">
<ref name="sidebars-by-val-type"/>
</element>
</optional>
<optional>
<element name="xcon:floor-information">
<ref name="floor-information-type"/>
Novo, et al. Expires October 29, 2011 [Page 59]
Internet-Draft Data Model Schema April 2011
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<define name="conference-description-type">
<element name="conference-description">
<interleave>
<optional>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</optional>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="subject">
<text/>
</element>
</optional>
<optional>
<element name="free-text">
<text/>
</element>
</optional>
<optional>
<element name="keywords">
<list>
<zeroOrMore>
<data type="string"/>
</zeroOrMore>
</list>
</element>
</optional>
<optional>
<element name="conf-uris">
<ref name="uris-type"/>
</element>
</optional>
Novo, et al. Expires October 29, 2011 [Page 60]
Internet-Draft Data Model Schema April 2011
<optional>
<element name="service-uris">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="maximum-user-count">
<data type="int"/>
</element>
</optional>
<optional>
<element name="available-media">
<ref name="conference-media-type"/>
</element>
</optional>
<optional>
<element name="xcon:language">
<data type="language"/>
</element>
</optional>
<optional>
<element name="xcon:allow-sidebars">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:cloning-parent">
<data type="anyURI"/>
</element>
</optional>
<optional>
<element name="xcon:sidebar-parent">
<data type="anyURI"/>
</element>
</optional>
<optional>
<element name="xcon:conference-time">
<ref name="conferencetime-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</element>
</define>
<!--
HOST TYPE
Novo, et al. Expires October 29, 2011 [Page 61]
Internet-Draft Data Model Schema April 2011
-->
<define name="host-type">
<interleave>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="web-page">
<data type="anyURI"/>
</element>
</optional>
<optional>
<element name="uris">
<ref name="uris-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
<ref name="anyAttribute"/>
</interleave>
</define>
<!--
CONFERENCE STATE TYPE
-->
<define name="conference-state-type">
<interleave>
<ref name="anyAttribute"/>
<optional>
<element name="user-count">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="active">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="locked">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:allow-conference-event-subscription">
<data type="boolean"/>
Novo, et al. Expires October 29, 2011 [Page 62]
Internet-Draft Data Model Schema April 2011
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
CONFERENCE MEDIA TYPE
-->
<define name="conference-media-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<ref name="conference-medium-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
CONFERENCE MEDIUM TYPE
-->
<define name="conference-medium-type">
<interleave>
<attribute name="label">
<text/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="type">
<text/>
</element>
</optional>
<optional>
<element name="status">
<ref name="media-status-type"/>
</element>
</optional>
<optional>
Novo, et al. Expires October 29, 2011 [Page 63]
Internet-Draft Data Model Schema April 2011
<element name="xcon:mixing-mode">
<ref name="mixing-mode-type"/>
</element>
</optional>
<optional>
<element name="xcon:codecs">
<ref name="codecs-type"/>
</element>
</optional>
<optional>
<element name="xcon:controls">
<ref name="control-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
URIs TYPE
-->
<define name="uris-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<ref name="uri-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
URI TYPE
-->
<define name="uri-type">
<interleave>
<element name="uri">
<data type="anyURI"/>
</element>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
Novo, et al. Expires October 29, 2011 [Page 64]
Internet-Draft Data Model Schema April 2011
<optional>
<element name="purpose">
<text/>
</element>
</optional>
<optional>
<element name="modified">
<ref name="execution-type"/>
</element>
</optional>
<zeroOrMore>
<element name="xcon:conference-password">
<text/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
<ref name="anyAttribute"/>
</interleave>
</define>
<!--
USERS TYPE
-->
<define name="users-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="user">
<ref name="user-type"/>
</element>
</zeroOrMore>
<optional>
<element name="xcon:join-handling">
<ref name="join-handling-type"/>
</element>
</optional>
<optional>
<element name="xcon:user-admission-policy">
<ref name="user-admission-policy-type"/>
</element>
</optional>
<optional>
<element name="xcon:allowed-users-list">
<ref name="allowed-users-list-type"/>
</element>
</optional>
Novo, et al. Expires October 29, 2011 [Page 65]
Internet-Draft Data Model Schema April 2011
<optional>
<element name="xcon:deny-users-list">
<ref name="deny-user-list-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
USER TYPE
-->
<define name="user-type">
<interleave>
<attribute name="entity">
<data type="anyURI"/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="associated-aors">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="roles">
<oneOrMore>
<element name="entry">
<ref name="single-role-type"/>
</element>
</oneOrMore>
</element>
</optional>
<optional>
<element name="languages">
<list>
<data type="language"/>
</list>
</element>
</optional>
<optional>
<element name="cascaded-focus">
<data type="anyURI"/>
Novo, et al. Expires October 29, 2011 [Page 66]
Internet-Draft Data Model Schema April 2011
</element>
</optional>
<zeroOrMore>
<element name="endpoint">
<ref name="endpoint-type"/>
</element>
</zeroOrMore>
<optional>
<element name="xcon:provide-anonymity">
<ref name="provide-anonymity-type"/>
</element>
</optional>
<optional>
<element name="xcon:allow-refer-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:allow-invite-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:allow-remove-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
ENDPOINT TYPE
-->
<define name="endpoint-type">
<interleave>
<attribute name="entity">
<text/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="referred">
Novo, et al. Expires October 29, 2011 [Page 67]
Internet-Draft Data Model Schema April 2011
<ref name="execution-type"/>
</element>
</optional>
<optional>
<element name="status">
<ref name="endpoint-status-type"/>
</element>
</optional>
<optional>
<element name="joining-method">
<ref name="joining-type"/>
</element>
</optional>
<optional>
<element name="joining-info">
<ref name="execution-type"/>
</element>
</optional>
<optional>
<element name="disconnection-method">
<ref name="disconnection-type"/>
</element>
</optional>
<optional>
<element name="disconnection-info">
<ref name="execution-type"/>
</element>
</optional>
<zeroOrMore>
<element name="media">
<ref name="media-type"/>
</element>
</zeroOrMore>
<optional>
<element name="call-info">
<ref name="call-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
ENDPOINT STATUS TYPE
-->
<define name="endpoint-status-type">
<choice>
Novo, et al. Expires October 29, 2011 [Page 68]
Internet-Draft Data Model Schema April 2011
<value>pending</value>
<value>dialing-out</value>
<value>dialing-in</value>
<value>alerting</value>
<value>on-hold</value>
<value>connected</value>
<value>muted-via-focus</value>
<value>disconnecting</value>
<value>disconnected</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
JOINING TYPE
-->
<define name="joining-type">
<choice>
<value>dialed-in</value>
<value>dialed-out</value>
<value>focus-owner</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
DISCONNECTION TYPE
-->
<define name="disconnection-type">
<choice>
<value>departed</value>
<value>booted</value>
<value>failed</value>
<value>busy</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
EXECUTION TYPE
-->
<define name="execution-type">
<interleave>
<optional>
<element name="when">
<data type="dateTime"/>
</element>
</optional>
<optional>
<element name="reason">
<text/>
Novo, et al. Expires October 29, 2011 [Page 69]
Internet-Draft Data Model Schema April 2011
</element>
</optional>
<optional>
<element name="by">
<data type="anyURI"/>
</element>
</optional>
<ref name="anyAttribute"/>
</interleave>
</define>
<!--
CALL TYPE
-->
<define name="call-type">
<interleave>
<element name="sip">
<ref name="sip-dialog-id-type"/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
<ref name="anyAttribute"/>
</interleave>
</define>
<!--
SIP DIALOG ID TYPE
-->
<define name="sip-dialog-id-type">
<interleave>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<element name="call-id">
<text/>
</element>
<element name="from-tag">
<text/>
</element>
<element name="to-tag">
<text/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
<ref name="anyAttribute"/>
</interleave>
Novo, et al. Expires October 29, 2011 [Page 70]
Internet-Draft Data Model Schema April 2011
</define>
<!--
MEDIA TYPE
-->
<define name="media-type">
<interleave>
<attribute name="id">
<data type="int"/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="type">
<text/>
</element>
</optional>
<optional>
<element name="label">
<text/>
</element>
</optional>
<optional>
<element name="src-id">
<text/>
</element>
</optional>
<optional>
<element name="status">
<ref name="media-status-type"/>
</element>
</optional>
<optional>
<element name="xcon:to-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<optional>
<element name="xcon:from-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
Novo, et al. Expires October 29, 2011 [Page 71]
Internet-Draft Data Model Schema April 2011
</interleave>
</define>
<!--
MEDIA STATUS TYPE
-->
<define name="media-status-type">
<choice>
<value>recvonly</value>
<value>sendonly</value>
<value>sendrecv</value>
<value>inactive</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
SIDEBARS-BY-VAL TYPE
-->
<define name="sidebars-by-val-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<ref name="conference-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
CONFERENCE TIME
-->
<define name="conferencetime-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:entry">
<element name="xcon:base">
<text/>
</element>
<optional>
<element name="xcon:mixing-start-offset">
<ref name="time-type"/>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
Novo, et al. Expires October 29, 2011 [Page 72]
Internet-Draft Data Model Schema April 2011
</element>
</optional>
<optional>
<element name="xcon:mixing-end-offset">
<ref name="time-type"/>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</optional>
<optional>
<element name="xcon:can-join-after-offset">
<ref name="time-type"/>
</element>
</optional>
<optional>
<element name="xcon:must-join-before-offset">
<ref name="time-type"/>
</element>
</optional>
<optional>
<element name="xcon:request-user">
<ref name="time-type"/>
</element>
</optional>
<optional>
<element name="xcon:notify-end-of-conference">
<data type="int"/>
</element>
</optional>
<optional>
<element name="xcon:allowed-extend-mixing-end-offset">
<data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element>
</zeroOrMore>
</interleave>
</define>
<!--
TIME TYPE
-->
<define name="time-type">
<data type="dateTime">
Novo, et al. Expires October 29, 2011 [Page 73]
Internet-Draft Data Model Schema April 2011
<param name="pattern">.+T.+Z.*</param>
</data>
</define>
<!--
SINGLE ROLE TYPE
-->
<define name="single-role-type">
<choice>
<value type="string">none</value>
<value type="string">administrator</value>
<value type="string">moderator</value>
<value type="string">user</value>
<value type="string">observer</value>
<value type="string">participant</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
MIXING MODE TYPE
-->
<define name="mixing-mode-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">automatic</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
CODECS TYPE
-->
<define name="codecs-type">
<interleave>
<attribute name="decision">
<ref name="decision-type"/>
</attribute>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:codec">
<ref name="codec-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
Novo, et al. Expires October 29, 2011 [Page 74]
Internet-Draft Data Model Schema April 2011
CODEC TYPE
-->
<define name="codec-type">
<interleave>
<attribute name="name">
<text/>
</attribute>
<attribute name="policy">
<ref name="policy-type"/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="xcon:subtype">
<text/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
DECISION TYPE
-->
<define name="decision-type">
<choice>
<value type="string">automatic</value>
<value type="string">moderator-controlled</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
POLICY TYPE
-->
<define name="policy-type">
<choice>
<value type="string">allowed</value>
<value type="string">disallowed</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
CONTROL TYPE
-->
<define name="control-type">
<interleave>
<ref name="anyAttribute"/>
<optional>
Novo, et al. Expires October 29, 2011 [Page 75]
Internet-Draft Data Model Schema April 2011
<element name="xcon:mute">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:pause-video">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:gain">
<ref name="gain-type"/>
</element>
</optional>
<optional>
<element name="xcon:video-layout">
<ref name="video-layout-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
GAIN TYPE
-->
<define name="gain-type">
<data type="int">
<param name="minInclusive">-127</param>
<param name="maxInclusive">127</param>
</data>
</define>
<!--
VIDEO LAYOUT TYPE
-->
<define name="video-layout-type">
<choice>
<value type="string">single-view</value>
<value type="string">dual-view</value>
<value type="string">dual-view-crop</value>
<value type="string">dual-view-2x1</value>
<value type="string">dual-view-2x1-crop</value>
<value type="string">quad-view</value>
<value type="string">multiple-3x3</value>
Novo, et al. Expires October 29, 2011 [Page 76]
Internet-Draft Data Model Schema April 2011
<value type="string">multiple-4x4</value>
<value type="string">multiple-5x1</value>
<value type="string">automatic</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
FLOOR INFORMATION TYPE
-->
<define name="floor-information-type">
<interleave>
<ref name="anyAttribute"/>
<optional>
<element name="xcon:conference-ID">
<data type="unsignedLong"/>
</element>
</optional>
<optional>
<element name="xcon:allow-floor-events">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:floor-request-handling">
<ref name="floor-request-type"/>
</element>
</optional>
<optional>
<element name="xcon:conference-floor-policy">
<ref name="conference-floor-policy"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
FLOOR REQUEST TYPE
-->
<define name="floor-request-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
Novo, et al. Expires October 29, 2011 [Page 77]
Internet-Draft Data Model Schema April 2011
CONFERENCE FLOOR POLICY
-->
<define name="conference-floor-policy">
<interleave>
<ref name="anyAttribute"/>
<oneOrMore>
<element name="xcon:floor">
<interleave>
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<oneOrMore>
<element name="xcon:media-label">
<data type="nonNegativeInteger"/>
</element>
</oneOrMore>
<optional>
<element name="xcon:algorithm">
<ref name="algorithm-type"/>
</element>
</optional>
<optional>
<element name="xcon:max-floor-users">
<data type="nonNegativeInteger"/>
</element>
</optional>
<optional>
<element name="xcon:moderator-id">
<data type="nonNegativeInteger"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</element>
</oneOrMore>
</interleave>
</define>
<!--
ALGORITHM POLICY
-->
<define name="algorithm-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">random</value>
Novo, et al. Expires October 29, 2011 [Page 78]
Internet-Draft Data Model Schema April 2011
<ref name="free-text-extension"/>
</choice>
</define>
<!--
USERS ADMISSION POLICY
-->
<define name="user-admission-policy-type">
<choice>
<value type="string">closedAuthenticated</value>
<value type="string">openAuthenticated</value>
<value type="string">anonymous</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
JOIN HANDLING TYPE
-->
<define name="join-handling-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
<value type="string">allow</value>
<value type="string">authenticate</value>
<value type="string">directed-operator</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
DENY USERLIST
-->
<define name="deny-user-list-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:target">
<attribute name="uri">
<data type="anyURI"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
Novo, et al. Expires October 29, 2011 [Page 79]
Internet-Draft Data Model Schema April 2011
ALLOWED USERS LIST TYPE
-->
<define name="allowed-users-list-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:target">
<ref name="target-type"/>
</element>
</zeroOrMore>
<optional>
<element name="xcon:persistent-list">
<ref name="persistent-list-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
PERSISTENT LIST TYPE
-->
<define name="persistent-list-type">
<interleave>
<zeroOrMore>
<element name="xcon:user">
<interleave>
<attribute name="name">
<text/>
</attribute>
<attribute name="nickname">
<text/>
</attribute>
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:e-mail">
<text/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</element>
Novo, et al. Expires October 29, 2011 [Page 80]
Internet-Draft Data Model Schema April 2011
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
TARGET TYPE
-->
<define name="target-type">
<attribute name="uri">
<data type="anyURI"/>
</attribute>
<attribute name="method">
<ref name="method-type"/>
</attribute>
<ref name="anyAttribute"/>
</define>
<!--
METHOD TYPE
-->
<define name="method-type">
<choice>
<value type="string">dial-in</value>
<value type="string">dial-out</value>
<value type="string">refer</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
ANONYMITY TYPE
-->
<define name="provide-anonymity-type">
<choice>
<value>private</value>
<value>semi-private</value>
<value>hidden</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
MIXER TYPE
-->
<define name="mixer-type">
<interleave>
<attribute name="name">
<ref name="mixer-name-type"/>
</attribute>
Novo, et al. Expires October 29, 2011 [Page 81]
Internet-Draft Data Model Schema April 2011
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:floor">
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<data type="boolean"/>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="xcon:controls">
<ref name="control-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
MIXER NAME TYPE
-->
<define name="mixer-name-type">
<choice>
<value>VideoIn</value>
<value>VideoOut</value>
<value>AudioOut</value>
<value>AudioIn</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
FREE TEXT EXTENSION
-->
<define name="free-text-extension">
<text/>
</define>
<!--
*********************************
EXTENSIBILITY OF THE SCHEMA
*********************************
-->
<!--
EXTENSIBILITY ELEMENTS
-->
<define name="anyElement">
Novo, et al. Expires October 29, 2011 [Page 82]
Internet-Draft Data Model Schema April 2011
<element>
<anyName>
<except>
<name>conference-description</name>
<name>host-info</name>
<name>conference-state</name>
<name>users</name>
<name>sidebars-by-ref</name>
<name>sidebars-by-val</name>
<name>display-text</name>
<name>subject</name>
<name>free-text</name>
<name>keywords</name>
<name>conf-uris</name>
<name>service-uris</name>
<name>maximum-user-count</name>
<name>available-media</name>
<name>web-page</name>
<name>uris</name>
<name>uri</name>
<name>user-count</name>
<name>active</name>
<name>locked</name>
<name>entry</name>
<name>type</name>
<name>status</name>
<name>purpose</name>
<name>modified</name>
<name>user</name>
<name>associated-aors</name>
<name>roles</name>
<name>languages</name>
<name>cascaded-focus</name>
<name>endpoint</name>
<name>referred</name>
<name>joining-method</name>
<name>joining-info</name>
<name>disconnection-method</name>
<name>disconnection-info</name>
<name>media</name>
<name>call-info</name>
<name>when</name>
<name>reason</name>
<name>by</name>
<name>sip</name>
<name>call-id</name>
<name>from-tag</name>
<name>to-tag</name>
Novo, et al. Expires October 29, 2011 [Page 83]
Internet-Draft Data Model Schema April 2011
<name>label</name>
<name>src-id</name>
<name>xcon:conference-password</name>
<name>xcon:mixing-mode</name>
<name>xcon:codecs</name>
<name>xcon:controls</name>
<name>xcon:language</name>
<name>xcon:allow-sidebars</name>
<name>xcon:cloning-parent</name>
<name>xcon:sidebar-parent</name>
<name>xcon:allow-conference-event-subscription</name>
<name>xcon:to-mixer</name>
<name>xcon:provide-anonymity</name>
<name>xcon:allow-refer-users-dynamically</name>
<name>xcon:allow-invite-users-dynamically</name>
<name>xcon:allow-remove-users-dynamically</name>
<name>xcon:from-mixer</name>
<name>xcon:join-handling</name>
<name>xcon:user-admission-policy</name>
<name>xcon:allowed-users-list</name>
<name>xcon:deny-users-list</name>
<name>xcon:floor-information</name>
<name>xcon:conference-time</name>
<name>xcon:provide-anonymity</name>
<name>xcon:floor</name>
<name>xcon:entry</name>
<name>xcon:mixing-start-offset</name>
<name>xcon:mixing-end-offset</name>
<name>xcon:can-join-after-offset</name>
<name>xcon:must-join-before-offset</name>
<name>xcon:request-user</name>
<name>xcon:notify-end-of-conference</name>
<name>xcon:allowed-extend-mixing-end-offset</name>
<name>xcon:codec</name>
<name>xcon:subtype</name>
<name>xcon:mute</name>
<name>xcon:pause-video</name>
<name>xcon:gain</name>
<name>xcon:video-layout</name>
<name>xcon:conference-ID</name>
<name>xcon:allow-floor-events</name>
<name>xcon:floor-request-handling</name>
<name>xcon:conference-floor-policy</name>
<name>xcon:media-label</name>
<name>xcon:algorithm</name>
<name>xcon:max-floor-users</name>
<name>xcon:moderator-id</name>
<name>xcon:target</name>
Novo, et al. Expires October 29, 2011 [Page 84]
Internet-Draft Data Model Schema April 2011
<name>xcon:persistent-list</name>
<name>xcon:e-mail</name>
<name>xcon:user</name>
</except>
</anyName>
<ref name="anyExtension"/>
</element>
</define>
<define name="anyExtension">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="any"/>
</choice>
</zeroOrMore>
</define>
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice>
</zeroOrMore>
</element>
</define>
<!--
EXTENSIBILITY ATTRIBUTES
-->
<define name="anyAttribute">
<zeroOrMore>
<attribute>
<anyName>
<except>
<name ns="http://www.w3.org/XML/1998/namespace">lang
</name>
<name ns="">entity</name>
<name ns="">required-participant</name>
Novo, et al. Expires October 29, 2011 [Page 85]
Internet-Draft Data Model Schema April 2011
<name ns="">label</name>
<name ns="">decision</name>
<name ns="">name</name>
<name ns="">policy</name>
<name ns="">uri</name>
<name ns="">method</name>
<name ns="">id</name>
<name ns="">nickname</name>
</except>
</anyName>
</attribute>
</zeroOrMore>
</define>
</grammar>
Appendix B. Non-Normative W3C XML Schema
The non-normative W3C XML schema defines extension elements in the
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. Note that
<xs:any> extensions in this schema are stricter than in the normative
RELAX NG schema [RELAX], and the normative RELAX NG schema [RELAX]
allows unordered child elements unlike this schema (and the [RFC4575]
schema). Also note that this schema allows also otherwise valid
extension elements to appear in the non-allowed positions. Likewise
the cardinalities of these extension elements can not be constrained
with this schema.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info">
<xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="mixing-mode" type="mixing-mode-type"/>
<xs:element name="codecs" type="codecs-type"/>
<xs:element name="conference-password" type="xs:string"/>
<xs:element name="controls" type="controls-type"/>
<xs:element name="language" type="xs:language"/>
<xs:element name="allow-sidebars" type="xs:boolean"/>
Novo, et al. Expires October 29, 2011 [Page 86]
Internet-Draft Data Model Schema April 2011
<xs:element name="cloning-parent" type="xs:anyURI"/>
<xs:element name="sidebar-parent" type="xs:anyURI"/>
<xs:element name="conference-time" type="conference-time-type"/>
<xs:element name="allow-conference-event-subscription"
type="xs:boolean"/>
<xs:element name="to-mixer" type="mixer-type"/>
<xs:element name="provide-anonymity"
type="provide-anonymity-type"/>
<xs:element name="allow-refer-users-dynamically"
type="xs:boolean"/>
<xs:element name="allow-invite-users-dynamically"
type="xs:boolean"/>
<xs:element name="allow-remove-users-dynamically"
type="xs:boolean"/>
<xs:element name="from-mixer" type="mixer-type"/>
<xs:element name="join-handling" type="join-handling-type"/>
<xs:element name="user-admission-policy"
type="user-admission-policy-type"/>
<xs:element name="allowed-users-list"
type="allowed-users-list-type"/>
<xs:element name="deny-users-list" type="deny-users-list-type"/>
<xs:element name="floor-information" type="floor-information-type"/>
<!-- CONFERENCE TIME -->
<xs:complexType name="conference-time-type">
<xs:sequence>
<xs:element name="entry"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="base"
type="xs:string" minOccurs="1"/>
<xs:element name="mixing-start-offset" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="time-type">
<xs:attribute name="required-participant"
type="role-type" use="required"/>
<xs:anyAttribute namespace="##any"
processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="mixing-end-offset" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
Novo, et al. Expires October 29, 2011 [Page 87]
Internet-Draft Data Model Schema April 2011
<xs:extension base="time-type">
<xs:attribute name="required-participant"
type="role-type" use="required"/>
<xs:anyAttribute namespace="##any"
processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="can-join-after-offset" type="time-type"
minOccurs="0"/>
<xs:element name="must-join-before-offset"
type="time-type" minOccurs="0"/>
<xs:element name="request-user" type="time-type"
minOccurs="0"/>
<xs:element name="notify-end-of-conference"
type="xs:integer" minOccurs="0"/>
<xs:element name="allowed-extend-mixing-end-offset"
type="xs:boolean" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- TIME TYPE -->
<xs:simpleType name="time-type">
<xs:restriction base="xs:dateTime">
<xs:pattern value=".+T.+Z.*"/>
</xs:restriction>
</xs:simpleType>
<!-- ROLE-TYPE -->
<xs:simpleType name="role-type">
<xs:restriction base="xs:string">
<xs:pattern value="none"/>
<xs:pattern value="administrator"/>
<xs:pattern value="moderator"/>
<xs:pattern value="user"/>
<xs:pattern value="observer"/>
<xs:pattern value="participant"/>
Novo, et al. Expires October 29, 2011 [Page 88]
Internet-Draft Data Model Schema April 2011
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- MIXING MODE TYPE -->
<xs:simpleType name="mixing-mode-type">
<xs:restriction base="xs:string">
<xs:pattern value="moderator-controlled"/>
<xs:pattern value="FCFS"/>
<xs:pattern value="automatic"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- CODECS TYPE -->
<xs:complexType name="codecs-type">
<xs:sequence>
<xs:element name="codec" type="codec-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="decision"
type="decision-type" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CODEC TYPE -->
<xs:complexType name="codec-type">
<xs:sequence>
<xs:element name="subtype" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name"
type="xs:string" use="required"/>
<xs:attribute name="policy"
type="policy-type" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- DECISION TYPE -->
<xs:simpleType name="decision-type">
<xs:restriction base="xs:string">
<xs:pattern value="automatic"/>
Novo, et al. Expires October 29, 2011 [Page 89]
Internet-Draft Data Model Schema April 2011
<xs:pattern value="moderator-controlled"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- POLICY TYPE -->
<xs:simpleType name="policy-type">
<xs:restriction base="xs:string">
<xs:pattern value="allowed"/>
<xs:pattern value="disallowed"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- CONTROL TYPE -->
<xs:complexType name="controls-type">
<xs:sequence>
<xs:element name="mute"
type="xs:boolean" minOccurs="0"/>
<xs:element name="pause-video"
type="xs:boolean" minOccurs="0"/>
<xs:element name="gain"
type="gain-type" minOccurs="0"/>
<xs:element name="video-layout"
type="video-layout-type" default="single-view" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- GAIN TYPE -->
<xs:simpleType name="gain-type">
<xs:restriction base="xs:integer">
<xs:minInclusive value="-127"/>
<xs:maxInclusive value="127"/>
</xs:restriction>
</xs:simpleType>
<!-- VIDEO LAYOUT TYPE -->
<xs:simpleType name="video-layout-type">
<xs:restriction base="xs:string">
<xs:pattern value="single-view"/>
<xs:pattern value="dual-view"/>
Novo, et al. Expires October 29, 2011 [Page 90]
Internet-Draft Data Model Schema April 2011
<xs:pattern value="dual-view-crop"/>
<xs:pattern value="dual-view-2x1"/>
<xs:pattern value="dual-view-2x1-crop"/>
<xs:pattern value="quad-view"/>
<xs:pattern value="multiple-3x3"/>
<xs:pattern value="multiple-4x4"/>
<xs:pattern value="multiple-5x1"/>
<xs:pattern value="automatic"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- FLOOR INFORMATION TYPE -->
<xs:complexType name="floor-information-type">
<xs:sequence>
<xs:element name="conference-ID"
type="xs:unsignedLong" minOccurs="0"/>
<xs:element name="allow-floor-events"
type="xs:boolean" default="false" minOccurs="0"/>
<xs:element name="floor-request-handling"
type="floor-request-handling-type" minOccurs="0"/>
<xs:element name="conference-floor-policy"
type="conference-floor-policy" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- FLOOR REQUEST TYPE -->
<xs:simpleType name="floor-request-handling-type">
<xs:restriction base="xs:string">
<xs:pattern value="block"/>
<xs:pattern value="confirm"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- CONFERENCE FLOOR POLICY -->
<xs:complexType name="conference-floor-policy">
<xs:sequence>
<xs:element name="floor" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
Novo, et al. Expires October 29, 2011 [Page 91]
Internet-Draft Data Model Schema April 2011
<xs:element name="media-label"
type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="algorithm"
type="algorithm-type" minOccurs="0"/>
<xs:element name="max-floor-users"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="moderator-id"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- ALGORITHM TYPE -->
<xs:simpleType name="algorithm-type">
<xs:restriction base="xs:string">
<xs:pattern value="moderator-controlled"/>
<xs:pattern value="FCFS"/>
<xs:pattern value="random"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- USER ADMISSION POLICY TYPE -->
<xs:simpleType name="user-admission-policy-type">
<xs:restriction base="xs:string">
<xs:pattern value="closedAuthenticated"/>
<xs:pattern value="openAuthenticated"/>
<xs:pattern value="anonymous"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- JOIN HANDLING TYPE -->
<xs:simpleType name="join-handling-type">
<xs:restriction base="xs:string">
<xs:pattern value="block"/>
<xs:pattern value="confirm"/>
<xs:pattern value="allow"/>
Novo, et al. Expires October 29, 2011 [Page 92]
Internet-Draft Data Model Schema April 2011
<xs:pattern value="authenticate"/>
<xs:pattern value="directed-operator"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- DENY USER LIST TYPE -->
<xs:complexType name="deny-users-list-type">
<xs:sequence>
<xs:element name="target" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="uri" use="required" type="xs:anyURI"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- ALLOWED USERS LIST TYPE -->
<xs:complexType name="allowed-users-list-type">
<xs:sequence>
<xs:element name="target" type="target-type"
minOccurs="0" maxOccurs="unbounded">
</xs:element>
<xs:element name="persistent-list"
type="persistent-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- PERSISTENT LIST TYPE -->
<xs:complexType name="persistent-list-type">
<xs:sequence>
<xs:element name="user" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="email" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
Novo, et al. Expires October 29, 2011 [Page 93]
Internet-Draft Data Model Schema April 2011
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name"
use="required" type="xs:anyURI"/>
<xs:attribute name="nickname"
use="required" type="xs:string"/>
<xs:attribute name="id"
use="required" type="xs:string"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- TARGET TYPE -->
<xs:complexType name="target-type">
<xs:attribute name="uri" use="required"
type="xs:anyURI"/>
<xs:attribute name="method" use="required"
type="method-type"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- METHOD TYPE -->
<xs:simpleType name="method-type">
<xs:restriction base="xs:string">
<xs:pattern value="dial-in"/>
<xs:pattern value="dial-out"/>
<xs:pattern value="refer"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
<!-- ANONYMITY TYPE -->
<xs:simpleType name="provide-anonymity-type">
<xs:restriction base="xs:string">
<xs:pattern value="private"/>
<xs:pattern value="semi-private"/>
<xs:pattern value="hidden"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
Novo, et al. Expires October 29, 2011 [Page 94]
Internet-Draft Data Model Schema April 2011
<!-- MIXER TYPE -->
<xs:complexType name="mixer-type">
<xs:sequence>
<xs:element name="floor">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:boolean">
<xs:attribute name="id" type="xs:string"
use="required"/>
<xs:anyAttribute namespace="##any"
processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="controls" type="controls-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="mixer-name-type"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- MIXER NAME TYPE -->
<xs:simpleType name="mixer-name-type">
<xs:restriction base="xs:string">
<xs:pattern value="VideoIn"/>
<xs:pattern value="VideoOut"/>
<xs:pattern value="AudioOut"/>
<xs:pattern value="AudioIn"/>
<xs:pattern value=".+"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Novo, et al. Expires October 29, 2011 [Page 95]
Internet-Draft Data Model Schema April 2011
Authors' Addresses
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Oscar.Novo@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
David P. Morgan
Fidelity Investments
82 Devonshire St, MZ V3C
Boston, MA 02109-3614
USA
Email: Dave.Morgan@fmr.com
Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com
Novo, et al. Expires October 29, 2011 [Page 96]