[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-novo-xcon-common-data-model)
00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 32 RFC 6501
XCON O. Novo
Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson
Expires: August 25, 2008 D. Morgan
Fidelity Investments
R. Even
Polycom
February 22, 2008
Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-09.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing
(XCON). A conference information data model is designed to convey
information about the conference and about participation in the
Novo, et al. Expires August 25, 2008 [Page 1]
Internet-Draft Data Model Schema February 2008
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 6
3.3. The Conference Object Identifier . . . . . . . . . . . . . 7
3.3.1. Conference Object URI Definition . . . . . . . . . . . 9
3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 9
4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 10
4.1. <conference-info> . . . . . . . . . . . . . . . . . . . . 13
4.2. <conference-description> . . . . . . . . . . . . . . . . . 14
4.2.1. <language> . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. <display-text> . . . . . . . . . . . . . . . . . . . . 14
4.2.3. <subject> . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4. <free-text> . . . . . . . . . . . . . . . . . . . . . 14
4.2.5. <keywords> . . . . . . . . . . . . . . . . . . . . . . 14
4.2.6. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 15
4.2.7. <conference-time> . . . . . . . . . . . . . . . . . . 15
4.2.8. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 16
4.2.9. <service-uris> . . . . . . . . . . . . . . . . . . . . 16
4.2.10. <maximum-user-count> . . . . . . . . . . . . . . . . . 17
4.2.11. <available-media> . . . . . . . . . . . . . . . . . . 17
4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 19
4.4.1. <allow-conference-event-subscription> . . . . . . . . 19
4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 19
4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 20
4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 20
4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 20
4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 20
4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 20
4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 21
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 22
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 22
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 23
4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 24
4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 24
4.6.5.1. <display-text> . . . . . . . . . . . . . . . . . . 25
4.6.5.2. <associated-aors> . . . . . . . . . . . . . . . . 25
Novo, et al. Expires August 25, 2008 [Page 2]
Internet-Draft Data Model Schema February 2008
4.6.5.3. <provide-anonymity> . . . . . . . . . . . . . . . 25
4.6.5.4. <roles> . . . . . . . . . . . . . . . . . . . . . 26
4.6.5.5. <languages> . . . . . . . . . . . . . . . . . . . 26
4.6.5.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 26
4.6.5.7. <allow-refer-users-dynamically> . . . . . . . . . 26
4.6.5.8. <allow-invite-users-dynamically> . . . . . . . . . 26
4.6.5.9. <allow-remove-users-dynamically> . . . . . . . . . 27
4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 27
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 28
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 28
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 36
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 45
8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 46
8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 46
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 47
9.3. Conference Object Identifier Registration . . . . . . . . 47
9.4. Conference User Identifier Registration . . . . . . . . . 48
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Normative References . . . . . . . . . . . . . . . . . . . 49
11.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML
Syntax . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . . 72
Novo, et al. Expires August 25, 2008 [Page 3]
Internet-Draft Data Model Schema February 2008
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
[I-D.ietf-xcon-framework]. 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 follow 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 who, 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
[I-D.ietf-xcon-framework]. 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 August 25, 2008 [Page 4]
Internet-Draft Data Model Schema February 2008
...............................................................
. 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 August 25, 2008 [Page 5]
Internet-Draft Data Model Schema February 2008
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 [I-D.ietf-xcon-framework] (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 [I-D.ietf-xcon-framework].
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 [I-D.ietf-xcon-framework], 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-20001006]
document that MUST be well formed and SHOULD be valid. Conference
object documents MUST be based on XML 1.0 and SHOULD be encoded using
UTF-8.
3.2. Data Model Namespace
This specification defines a new namespace specification for
identifying the elements defined in the data model. This namespace
Novo, et al. Expires August 25, 2008 [Page 6]
Internet-Draft Data Model Schema February 2008
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 August 25, 2008 [Page 7]
Internet-Draft Data Model Schema February 2008
+--------------------------+
| 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 August 25, 2008 [Page 8]
Internet-Draft Data Model Schema February 2008
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 [ ":" port ]
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host, port, and unreserved are defined in RFC3986[RFC3986]
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).
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 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.
Novo, et al. Expires August 25, 2008 [Page 9]
Internet-Draft Data Model Schema February 2008
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>*
| |--<conference-time>*
| | |--<entry>*
| | | |--<base>*
| | | |--<mixing-start-offset>*
| | | |--<mixing-end-offset>*
| | | |--<can-join-after-offset>*
| | | |--<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>
Novo, et al. Expires August 25, 2008 [Page 10]
Internet-Draft Data Model Schema February 2008
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<codecs>*
| | | | |--<entry>*
| | | | |--<entry>*
| | | | ...
| | | |--<controls>*
| | | | |--<mute>*
| | | | |--<gain>*
| | | | ...
| | |--<entry>
| | | |--<display-text>
| | | |--<type>
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<codecs>*
| | | | |--<entry>*
| | | | |--<entry>*
| | | | ...
| | | |--<controls>*
| | | | |--<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>*
Novo, et al. Expires August 25, 2008 [Page 11]
Internet-Draft Data Model Schema February 2008
| | | |--<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>*
| | |--<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>*
| | | | | | ...
Novo, et al. Expires August 25, 2008 [Page 12]
Internet-Draft Data Model Schema February 2008
| | | | |--<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>
| ...
|--<sidebars-by-val>
| |--<entry>
| | |
| | ...
| |--<entry>
| | |
| ... ...
Figure 4: 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 tag
<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 applies 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.
Novo, et al. Expires August 25, 2008 [Page 13]
Internet-Draft Data Model Schema February 2008
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 extra
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>, <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.
4.2.1. <language>
The <language> element indicates the predominant language that is
expected to be employed within a conference. This element is not
enforcing 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].
Novo, et al. Expires August 25, 2008 [Page 14]
Internet-Draft Data Model Schema February 2008
4.2.6. <allow-sidebars>
The <allow-sidebars> element represents a boolean action. If set to
TRUE, the conference is allowed to create sidebar conferences.
4.2.7. <conference-time>
The <conference-time> element contains the information related to
conference time and duration of a conference. The <conference-time>
element contains one or more <entry> elements each defining the time
information specifying a single conference occurrence.
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
[RFC2445].
o <mixing-start-offset>: The <mixing-start-offset> child element
specifies when the conference media mixing starts before the
conference starts. The <mixing-start-offset> child element
expresses the offset as signed integers representing seconds
before/after the iCalendar DTSTART field [RFC2445]. 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". 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 that
specifies the time a conference media mixing stops after the
conference stops. The <mixing-end-offset> child element expresses
the offset as signed integers representing seconds before/after
the iCalendar DTEND field [RFC2445]. If the <mixing-end-offset>
element is not present, it indicates that the conference
occurrence is not bounded. The <mixing-end-offset> elements both
have 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-
Novo, et al. Expires August 25, 2008 [Page 15]
Internet-Draft Data Model Schema February 2008
offset>. If the conference policy was modified so that last
privileged user is now a normal conference participant, and the
conference requires a privileged 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. This is done by populating the <must-join-before-offset>
element expressing the offset as signed integers representing
seconds before/after DTSTART field.
o <request-user>: It is possible to define the time when users or
resources on the <allowed-users-list> are requested to join the
conference by using the <request-users> element. This element
expresses the offset as signed integers representing seconds
before/after DTSTART field.
o <notify-end-of-conference>: The <notify-end-of-conference> element
defines in seconds when the system has to 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. The <notify-end-of-conference> child element
expresses the offset as signed integers representing seconds after
DTSTART field.
o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
end-offset> refers to the possibility to extend the conference.
It has a boolean value.
4.2.8. <conf-uris>
The <conf-uris> contains the identifiers to be used in order to
access the conference by different signaling means. This document
describes a new element, <conference-password>. This element
contains the password 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]. Future extensions to this schema may define new values
and register them with IANA.
4.2.9. <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]. Future extensions to this schema may define new values
and register them with IANA.
Novo, et al. Expires August 25, 2008 [Page 16]
Internet-Draft Data Model Schema February 2008
4.2.10. <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.11. <available-media>
The <available-media> has 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. The <available-
media> element contains a sequence of <entry> child elements. 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 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.
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 identifies a codec. The list of possible codecs
accepted as a 'name' attribute is defined by the IANA registry for
RTP Payload Types. The possible values of the attribute 'name'
are the values of the 'subtype' column of the RTP Payload Format
media types per [RFC4855] defined in IANA [IANA]. The 'policy'
attribute contains the policy for that codec (allowed, or
disallowed).
o The <controls> element contains the basic audio and video global
control elements for a conference. It is expected that for the
majority of the basic conferences, these controls are sufficient.
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
Novo, et al. Expires August 25, 2008 [Page 17]
Internet-Draft Data Model Schema February 2008
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 associated media. 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
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
Novo, et al. Expires August 25, 2008 [Page 18]
Internet-Draft Data Model Schema February 2008
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 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.
4.4. <conference-state>
The <conference-state> is introduced in RFC4575 [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 RFC4575 'SIP Event
Package for Conference State' [RFC4575]. If set to FALSE, the
subscription to conference state events would 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.
Novo, et al. Expires August 25, 2008 [Page 19]
Internet-Draft Data Model Schema February 2008
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. Other elements from different namespaces MAY
be present for the purposes of extensibility. 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 created within the conferencing system, the
'conference-ID' can be represented by the unique conference object
Identifier (XCON-URI). When BFCP serves as the floor control
protocol, the <conference-ID> is a 32-bit BFCP conference identifier
defined in [RFC4582] section 5.1 and there is a 1:1 mapping to the
XCON-URI.
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.
There are two methods which a conference participant subscribes
himself to a floor control event. 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
Novo, et al. Expires August 25, 2008 [Page 20]
Internet-Draft Data Model Schema February 2008
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 or floors 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
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. 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 5.1. Note that [RFC4582] refers to the moderator role as
a 'floor chair'.
Novo, et al. Expires August 25, 2008 [Page 21]
Internet-Draft Data Model Schema February 2008
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 notifications mechanism. 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.
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 allowed into the conference.
The list of possible values are:
o "closedAuthenticated": A 'closedAuthenticated' policy requires
each conference participant to be in the allowed users list
(listed under the <allowed-users-list> XML 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
Novo, et al. Expires August 25, 2008 [Page 22]
Internet-Draft Data Model Schema February 2008
user is placed on a pending list as indicated earlier.
o "openAuthenticated": An 'openAuthenticated' policy requires each
conferencing participant to be sufficiently authenticated (as
before) but does not restrict which participants can join the
conference. Typically this implies that anyone capable of
authenticating with the conferencing system may join the
conference.
o "anonymous": An 'anonymous' policy allows any join requests in and
is the least restrictive policy.
4.6.3. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs,
roles, or domains (*@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.
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:
Novo, et al. Expires August 25, 2008 [Page 23]
Internet-Draft Data Model Schema February 2008
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,
roles, or domains (*@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 a conferencing system. The URI
format of this identifier is as follow:
XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*(unreserved)
[unreserved is defined in RFC3986]
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 6 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 that
can be used.
Novo, et al. Expires August 25, 2008 [Page 24]
Internet-Draft Data Model Schema February 2008
+----------------+
| 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 6: 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.
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 provides anonymity 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 information about the user is still stored in
the data model. This can be achieved by using the <provide-
anonymity> element. This element has three values: 'private', 'semi-
Novo, et al. Expires August 25, 2008 [Page 25]
Internet-Draft Data Model Schema February 2008
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 with equal or
lesser permissions in the conference. '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 of the
following values: "administrator", "moderator", "user",
"participant", "observer", and "none". 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
action. If set to TRUE, a participant is allowed to instruct the
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 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 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
Novo, et al. Expires August 25, 2008 [Page 26]
Internet-Draft Data Model Schema February 2008
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 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 defined in [RFC4575]. It can provide
the desired level of detail about the user's devices and their
signaling sessions taking part in the conference. The <endpoint>
element in this document does not defined the 'state' attribute
defined in [RFC4575] for the same element since the 'state' attribute
only applies to notification mechanisms.
The <endpoint> element has the following child elements: <display-
text>, <referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>, <floor>,and
<call-info>. All the <endpoint> child elements are defined in
[RFC4575] with the exception of the <floor> element.
The <floor> element describes a floor that joins this 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 or floors 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.
Besides the <floor> element, the <endpoint>/<media> element has two
other child elements defined 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
Novo, et al. Expires August 25, 2008 [Page 27]
Internet-Draft Data Model Schema February 2008
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. More values can be defined
in the future. The <to-mixer> and <from-mixer> elements have the
<controls> child element:
* Controls that apply to a specific user would appear under the
<controls> element.
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.
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
[I-D.ietf-xcon-framework], 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.
This specification defines some document fragments in RELAX NG format
[RELAX].
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace local = ""
default namespace ns1 ="urn:ietf:params:xml:ns:xcon-conference-info"
namespace ns2 = "urn:ietf:params:xml:ns:conference-info"
Novo, et al. Expires August 25, 2008 [Page 28]
Internet-Draft Data Model Schema February 2008
start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
attribute entity { text },
anyAttribute,
conference-description-type,
element language { xsd:language }?,
element host-info { conference-info-urn* }?,
element conference-state { conference-state-type }?,
element floor-information { floor-information-type }?,
element users { users-type },
element sidebars-by-ref { sidebars-by-ref-type }?,
element sidebars-by-val { sidebars-by-val-type }?,
anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
element conference-description {
attribute lang { xsd:language }?,
anyAttribute,
element display-text { text }?,
element subject { text }?,
element free-text { text }?,
element keywords {
list { xsd:string* }
}?,
element allow-sidebars { xsd:boolean }?,
element conference-time { conferencetime-type }?,
element conf-uris {
(element conference-password { text }?,
conference-info-urn)*
}?,
element service-uris { conference-info-urn* }?,
element maximum-user-count { xsd:int }?,
element available-media { conference-media-type }?,
anyElement*
}
# CONFERENCE TIME
conferencetime-type =
anyAttribute,
element entry {
element base { text }?,
element mixing-start-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type },
anyAttribute
}?,
element mixing-end-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
Novo, et al. Expires August 25, 2008 [Page 29]
Internet-Draft Data Model Schema February 2008
attribute required-participant { single-role-type },
anyAttribute
}?,
element can-join-after-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element must-join-before-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element notify-end-of-conference { xsd:int }?,
element allowed-extend-mixing-end-offset { xsd:boolean }?,
anyElement*
}*,
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 mixing-mode { mix-mode-type }?,
element codecs { codecs-type }?,
element controls { control-type }?,
anyElement*
# MIX MODE TYPE
mix-mode-type =
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "automatic"
| text
# CODECS TYPE
codecs-type =
attribute decision { decision-type },
anyAttribute,
element codec { codec-type }*,
anyElement*
# CODEC TYPE
codec-type =
attribute name { text },
attribute policy { policy-type },
anyAttribute
# DECISION TYPE
Novo, et al. Expires August 25, 2008 [Page 30]
Internet-Draft Data Model Schema February 2008
decision-type =
xsd:string "automatic" | xsd:string "moderator-controlled" | text
# POLICY TYPE
policy-type = xsd:string "allowed" | xsd:string "disallowed" | text
# CONTROL TYPE
control-type =
anyAttribute,
(element mute { xsd:boolean },
element pause-video { xsd:boolean },
element gain {
xsd:int { minInclusive = "-127" maxInclusive = "127" }
},
element video-layout {
xsd:string "single-view"
| xsd:string "dual-view"
| xsd:string "dual-view-crop"
| xsd:string "dual-view-2x1"
| xsd:string "dual-view-2x1-crop"
| xsd:string "quad-view"
| xsd:string "multiple-3x3"
| xsd:string "multiple-4x4"
| xsd:string "multiple-5x1"
| xsd:string "automatic"
| text
},
anyElement*)*
# CONFERENCE STATE TYPE
conference-state-type =
anyAttribute,
element allow-conference-event-subscription { xsd:boolean }?,
element user-count { xsd:unsignedInt }?,
element active { xsd:boolean }?,
element locked { xsd:boolean }?,
anyElement*
# FLOOR INFORMATION TYPE
floor-information-type =
anyAttribute,
(element conference-ID { xsd:unsignedLong },
element allow-floor-events { xsd:boolean },
element floor-request-handling { floor-request-type },
element conference-floor-policy { Conference-floor-policy },
anyElement*)*
# FLOOR REQUEST TYPE
floor-request-type =xsd:string "block" | xsd:string "confirm" | text
# CONFERENCE FLOOR POLICY
Conference-floor-policy =
anyAttribute,
element floor {
Novo, et al. Expires August 25, 2008 [Page 31]
Internet-Draft Data Model Schema February 2008
attribute id { text },
anyAttribute,
element media-label { xsd:nonNegativeInteger }+,
(element algorithm {
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "random"
| text
},
element max-floor-users { xsd:nonNegativeInteger },
element moderator-id { text },
anyElement*)*
}+
# USERS TYPE
users-type =
anyAttribute,
element join-handling { join-handling-type }?,
element user-admission-policy { user-admission-policy-type }?,
element allowed-users-list { UserList }?,
element deny-users-list { deny-user-list }?,
element user { user-type }*,
anyElement*
# USERS ADMISSION POLICY
user-admission-policy-type =
xsd:string "closedAuthenticated"
| xsd:string "openAuthenticated"
| xsd:string "anonymous"
| text
# JOIN HANDLING TYPE
join-handling-type =
xsd:string "block"
| xsd:string "confirm"
| xsd:string "allow"
| xsd:string "authenticate"
| xsd:string "directed-operator"
| text
# DENYUSERLIST
deny-user-list =
anyAttribute,
element target {
attribute uri { xsd:anyURI },
anyAttribute
}*,
anyElement*
# USERLIST
UserList =
anyAttribute,
element target { target-type }*,
Novo, et al. Expires August 25, 2008 [Page 32]
Internet-Draft Data Model Schema February 2008
anyElement*,
element persistent-list {
element user {
attribute name { text },
attribute nickname { text },
attribute id { text },
anyAttribute,
element e-mail { text }*
}*,
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"
| text
# USER TYPE
user-type =
attribute entity { xsd:anyURI },
anyAttribute,
element display-text { text }?,
element associated-aors { conference-info-urn* }?,
element provide-anonymity { "private" | "semi-private" |
"hidden" | text }?,
element roles { single-role-type }?,
element languages {
list { xsd:language }
}?,
element cascaded-focus { xsd:anyURI }?,
element allow-refer-users-dynamically { xsd:boolean }?,
element allow-invite-users-dynamically { xsd:boolean }?,
element allow-remove-users-dynamically { xsd:boolean }?,
element endpoint { endpoint-type }*,
anyElement*
# ENDPOINT TYPE
endpoint-type =
attribute entity { text },
anyAttribute,
element display-text { text }?,
element referred { conference-info-urn* }?,
element status { endpoint-status-type }?,
element joining-method { joining-type }?,
Novo, et al. Expires August 25, 2008 [Page 33]
Internet-Draft Data Model Schema February 2008
element joining-info { conference-info-urn* }?,
element disconnection-method { disconnection-type }?,
element disconnection-info { conference-info-urn* }?,
element media { media-type }*,
element floor {
attribute id { text },
anyAttribute,
xsd:boolean
}*,
element call-info { conference-info-urn* }?,
anyElement*
# MEDIA TYPE
media-type =
attribute id { xsd:int },
anyAttribute,
element display-text { text }?,
element type { text }?,
element label { text }?,
element src-id { text }?,
element status { media-status-type }?,
element to-mixer { mixer-type }?,
element from-mixer { mixer-type }?,
anyElement*
# MIXER TYPE
mixer-type =
anyAttribute,
element controls { control-type }?,
anyElement*
# SIDEBARS-BY-REF TYPE
sidebars-by-ref-type =
anyAttribute,
element entry { conference-info-urn* }*,
anyElement*
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
anyAttribute,
element entry { conference-type }*,
anyElement*
# SINGLE ROLE TYPE
single-role-type =
xsd:string "administrator"
| xsd:string "moderator"
| xsd:string "user"
| xsd:string "participant"
| xsd:string "observer"
| xsd:string "none"
| text
# *********************************
Novo, et al. Expires August 25, 2008 [Page 34]
Internet-Draft Data Model Schema February 2008
# EXTENSIBILITY OF THE SCHEMA
# *********************************
# EXTENSIBILITY ELEMENTS
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
# EXTENSIBILITY ATTRIBUTES
anyAttribute =
attribute * - (entity
| lang
| required-participant
| label
| decision
| name
| policy
| uri
| method
| id
| local:*
| ns1:*) { text }*
# *************************************************************
# TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
# - RFC4575 -
# *************************************************************
# WILDCARD FOR EVENT-PACKAGE NAMESPACE
conference-info-urn =
element * - (ns2:* | local:*) {
mixed {
(attribute * { text }
| conference-info-urn)*
}
}
# DEFINITION OF ENDPOINT STATUS TYPE
media-status-type =
"recvonly" | "sendonly" | "sendrecv" | "inactive" | text
# ENDPOINT STATUS TYPE
endpoint-status-type =
"pending"
| "dialing-out"
| "dialing-in"
| "alerting"
| "on-hold"
| "connected"
Novo, et al. Expires August 25, 2008 [Page 35]
Internet-Draft Data Model Schema February 2008
| "muted-via-focus"
| "disconnecting"
| "disconnected"
| text
# JOINING TYPE
joining-type = "dialed-in" | "dialed-out" | "focus-owner" | text
# DISCONNECTION TYPE
disconnection-type = "departed" | "booted" | "failed" | "busy" | text
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 extension elements from
the same namespace in future. Other instances are free to define
extension elements under any namespace other than
urn:ietf:params:xml:ns:xcon-conference-info.
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:xcon-conference-info"
entity="conference123@example.com">
<!--
CONFERENCE DESCRIPTION
-->
<conference-description lang="en-us">
<language>En-us</language>
<display-text>Discussion of Formula-1 racing</display-text>
<subject>Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
Novo, et al. Expires August 25, 2008 [Page 36]
Internet-Draft Data Model Schema February 2008
<keywords>Formula-1, cars</keywords>
<allow-sidebars>true</allow-sidebars>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<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</base>
<mixing-start-offset required-participant="moderator"
> 2007-10-17T14:29:00Z</mixing-start-offset>
<mixing-end-offset required-participant="participant"
> 2007-10-17T16:31:00Z</mixing-end-offset>
<must-join-before-offset
> 2007-10-17T15:30:00Z</must-join-before-offset>
</entry>
</conference-time>
<!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<conf-uris>
<entry>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
<conference-password>5678</conference-password>
</entry>
<entry>
<uri>http://www.example.com/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris>
<entry>
<uri>http://www.example.com/formula1/</uri>
Novo, et al. Expires August 25, 2008 [Page 37]
Internet-Draft Data Model Schema February 2008
<purpose>web-page</purpose>
</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>
<mixing-mode>automatic</mixing-mode>
<codecs decision="automatic">
<codec name="PCMU" policy="allowed"/>
</codecs>
<controls>
<mute>true</mute>
<gain>50</gain>
</controls>
</entry>
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<mixing-mode>automatic</mixing-mode>
<codecs decision="automatic">
<codec name="H.263" policy="allowed"/>
</codecs>
<controls>
<video-layout>single-view</video-layout>
</controls>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<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>
Novo, et al. Expires August 25, 2008 [Page 38]
Internet-Draft Data Model Schema February 2008
<entry>
<uri>sip:carol@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<allow-conference-event-subscription
>true</allow-conference-event-subscription>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
FLOOR INFORMATION
-->
<floor-information>
<conference-ID>567</conference-ID>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>confirm</floor-request-handling>
<conference-floor-policy>
<floor id="345">
<media-label>10234</media-label>
<media-label>10235</media-label>
<algorithm>moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-id>234</moderator-id>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users>
<join-handling>allow</join-handling>
<user-admission-policy
>openAuthenticated</user-admission-policy>
<!--
ALLOWED USERS LIST
-->
<allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/>
</allowed-users-list>
Novo, et al. Expires August 25, 2008 [Page 39]
Internet-Draft Data Model Schema February 2008
<!--
DENY USERS LIST
-->
<deny-users-list>
<target uri="sip:charlie@example.com"/>
</deny-users-list>
<!--
USER BOB
-->
<user entity="bob534">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<provide-anonymity>semi-private</provide-anonymity>
<roles>
<entry>participant</entry>
</roles>
<languages>en-us</languages>
<allow-refer-users-dynamically
>false</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>false</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>false</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com">
<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>
Novo, et al. Expires August 25, 2008 [Page 40]
Internet-Draft Data Model Schema February 2008
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<to-mixer name="VideoIn">
<controls>
<video-layout
>single-view</video-layout>
</controls>
</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>
</user>
<!--
USER ALICE
-->
<user entity="alice334">
<display-text>Alice Kay</display-text>
<associated-aors>
<entry>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<provide-anonymity>private</provide-anonymity>
<roles>
<entry>moderator</entry>
</roles>
<languages>en-us</languages>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
Novo, et al. Expires August 25, 2008 [Page 41]
Internet-Draft Data Model Schema February 2008
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
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>
<to-mixer name="VideoIn">
<controls>
<video-layout
>single-view</video-layout>
</controls>
</to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<to-mixer name="VideoIn">
<controls>
<gain>50</gain>
</controls>
</to-mixer>
<from-mixer name="VideoOut">
<controls>
<gain>50</gain>
</controls>
</from-mixer>
</media>
<floor id="345">true</floor>
Novo, et al. Expires August 25, 2008 [Page 42]
Internet-Draft Data Model Schema February 2008
<!--
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>
</endpoint>
</user>
<!--
USER CAROL
-->
<user entity="carol233">
<display-text>Carol More</display-text>
<associated-aors>
<entry>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<provide-anonymity>private</provide-anonymity>
<roles>
<entry>administrator</entry>
</roles>
<languages>en-us</languages>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
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>
Novo, et al. Expires August 25, 2008 [Page 43]
Internet-Draft Data Model Schema February 2008
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<to-mixer name="VideoIn">
<controls>
<video-layout
>single-view</video-layout>
</controls>
</to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<to-mixer name="VideoIn">
<controls>
<gain>50</gain>
</controls>
</to-mixer>
<from-mixer name="VideoOut">
<controls>
<gain>50</gain>
</controls>
</from-mixer>
</media>
<floor id="345">false</floor>
<!--
CALL INFO
-->
<call-info>
<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>
</endpoint>
</user>
</users>
Novo, et al. Expires August 25, 2008 [Page 44]
Internet-Draft Data Model Schema February 2008
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref>
<entry>
<uri>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="bob534"/>
<user entity="carol233"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash
characters mark where line folding has taken place. These
backslashes would not appear in the actual XML data model.
8. Security Considerations
There are numerous security considerations for this document. This
section considers them.
8.1. Authentication
Different conferencing protocols will support different types of
authentication mechanisms. Since a variety of signaling protocols
are possible, a variety of authentication mechanism may need to be
mapped from the different protocols.
Futhermore, users may use different namespaces to access to a
conference. So a mapping database has to specify the acceptable
range of namespace for a user. Doing so, a users will not access the
same conference twice using a different namespace.
The security considerations for authentication (section 10.1)
described in the centralized conferencing framework [RFC4575] applies
to this document. The focus must ensure that only authorized
Novo, et al. Expires August 25, 2008 [Page 45]
Internet-Draft Data Model Schema February 2008
entities are able to manipulate the data to access the information.
8.2. Confidentiality
Participants of a conference may not want to reveal some private
information to other users. The Conference Information Data Model
contains sensitive data which should not be analyzed or given to
anyone. Confidentiality is provided through encryption. Strong end-
to-end authentication and encryption can be done using public keys,
and end-to-end encryption can be done using private keys. It is
RECOMMENDED that the protocols that manipulated the conference
information data model use a strong encryption for conference
information protection.
8.3. Integrity
A conferencing system may maintain a mapping database between the
conference object identifiers and the identifiers associated with
each of the complementary centralized conferencing protocols, as well
as, a mapping between the conference user identifiers and the
identifiers associated with each user in a conference. This mapping
database contains sensitive data. It is RECOMMENDED that the mapping
database has integrity when it is established, the integrity has to
be protected, and the database has to be maintained to ensure changes
in namespaces are accurately reflected.
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:ns: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
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
and its last line is
Novo, et al. Expires August 25, 2008 [Page 46]
Internet-Draft Data Model Schema February 2008
disconnection-type = "departed" | "booted" | "failed" | "busy"
9.2. XML Namespace Registration
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 register.
XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] [RFC xxxx]
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
Novo, et al. Expires August 25, 2008 [Page 47]
Internet-Draft Data Model Schema February 2008
host, port, and unreserved are defined in RFC3986[RFC3986]
[Note to the RFC Editor: replace xxxx with the number this RFC gets
assigned.]
Subject: Request for XCON-URI Registration
Person & email address to contact for further information:
Oscar Novo <oscar novo_at_ericsson.com>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the Conference
9.4. Conference User Identifier Registration
The IANA is requested to register the following URI scheme
under the Permanent URI Schemes register.
XCON-USERID = "xcon-userid" ":" conf-user-id [ RFC xxxx ]
conf-user-id = 1*(unreserved)
unreserved is defined in RFC3986[RFC3986]
[Note to the RFC Editor: replace xxxx with the number this RFC gets
assigned.]
Subject: Request for XCON-USERID Registration
Person & email address to contact for further information:
Oscar Novo <oscar novo_at_ericsson.com>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the User in the conference
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
Novo, et al. Expires August 25, 2008 [Page 48]
Internet-Draft Data Model Schema February 2008
would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki
Niemi, Jari Urpilainen, Rohan Mahy, Jonathan Lennox, 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.
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 2445, November 1998.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
11.2. Informative References
[I-D.ietf-xcon-framework]
Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-10
(work in progress), November 2007.
[IANA] "IANA registry for RTP Payload Types"
"http://www.iana.org/assignments/rtp-parameters".
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
Novo, et al. Expires August 25, 2008 [Page 49]
Internet-Draft Data Model Schema February 2008
RFC 3986, January 2005.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 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.
[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.
[W3C.REC-xml-20001006]
Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<grammar ns="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
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">
<attribute name="entity">
<text/>
</attribute>
<ref name="anyAttribute"/>
<ref name="conference-description-type"/>
<optional>
Novo, et al. Expires August 25, 2008 [Page 50]
Internet-Draft Data Model Schema February 2008
<element name="language">
<data type="language"/>
</element>
</optional>
<optional>
<element name="host-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="conference-state">
<ref name="conference-state-type"/>
</element>
</optional>
<optional>
<element name="floor-information">
<ref name="floor-information-type"/>
</element>
</optional>
<element name="users">
<ref name="users-type"/>
</element>
<optional>
<element name="sidebars-by-ref">
<ref name="sidebars-by-ref-type"/>
</element>
</optional>
<optional>
<element name="sidebars-by-val">
<ref name="sidebars-by-val-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<define name="conference-description-type">
<element name="conference-description">
<optional>
<attribute name="lang">
<data type="language"/>
</attribute>
</optional>
Novo, et al. Expires August 25, 2008 [Page 51]
Internet-Draft Data Model Schema February 2008
<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="allow-sidebars">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="conference-time">
<ref name="conferencetime-type"/>
</element>
</optional>
<optional>
<element name="conf-uris">
<zeroOrMore>
<optional>
<element name="conference-password">
<text/>
</element>
</optional>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
Novo, et al. Expires August 25, 2008 [Page 52]
Internet-Draft Data Model Schema February 2008
<element name="service-uris">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</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>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element>
</define>
<!--
CONFERENCE TIME
-->
<define name="conferencetime-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<optional>
<element name="base">
<text/>
</element>
</optional>
<optional>
<element name="mixing-start-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</optional>
<optional>
<element name="mixing-end-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
Novo, et al. Expires August 25, 2008 [Page 53]
Internet-Draft Data Model Schema February 2008
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</optional>
<optional>
<element name="can-join-after-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
</element>
</optional>
<optional>
<element name="must-join-before-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
</element>
</optional>
<optional>
<element name="notify-end-of-conference">
<data type="int"/>
</element>
</optional>
<optional>
<element name="allowed-extend-mixing-end-offset">
<data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONFERENCE MEDIA TYPE
-->
<define name="conference-media-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
Novo, et al. Expires August 25, 2008 [Page 54]
Internet-Draft Data Model Schema February 2008
<ref name="conference-medium-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONFERENCE MEDIUM TYPE
-->
<define name="conference-medium-type">
<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>
<element name="mixing-mode">
<ref name="mix-mode-type"/>
</element>
</optional>
<optional>
<element name="codecs">
<ref name="codecs-type"/>
</element>
</optional>
<optional>
<element name="controls">
<ref name="control-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
Novo, et al. Expires August 25, 2008 [Page 55]
Internet-Draft Data Model Schema February 2008
</define>
<!--
MIX MODE TYPE
-->
<define name="mix-mode-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">automatic</value>
<text/>
</choice>
</define>
<!--
CODECS TYPE
-->
<define name="codecs-type">
<attribute name="decision">
<ref name="decision-type"/>
</attribute>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="codec">
<ref name="codec-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CODEC TYPE
-->
<define name="codec-type">
<attribute name="name">
<text/>
</attribute>
<attribute name="policy">
<ref name="policy-type"/>
</attribute>
<ref name="anyAttribute"/>
</define>
<!--
DECISION TYPE
-->
<define name="decision-type">
<choice>
<value type="string">automatic</value>
<value type="string">moderator-controlled</value>
Novo, et al. Expires August 25, 2008 [Page 56]
Internet-Draft Data Model Schema February 2008
<text/>
</choice>
</define>
<!--
POLICY TYPE
-->
<define name="policy-type">
<choice>
<value type="string">allowed</value>
<value type="string">disallowed</value>
<text/>
</choice>
</define>
<!--
CONTROL TYPE
-->
<define name="control-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="mute">
<data type="boolean"/>
</element>
<element name="pause-video">
<data type="boolean"/>
</element>
<element name="gain">
<data type="int">
<param name="minInclusive">-127</param>
<param name="maxInclusive">127</param>
</data>
</element>
<element name="video-layout">
<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>
<value type="string">multiple-4x4</value>
<value type="string">multiple-5x1</value>
<value type="string">automatic</value>
<text/>
</choice>
</element>
<zeroOrMore>
<ref name="anyElement"/>
Novo, et al. Expires August 25, 2008 [Page 57]
Internet-Draft Data Model Schema February 2008
</zeroOrMore>
</zeroOrMore>
</define>
<!--
CONFERENCE STATE TYPE
-->
<define name="conference-state-type">
<ref name="anyAttribute"/>
<optional>
<element name="allow-conference-event-subscription">
<data type="boolean"/>
</element>
</optional>
<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>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
FLOOR INFORMATION TYPE
-->
<define name="floor-information-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="conference-ID">
<data type="unsignedLong"/>
</element>
<element name="allow-floor-events">
<data type="boolean"/>
</element>
<element name="floor-request-handling">
<ref name="floor-request-type"/>
</element>
<element name="conference-floor-policy">
Novo, et al. Expires August 25, 2008 [Page 58]
Internet-Draft Data Model Schema February 2008
<ref name="Conference-floor-policy"/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore>
</define>
<!--
FLOOR REQUEST TYPE
-->
<define name="floor-request-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
<text/>
</choice>
</define>
<!--
CONFERENCE FLOOR POLICY
-->
<define name="Conference-floor-policy">
<ref name="anyAttribute"/>
<oneOrMore>
<element name="floor">
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<oneOrMore>
<element name="media-label">
<data type="nonNegativeInteger"/>
</element>
</oneOrMore>
<zeroOrMore>
<element name="algorithm">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">random</value>
<text/>
</choice>
</element>
<element name="max-floor-users">
<data type="nonNegativeInteger"/>
</element>
<element name="moderator-id">
<text/>
</element>
Novo, et al. Expires August 25, 2008 [Page 59]
Internet-Draft Data Model Schema February 2008
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore>
</element>
</oneOrMore>
</define>
<!--
USERS TYPE
-->
<define name="users-type">
<ref name="anyAttribute"/>
<optional>
<element name="join-handling">
<ref name="join-handling-type"/>
</element>
</optional>
<optional>
<element name="user-admission-policy">
<ref name="user-admission-policy-type"/>
</element>
</optional>
<optional>
<element name="allowed-users-list">
<ref name="UserList"/>
</element>
</optional>
<optional>
<element name="deny-users-list">
<ref name="deny-user-list"/>
</element>
</optional>
<zeroOrMore>
<element name="user">
<ref name="user-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
USERS ADMISSION POLICY
-->
<define name="user-admission-policy-type">
<choice>
<value type="string">closedAuthenticated</value>
<value type="string">openAuthenticated</value>
Novo, et al. Expires August 25, 2008 [Page 60]
Internet-Draft Data Model Schema February 2008
<value type="string">anonymous</value>
<text/>
</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>
<text/>
</choice>
</define>
<!--
DENYUSERLIST
-->
<define name="deny-user-list">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="target">
<attribute name="uri">
<data type="anyURI"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
USERLIST
-->
<define name="UserList">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="target">
<ref name="target-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
Novo, et al. Expires August 25, 2008 [Page 61]
Internet-Draft Data Model Schema February 2008
<optional>
<element name="persistent-list">
<zeroOrMore>
<element name="user">
<attribute name="name">
<text/>
</attribute>
<attribute name="nickname">
<text/>
</attribute>
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="e-mail">
<text/>
</element>
</zeroOrMore>
</element>
</zeroOrMore>
<ref name="anyElement"/>
</element>
</optional>
</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>
<text/>
</choice>
</define>
Novo, et al. Expires August 25, 2008 [Page 62]
Internet-Draft Data Model Schema February 2008
<!--
USER TYPE
-->
<define name="user-type">
<attribute name="entity">
<data type="anyURI"/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="associated-aors">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="provide-anonymity">
<choice>
<value>private</value>
<value>semi-private</value>
<value>hidden</value>
<text/>
</choice>
</element>
</optional>
<optional>
<element name="roles">
<ref name="single-role-type"/>
</element>
</optional>
<optional>
<element name="languages">
<list>
<data type="language"/>
</list>
</element>
</optional>
<optional>
<element name="cascaded-focus">
<data type="anyURI"/>
</element>
</optional>
<optional>
Novo, et al. Expires August 25, 2008 [Page 63]
Internet-Draft Data Model Schema February 2008
<element name="allow-refer-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="allow-invite-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="allow-remove-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<element name="endpoint">
<ref name="endpoint-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
ENDPOINT TYPE
-->
<define name="endpoint-type">
<attribute name="entity">
<text/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="referred">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="status">
<ref name="endpoint-status-type"/>
</element>
</optional>
Novo, et al. Expires August 25, 2008 [Page 64]
Internet-Draft Data Model Schema February 2008
<optional>
<element name="joining-method">
<ref name="joining-type"/>
</element>
</optional>
<optional>
<element name="joining-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="disconnection-method">
<ref name="disconnection-type"/>
</element>
</optional>
<optional>
<element name="disconnection-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<zeroOrMore>
<element name="media">
<ref name="media-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="floor">
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<data type="boolean"/>
</element>
</zeroOrMore>
<optional>
<element name="call-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
Novo, et al. Expires August 25, 2008 [Page 65]
Internet-Draft Data Model Schema February 2008
</define>
<!--
MEDIA TYPE
-->
<define name="media-type">
<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="to-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<optional>
<element name="from-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
Novo, et al. Expires August 25, 2008 [Page 66]
Internet-Draft Data Model Schema February 2008
<!--
MIXER TYPE
-->
<define name="mixer-type">
<ref name="anyAttribute"/>
<optional>
<element name="controls">
<ref name="control-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
SIDEBARS-BY-REF TYPE
-->
<define name="sidebars-by-ref-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
SIDEBARS-BY-VAL TYPE
-->
<define name="sidebars-by-val-type">
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="entry">
<ref name="conference-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
SINGLE ROLE TYPE
-->
<define name="single-role-type">
Novo, et al. Expires August 25, 2008 [Page 67]
Internet-Draft Data Model Schema February 2008
<choice>
<value type="string">administrator</value>
<value type="string">moderator</value>
<value type="string">user</value>
<value type="string">participant</value>
<value type="string">observer</value>
<value type="string">none</value>
<text/>
</choice>
</define>
<!--
*********************************
EXTENSIBILITY OF THE SCHEMA
*********************************
-->
<!--
EXTENSIBILITY ELEMENTS
-->
<define name="anyElement">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement"/>
</choice>
</zeroOrMore>
</element>
</define>
<!--
EXTENSIBILITY ATTRIBUTES
-->
<define name="anyAttribute">
<zeroOrMore>
<attribute>
<anyName>
<except>
<name ns="">entity</name>
<name ns="">lang</name>
<name ns="">required-participant</name>
<name ns="">label</name>
<name ns="">decision</name>
<name ns="">name</name>
<name ns="">policy</name>
<name ns="">uri</name>
Novo, et al. Expires August 25, 2008 [Page 68]
Internet-Draft Data Model Schema February 2008
<name ns="">method</name>
<name ns="">id</name>
<nsName ns=""/>
<nsName ns="urn:ietf:params:xml:ns:xcon-conference-info"/>
</except>
</anyName>
<text/>
</attribute>
</zeroOrMore>
</define>
<!--
*************************************************************
TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
- RFC4575 -
*************************************************************
-->
<!--
WILDCARD FOR EVENT-PACKAGE NAMESPACE
-->
<define name="conference-info-urn">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:conference-info"/>
<nsName ns=""/>
</except>
</anyName>
<mixed>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="conference-info-urn"/>
</choice>
</zeroOrMore>
</mixed>
</element>
</define>
<!--
DEFINITION OF ENDPOINT STATUS TYPE
-->
<define name="media-status-type">
<choice>
<value>recvonly</value>
<value>sendonly</value>
<value>sendrecv</value>
Novo, et al. Expires August 25, 2008 [Page 69]
Internet-Draft Data Model Schema February 2008
<value>inactive</value>
<text/>
</choice>
</define>
<!--
ENDPOINT STATUS TYPE
-->
<define name="endpoint-status-type">
<choice>
<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>
<text/>
</choice>
</define>
<!--
JOINING TYPE
-->
<define name="joining-type">
<choice>
<value>dialed-in</value>
<value>dialed-out</value>
<value>focus-owner</value>
<text/>
</choice>
</define>
<!--
DISCONNECTION TYPE
-->
<define name="disconnection-type">
<choice>
<value>departed</value>
<value>booted</value>
<value>failed</value>
<value>busy</value>
<text/>
</choice>
</define>
</grammar>
Novo, et al. Expires August 25, 2008 [Page 70]
Internet-Draft Data Model Schema February 2008
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
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Novo, et al. Expires August 25, 2008 [Page 71]
Internet-Draft Data Model Schema February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Novo, et al. Expires August 25, 2008 [Page 72]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/