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