From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc6501.txt | 5267 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 5267 insertions(+)
 create mode 100644 doc/rfc/rfc6501.txt

(limited to 'doc/rfc/rfc6501.txt')

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