path: root/doc/rfc/rfc6501.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L