RFC 6501
Conference Information Data Model for Centralized Conferencing (XCON)
RFC 6501: Conference Information Data Model for Centralized Conferencing (XCON) 💖
okay bestie, let's get into it 🎀 this RFC was written by Novo, Camarillo, Morgan, and Urpalainen, from Ericsson, Fidelity Investments, and Nokia 🫶 It came out in March 2012 as a Standards Track document, and its ISSN is 2070-1721. Its header doesn't list any document it obsoletes or updates. It's all about the XML data model for conference objects in centralized conferencing (XCON) ✨
Abstract ✨
okay so [RFC5239] describes centralized conferencing (XCON) as a bunch of participants gathered around a central focus 🌸 The state of a conference lives in a conference object 🧚 This document defines an XML-based conference information data model that conference objects use 💅 That model is built to carry info about the conference itself and about who is taking part in it 💜 It's an extension of the data format from the conference state event package for the Session Initiation Protocol (SIP) 🦋 ngl that's the whole point, it's the SIP package but glow-up edition 🔥
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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check out Section 2 of RFC 5741 🌈
For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6501 🦋
Copyright Notice ✨
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the day it was published 🍓 Read these carefully, bestie, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License explains 🌸
This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🌈 The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈 So, without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside the IETF Standards Process 💀 The one exceptions are formatting it for publication as an RFC or translating 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
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 .........................841. Introduction 🧚
There's a core set of conference info that every conference needs, no matter what media it's using 💅 This core data set is called the "conference information data model," and this document defines it in an XML-based format 🌸 The model is logically represented by the conference object 🫶
Conference objects are a big deal in centralized conferencing, as described in the centralized conferencing framework [RFC5239] ✨ A conference object is a particular instance of a conference information data model, so conference objects use the XML format defined in this document 💖
The Session Initiation Protocol (SIP) event package for conference state, specified in [RFC4575], already has a data format for conferences 🦋 But that model is SIP-specific and is missing some of the stuff the centralized conferencing framework [RFC5239] covers, like floor control 💀 So this data model is a superset of the data format from [RFC4575] 🔥 The result supports more call signaling protocols (CSPs) besides SIP and covers all the functionality 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 terms defined in the centralized conferencing framework [RFC5239], the SIPPING conferencing framework [RFC4353], and the BFCP (Binary Floor Control Protocol) specification [RFC4582] 🍓 Readers should be familiar with the terminology used in those documents, bestie 📚
3. Overview 🦋
The data model in this document comes from extending the data format defined in [RFC4575] with new elements ✨ Examples of those extensions include scheduling elements, media control elements, floor control elements, non-SIP URIs, and localization extensions added to text elements 💜 Conference servers offering different types of basic conferences can use this data model 🌸 It's expected that the data model can be extended further with new elements later on to support 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 conference object document syntax, for implementers of parsers and generators, is in the RELAX NG schema in Section 5 🔥 Compliant messages MUST meet the requirements of that schema 💖
3.2. Data Model Namespace 🌈
This specification defines a new namespace for identifying the elements in the data model ✨ The namespace is:
urn:ietf:params:xml:ns:xcon-conference-infothat's the end of part 1 🎀 the rest of the spec (3.3 onwards) comes next, so stay tuned, bestie 💅🦋
3.3. The Conference Object Identifier 🎀
Okay so the conference object identifier (XCON-URI) is basically the key to one specific conference object 🔑✨ It's what the conference control protocol uses to get at, change, and delete that object, no cap. The conferencing client gets it from the conference notification service, or through out-of-band mechanisms (e.g., email) 📧
A conferencing system can keep track of how the conference object identifiers line up with the identifiers for each of the complementary centralized conferencing protocols (e.g., call signaling protocol, BFCP, etc.) 🧩 The conference object identifier acts as the top-level ID inside the system for finding the interfaces of these other protocols. This implicit binding gives you a neat, structured mapping of all the protocols back to the conference object identifier 💅 Figure 1 shows how the IDs for the protocols connect to the general conference object identifier (XCON-URI).
+--------------------------+
| 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 MappingIn Figure 1, the conference object identifier is the top-level key for the whole identification process 👑 The call signaling protocols each have a conference user identifier, which is often written as a URI 🌸 BFCP, as defined in [RFC4582], has a 'conference ID' identifier that stands for a conference instance inside floor control. When the conferencing system creates one, the 'conference ID' has a 1:1 mapping to the unique conference object identifier (XCON-URI) 🦋 Conference control operations are tied straight to the conference object, so the main identifier for those protocols is the conference object identifier (XCON-URI) 💖
The mappings for the additional protocols and interfaces aren't strictly 1:1, and they're allowed to show up multiple times 🙈 For example, several call signaling protocols can each have a representation that's implicitly linked to the top-level conference object identifier, like the H323 and SIP URIs that stand for one conference instance 📞 It should be noted that a conferencing system is free to structure these relationships however it needs to, and this information is just a guideline you can use ✨
Further elements can be added to the tree representation in Figure 1 so you get a complete picture of a conference instance inside 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 isn't designed to be resolved 🙅♀️ So an application MUST NOT attempt to run a standard DNS lookup on the host portion of one of these URIs to try to find an IP address or port to connect to 💀
3.3.2. Normalization and Conference Object URI Comparison 🍓
To make comparing XCON-URI identifiers easier, all the components of the identifiers MUST be converted to lowercase 🫶 After you normalize 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, and those aren't usually compared character by character 🤔 But the host part of an XCON-URI is only an identifier, so it's 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 like this 💅 All the information about a conference lives inside a <conference-info> element, and that element has these child elements:
- The
<conference-description>element describes the conference as a whole ✨ It has things like the URI of the conference, the maximum number of users allowed, the media available in the conference, or the time the conference will start 🎀 - The
<host-info>element has info about the entity hosting the conference (e.g., its URI) 🏠 - The
<conference-state>element keeps subscribers posted on changes to the overall conference information 📣 - The
<floor-information>element has info on the status of the different floors in the conference 🦋 - The
<users>element describes the membership information as a whole 👑 It holds a set of<user>child elements, and each one describes a single participant in the conference 🫶 - If a participant in the main conference joins a sidebar, a new element gets created in the conference. It's referenced from the
<sidebars-by-ref>element or lives under one of the<sidebars-by-val>elements 🧚
Some of the elements above, like <conference-info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-val>, aren't defined in the data model in this specification 🙃 They're defined in the data format of [RFC4575]. We describe them here anyway because they're part of the basic structure of the data model, and you need to know them to see the whole picture 🌈
4. Data Model Definition ✨
okay so this part is the big family tree of the whole conference object 🌳💖 the diagram below is NOT normative (it's just a pretty map, bestie), but the symbols matter: a "!" in front of an element means it is REQUIRED in the data model 🔥, and a "*" after an element means it's brand new and defined in this doc 🎀. no star? that one was already 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>*
| | | |--<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>*
| | | | |--<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>
| | | |
| | | ...
| | |--<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>
| ...
|--<sidebars-by-val>
| |--<entry>
| | |
| | ...
| |--<entry>
| | |
| ... ...the diagram is basically a cheat sheet 💅 the deep-dive for each element is coming up, and the full RELAX NG schema lives in Section 5 🌈
4.1. <conference-info>
every conference object document starts with the root element <conference-info> 🌸 that one is defined in [RFC4575]. the state and version attributes on it are also from [RFC4575], but we're NOT using them here because they only matter for notification mechanisms 🙈
[RFC4575] also has an entity attribute that holds the SIP URI identifier. this spec stretches that entity attribute so it can hold the conference object identifier (XCON-URI) instead, which we explain in Section 3.3 🦋
on top of that, this spec adds the child elements of <floor-information> to <conference-info> itself 🎀
4.2. <conference-description>
the <conference-description> element, which comes from [RFC4575], describes the whole conference (the big picture, babe 🌍). it SHOULD have a lang attribute to say what language the stuff inside it is written in 🇬🇧. its kids are <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], so go check there if you want the original scoop 💜
the next subsections go deeper into these elements, one by one 🧚 other child elements MAY be defined later on to extend <conference-description>, so keep your eyes peeled 👀
4.2.1. <language>
the <language> element tells everyone the predominant language people are expected to use in the conference 🗣️ it holds only one language. the allowed values are the values from the 'Subtag' column of the "Language Subtag Registry" at [IANA-Lan], which was originally defined in [RFC5646] 🌷
here's the tea 🫖: this element does NOT enforce the language. it just gives participants a heads-up about the language they should ideally use. they're totally free to switch to other languages if they want 🕊️
4.2.2. <allow-sidebars>
the <allow-sidebars> element is a boolean, so it's either yes or no 🎀 if it's set to true or "1", the conference is allowed to create sidebar conferences ✅. if it's absent, or set to "false" or "0", then the conference cannot create sidebar conferences 🚫
4.2.3. <cloning-parent>
when a <cloning-parent> is present, it means this conference object is a child of a parent conference 👶 the <cloning-parent> element holds the conference object identifier (XCON-URI) of that parent, and it's different from the main XCON-URI 🔗
4.2.4. <sidebar-parent>
when a <sidebar-parent> is present, it means this conference object represents a sidebar of another conference 💬 the <sidebar-parent> element holds the conference object identifier (XCON-URI) of the parent, which is also different from the main XCON-URI 🦋
4.2.5. <conference-time> 📅
okay so <conference-time> is where all the scheduling drama lives 💅 it holds the time, policy, and duration info for a conference, and it can have one or more <entry> elements, each one defining the time and policy for a single conference occurrence 🦋. what makes it different from iCalendar objects [RFC5545] is that it can set different policies (<can-join-after-offset>, <must-join-before-offset>) for the same conference at different times. it's giving flexibility 🌸
every <entry> has these child elements:
<base>: this one points to the iCalendar object of the conference. the iCalendar object components are defined in [RFC5545] 🎀<mixing-start-offset>: this says how long before the conference starts the media mixing begins. it's an absolute value, not an offset value 🧚 if this element isn't there, mixing just starts right away ✨ it MUST include the'required-participant'attribute 💖 that attribute can be"none","administrator","moderator","user","observer", or"participant"🌈 the semantic definitions of those roles are out of scope for this document and will be handled by future policy documents 📜 more values can show up later too. the'required-participant'attribute lets a privileged user decide when mixing starts, based on whichever is later: the mixing start time or the moment the first participant arrives 👑 if it's set to"none", mixing just follows the mixing start time 🫶<mixing-end-offset>: this says when media mixing stops, measured as time after the conference stops 🍓 if the element isn't there, the conference occurrence is unbounded ♾️ it MUST include the'required-participant'attribute too, with the same six values:"none","administrator","moderator","user","observer", and"participant"💜 more values can be added later 🔥 this attribute lets a privileged user decide when mixing ends, based on whichever is earlier: the<mixing-end-offset>or the moment the last participant leaves 😭 if it's set to"none", mixing stops according to<mixing-end-offset>💅 and here's the drama: if the conference policy gets changed so the last privileged user is now a regular participant, and the conference still needs a privileged user to keep going, then that conference MUST terminate 💀<can-join-after-offset>: an administrator uses this element to say when users are allowed to start joining the conference 🦋<must-join-before-offset>: an administrator uses this element to set the point after which new users can't join the conference anymore 🙈<request-user>: this one sets when users or resources on the<allowed-users-list>get asked to join the conference, using the<request-users>element 🌸<notify-end-of-conference>: this one defines, in seconds, when the system MUST send a notice that the end of the conference is coming up ⏰ if it isn't there, the system doesn't warn users when the end is approaching 🥲<allowed-extend-mixing-end-offset>: this shows whether the conference is allowed to be extended 🎀 it's a boolean value ✨
4.2.6. <conf-uris> 🔐
the <conf-uris> element holds a set of <entry> child elements, and each one contains a new element called <conference-password> 🗝️ this is where the password(s) for the conference go. for example, a PSTN (Public Switched Telephone Network) conference would store its 'PIN code' here 📞 every other <conf-uris> child element is described in Section 5.3.1 of [RFC4575] 🌷
the RELAX NG schema in Section 5 lets <conference-password> show up anywhere uris-type gets expanded, but this document only gives it meaning when it's a descendant of <conf-uris> 🧐 future standardization might give it meaning in other uris-type elements. until that happens, <conference-password> MUST NOT appear in any uris-type elements besides <conf-uris> 🚫 absolutely not, bestie 😤
4.2.7. <available-media> 🎬
the <available-media> element is a sequence of <entry> child elements 💖 each <entry> MAY contain these child elements:
<display-text>,<type>, and<status>: these are described in Section 5.3.4 of [RFC4575] ✨<mixing-mode>: this one describes a default scheduling policy that the mixer uses to build the outgoing stream from the incoming streams 🌀 it's different from the policy that describes the floors for each media, so don't mix them up 🙃 the<mixing-mode>element MUST contain one and only one of the values"moderator-controlled","FCFS", and"automatic", which tells the default algorithm to use with every media stream 🎯"moderator-controlled"means the conference moderator controls the media stream policy 👑"FCFS"means a 'first-come-first-served' policy 🏃♀️ and"automatic"means the mixer must choose the best scheduling policy for the conference 🧠<codecs>: this one specifies which codecs are allowed in the conference 🎧 it has a 'decision' attribute that says whether the focus picks the common codec automatically or needs the moderator's approval ("automatic","moderator-controlled") 🌟 the<codecs>element contains<codec>elements. a<codec>element can have the attributes 'name' and 'policy' 💜 the 'name' attribute is a codec identifier assigned by the conferencing server 🏷️ the 'policy' attribute holds the policy for that codec (allowed or disallowed) 🚦 each<codec>also has a child element called<subtype>, which stores the codec's name 🎀 the possible values for<subtype>are the values from the 'subtype' column of the "RTP Payload Format media types" registry at [IANA], which was originally defined in [RFC4855] 📚 future conferencing specs are expected to define matching schema extensions, as appropriate 🔮<controls>: this holds the basic audio and video global control elements for a conference 🎛️ they're enough for most basic conferences 🍰 if the conference server wants more advanced controls, it is RECOMMENDED to use an extension to the data model instead 🧩 the schema for<controls>is extensible, so new control types can be added later 🌈 moderator controls that affect all media output go under<available-media>instead 💅 these child elements are defined for<controls>:<mute>: used with an audio stream to stop all audio transmission from that stream 🔇 for the whole time mute applies, every current and future participant is muted and won't send any audio 🙊 it's a boolean value. if this control isn't specified, the client doesn't get access to it 🚫<pause-video>: used with a video stream to stop transmission of the associated media ⏸️ it's a boolean value. if this control isn't specified, the client doesn't have access to it 🥺<gain>: used with a media output stream to show how much an audio stream is amplified 🔊 the value is an integer from -127 to 127 📊 if this control isn't specified, the client doesn't have access to it 💫<video-layout>: used with a video stream to specify how the participants' video streams are viewed by each participant 📺 only one layout type can be set for each output stream 🎞️ if there are fewer participants than panels in the chosen layout, blanking (a black screen) MAY be mixed into the stream on behalf of the missing input streams 🖤 if it's unspecified, the default type SHOULD be"single-view"✨ here are the layout types, though any number of custom layouts may be added in future extensions 🌸single-view: only one stream is presented by the focus to all participants, in one panel 🎯dual-view: the video is shown side-by-side in two panels and the aspect ratio of the streams is not altered 👯 this means the focus has to add blanking to parts of the overall image that participants see 🌗dual-view-crop: a side-by-side layout where the focus alters the aspect ratio of the streams (alter-aspect-ratio=true), so blanking isn't needed 🪄 the focus handles the cropping of the streams ✂️dual-view-2x1: the focus places one stream above the other, so two rows and one column 🌷 the aspect ratio is not altered and blanking is introduced 🌫️dual-view-2x1-crop: the focus again places one stream above the other, in two rows and one column 💕 this time 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 is maintained (alter-aspect-ratio= FALSE) 📐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 is 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 is preserved 💎multiple-5x1: a 5x1 layout where one panel occupies 4/9 of the mixed video stream and the others each occupy 1/9 🌙 typically the aspect ratio of the streams is preserved 🩷automatic: the focus adds 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> element was introduced in [RFC4575] ✨ it 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> 💖
okay so <allow-conference-event-subscription> is a boolean action, bestie 🫶 If it's set to true, the focus gets the green light to allow subscriptions to conference state events, like the 'SIP event package for conference state' [RFC4575] 🦋 If it's set to FALSE, the subscription to conference state events MUST be rejected. And if the element is undefined, the default is true, so those subscriptions get accepted ✨
4.5. <floor-information> 🎀
The <floor-information> element holds the <conference-ID>, <allow-floor-events>, <floor-request-handling>, and <conference-floor-policy> child elements. If this element isn't in an XML document, that means the conference doesn't have a floor 🙈
4.5.1. <conference-ID> 🧚
The <conference-ID> represents a conference instance within floor control. When BFCP is the floor control protocol, the <conference-ID> is a 32-bit BFCP conference identifier defined in [RFC4582], Section 5.1. Also, when it's created inside the conferencing system, there's 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 it's set to true, the focus is told to accept the subscription to floor control events. If it's set to FALSE, the focus is told to reject it. If the element is undefined, the default value is FALSE, so the subscription to floor control events gets rejected.
A conference participant can sign themselves up for floor control events in two different ways 🍓 One way is an offer/answer exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters in the SDP [RFC4583]. The other way 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 the conference focus uses to control floor requests. It sets the action the focus takes when it processes a particular request to a floor within a conference. The values are:
"block": This action tells the focus to deny the floor request. It's the default action when no other actions are present."confirm": This action tells 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 is about floor control information, so the value"block"in a<floor-request-handling>element isn't related to the"block"value in the<join-handling>element (see Section 4.6.1). Different thing, same word, no cap 🙃
4.5.4. <conference-floor-policy> 👑
The <conference-floor-policy> element has one or more <floor> child elements. Every <floor> child element has an id attribute, which uniquely identifies a floor within a conference. For BFCP [RFC4582], the id attribute corresponds to the floor-id identifier defined in [RFC4582], Section 5.2.2.
<media-label>: Every floor is identified by 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 tells you how many floors the conference can have. A floor can be used for one or more media types.<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, which indicate the algorithm. The"moderator-controlled"value means the moderator of the conference controls the floor. The"FCFS"value means a 'first-come-first-served' policy.<max-floor-users>: The<max-floor-users>child element in the<floor>element is OPTIONAL and, if present, sets the maximum number of users who can have the floor at one time.<moderator-id>: The OPTIONAL<moderator-id>shows the "User ID" of the moderator(s). It MUST be set if the<algorithm>element is set to the"moderator-controlled"value. When the floor is created inside the conferencing system, the XCON-USERID MAY be used as the<moderator-id>. When BFCP is the floor control protocol, the<moderator-id>is defined in [RFC4582], Section 3. Note that [RFC4582] calls the moderator role a "floor chair" 🪑
4.6. <users> 🌈
The <users> element is described in [RFC4575]. It contains the <join-handling>, <user-admission-policy>, <allowed-users-list>, and <deny-users-list> defined in this document, plus <user> child elements defined in [RFC4575]. When <users> is used in the XCON Conference Information Model, the 'state' and 'version' attributes defined in [RFC4575] aren't used, since they only apply to notification mechanisms. The following sections go into more detail on these elements. Other child elements and attributes can be added to <users> in the future ✨
4.6.1. <join-handling> 🔥
The <join-handling> element defines the actions the conference focus uses to control conference participation. It sets the action the focus takes when it processes a particular request to join a conference. The values are:
"block": This action tells the focus to deny access to the conference. It's the default action when no other actions are present."confirm": This action tells the focus to place the participant on a pending list (for example, by parking the call on a music-on-hold server) while it waits for moderator input on further actions."allow": This action tells the focus to accept the conference join request and grant access to the conference, within the instructions specified in the transformations of this rule."authenticate": This action tells the focus that the user has to provide a combination of username and password."directed-operator": This action tells 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 the right permissions) choose a policy for the conference. That policy 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 may need to be mapped from the different protocols, and each individual conference server decides which ones. The specific types of authentication mechanisms are beyond the scope of this document. The possible values are:
"closedAuthenticated": A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list (listed under the<allowed-users-list>element), and each participant has to be sufficiently (up to local policy) authenticated. Conference join requests from users who aren't in the allowed users list, or from participants who aren't authenticated, should be rejected, unless a<join-handling>action of 'confirm' is selected. In that case, the user is placed on a pending list as described earlier. A 'closedAuthenticated' policy MUST NOT include a<deny-users-list>. If<deny-users-list>appears in the data model, it MUST be ignored."openAuthenticated": An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated. Typically, this means that anyone who can authenticate with the conferencing system may join the conference. The 'openAuthenticated' policy allows "banned" conferencing participants to be specified. Banned users can't re-join the conference until they've been un-banned. An 'openAuthenticated' policy SHOULD have a deny users list (listed under the<deny-users-list>XML element) so that conferencing participants can be banned 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."anonymous": An 'anonymous' policy grants any join request 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> or a <deny-users-list> MUST be ignored, unless a future specification describes otherwise. Future specifications that use these lists must provide clear guidance on how to process them when they occur together, especially when both lists contain the same user. For example, such a specification could stop both lists from appearing at the same time, similar to the <user-admission-policy> values defined in this document 🫶
4.6.3. <allowed-users-list> 🎀
okay so the guest list is the <allowed-users-list> element 💅 It holds user URIs (like XCON-USERID, which you'll meet in Section 4.6.5), roles (see Section 4.6.5.2), or domains (think *@example.com) that the focus checks to figure out who can join the conference, who can be invited, or who the focus needs to "refer to" the conference. It can hold zero or more <target> child elements. Each <target> has the mandatory uri attribute AND the mandatory method attribute 🫶 The same uri can show up more than once in the list, as long as the method values are different.
The method attribute is a list with these values:
- "dial-in": the focus uses this one to decide who can join the conference 🚪
- "dial-out": this one holds a list of resources that the focus will start a session with 📞
- "refer": the focus uses this to figure out which resources it needs to "refer to" the conference. In SIP, the focus does that by sending a REFER request to those potential participants. In a different paradigm, it could also mean the focus sends an SMS or an email to the referred user 📩 This list can change during the conference lifetime, so it works for mid-conference refers too ✨
The "refer" value is different from "dial-out" because the resources on the "refer" list are expected to start the session setup toward the focus themselves 🙈 It's also envisioned that different users will have different access rights to those lists, so the two need to stay separate. iykyk.
The <allowed-users-list> element also has a <persistent-list> child element. Some chat room systems allow -- and some require -- registering detailed info about a user before they can join a chat room 🍓 The <persistent-list> stores info about users who aren't actively in an ongoing chat room session right now. It stores the following:
- 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, andid, plus 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 too.
4.6.4. <deny-users-list> 🚫
The <deny-users-list> child element is the naughty list 😤 It holds user URIs (like a SIP URI or the 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 figure out who has been 'banned' from the conference. Banned users are blocked from re-joining the chat room until the ban is lifted. no re-entry, bestie 💀
4.6.5. <user> and Its <user> Sub-Elements 👑
The element <user> is described in [RFC4575], and it represents a single participant in the conference. It has an attribute called 'entity'. When <user> shows up in the XCON Conference Information Model, the 'state' and 'version' attributes from [RFC4575] are NOT used, since they only apply to notification mechanisms 🙅♀️
The 'entity' attribute holds a unique conference user identifier (XCON-USERID), which is unique within the scope of the conference. This identifier's URI format looks like this (written in ABNF [RFC5234]):
XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*unreservedNote: unreserved is defined in RFC 3986.
To make comparing XCON-USERID identifiers easier, all the components of the identifiers MUST be converted to lowercase 🔤
After normalizing the URI strings, the URI 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 linked to this conference user identifier. That lets the conferencing system correlate and map multiple authenticated user identities to a single global user identifier, which is so main character energy 🦋 Figure 2 shows an example that links the conference user identifier to the user identities defined for BFCP, SIP, and H323. It should be noted that a conferencing system is free to structure these relationships however it needs to, and this info is just a guideline 🌸
+----------------+
| Conference |
| User |
| Identifier |
+----------------+
|XCON-USERID:John|
+-------+--------+
|
|
|
+----------------------+-------------------------+
| | |
+-------+--------+ +-----------+-----------+ +-----------+-----------+
| BFCP User ID | | SIP User URI | | H323 User URI |
+----------------+ +-----------------------+ +-----------------------+
| 543 | |sip:851221@example.com | |h323:taeduk@example.com|
+----------------+ +-----------------------+ +-----------------------+Figure 2: Conference User Mapping
The <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> elements. The next sections break these down. <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 sets what level of anonymity the server gives the user 🫣 The focus either gives the other participants an anonymous identity for that user (like anonymousX), or it gives them no info at all, so nobody can see that this person is in the conference. This element only changes how the user info is shown to the other participants. The real user info is still stored in the data model, but it SHOULD NOT be provided to the other participants of the conference, and <provide-anonymity> is how you make that happen 🔒
This element has three values:
- "private": the user is completely anonymous in the conference 🥷
- "semi-private": the user is anonymous to everyone who hasn't been given permission to see them 👀
- "hidden": other users can't see this participant in the conference at all 🫥
4.6.5.2. <roles> 🎭
A <role> gives the context for the set of conference operations a participant can perform 💫 This element can contain one or more of these values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" means that any role is assigned. The semantics of <roles> are out of scope for this document and will be handled by future policy documents 📝 The element can also be extended with new roles in future documents 🌈
4.6.5.3. <allow-refer-users-dynamically> 🔁
The <allow-refer-users-dynamically> element is a boolean value 🫶 If it's set to true, a participant can tell the focus to refer a user to the conference without changing the <allowed-users-list>. In SIP terms, the participant sends a REFER request [RFC3515] to the focus, and the focus then sends a REFER request to the user the referrer wants to join the conference. If it's set to FALSE, the REFER request gets rejected. If this element is undefined, it has a value of FALSE, so the REFER request gets rejected 🙅♀️
4.6.5.4. <allow-invite-users-dynamically> 💌
The <allow-invite-users-dynamically> element is a boolean action ✨ If it's set to true, a participant can tell the focus to invite a user to the conference without changing the <allowed-users-list>. In SIP terms, the participant sends a REFER request [RFC3515] to the focus, and the focus sends an INVITE request to the user the referrer wants to join the conference. If it's set to FALSE, the REFER request gets rejected. If this element is undefined, it has a value of FALSE, so the REFER request gets rejected 🎀
4.6.5.5. <allow-remove-users-dynamically> 👋
The <allow-remove-users-dynamically> element is also a boolean action 💅 If it's set to true, a participant can tell the focus to remove a user from the conference without changing the ruleset. In SIP terms, the participant sends a REFER request [RFC3515] to the focus, and the focus sends a BYE request to the user the referrer wants to leave the conference. If it's set to FALSE, the REFER request gets rejected. If this element is undefined, it has a value of FALSE, so the REFER request gets rejected 🫠
4.6.5.6. <endpoint> 🎀
okay bestie, so the <endpoint> child element is basically a twin of the one in [RFC4575] 👯♀️ same name, same energy, with one difference: it doesn't include the state attribute 💅 When it shows up in the XCON Conference Information Model, the state and version attributes from [RFC4575] aren't used, because they only matter for notification mechanisms 🔔 Still, <endpoint> gives you the detail you want about the user's devices and their signaling sessions taking part in the conference ✨
The <endpoint> element has these child elements: <display-text>, <referred>, <status>, <joining-method>, <joining-info>, <disconnection-method>, <disconnection-info>, <media>, and <call-info> 🧚 All of them are defined in [RFC4575] except <to-mixer> and <from-mixer>, which are new here 🌸
The <endpoint>/<media> element has two more child elements defined in this document: <to-mixer> and <from-mixer> 💖
<from-mixer>,<to-mixer>: These are controls that apply to a user's media stream, either being sent from the mixer to the participant's endpoint, or going to the mixer from the participant's endpoint 🦋 The<to-mixer>element details properties of the incoming streams to the mixer (the ones sent to the mixer from the participant). The<from-mixer>element details properties of the outgoing streams from the mixer (the ones sent from the mixer to the participant). Both of these elements have the attributename, and it takes the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn" 🎬- "VideoOut" and "AudioOut" media streams detail properties of the outgoing video and audio from the mixer ⭐
- "VideoIn" and "AudioIn" media streams detail properties of 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 needs to talk, they first have to get the floor from the chair of the conference 🙈 The<floor>element has an attributeid, which uniquely identifies a floor within a conference. Theidattribute corresponds to the floor-id identifier defined in [RFC4582], Section 5.2.2 🍓 The<floor>element holds a boolean value. A value of FALSE means this user does not hold the floor at this moment. If this control isn't specified, this user SHOULD NOT specify the floor option 🫶
- The
- 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 ✨
- Controls that apply to a specific user would appear under the
- 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 🗂️ It's described in [RFC4575], Section 5.9.1 💅 When it's used in the context of the XCON conference information model, the state and version attributes from [RFC4575] aren't used, since they only apply to notification mechanisms 🔔
4.8. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child elements, and each one holds information about a single sidebar 🌷 It's described in [RFC4575], Section 5.9.2 ✨ Just like before, when it's used in the XCON conference information model, the state and version attributes from [RFC4575] aren't used, because they only apply to notification mechanisms 🫧
5. RELAX NG Schema
Following the centralized conferencing framework document [RFC5239], the conference object is a logical representation of a conference instance 🌸 The conference information schema holds the core information used in any conference, and 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] 🎀 On top of approximately similar RELAX NG [RELAX] definitions of [RFC5239], this schema contains extension elements in the "urn:ietf:params:xml:ns:xcon-conference-info" namespace 🌈
default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"
start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
attribute entity { text }
& anyAttribute
& conference-description-type?
& element host-info { host-type }?
& element conference-state { conference-state-type }?
& element users { users-type }?
& element sidebars-by-ref { uris-type }?
& element sidebars-by-val { sidebars-by-val-type }?
& element xcon:floor-information { floor-information-type }?
& anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
element conference-description {
attribute xml:lang { xsd:language }?
& anyAttribute
& element display-text { text }?
& element subject { text }?
& element free-text { text }?
& element keywords {
list { xsd:string* }
}?
& element conf-uris { uris-type }?
& element service-uris { uris-type }?
& element maximum-user-count { xsd:int }?
& element available-media { conference-media-type }?
& element xcon:language { xsd:language }?
& element xcon:allow-sidebars { xsd:boolean }?
& element xcon:cloning-parent { xsd:anyURI }?
& element xcon:sidebar-parent { xsd:anyURI }?
& element xcon:conference-time { conferencetime-type }?
& anyElement*
}
# HOST TYPE
host-type =
element display-text { text }?
& element web-page { xsd:anyURI }?
& element uris { uris-type }?
& anyElement*
& anyAttribute
# CONFERENCE STATE TYPE
conference-state-type =
anyAttribute
& element user-count { xsd:unsignedInt }?
& element active { xsd:boolean }?
& element locked { xsd:boolean }?
& element xcon:allow-conference-event-subscription { xsd:boolean }?
& anyElement*
# CONFERENCE MEDIA TYPE
conference-media-type =
anyAttribute
& element entry { conference-medium-type }*
& anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
attribute label { text }
& anyAttribute
& element display-text { text }?
& element type { text }?
& element status { media-status-type }?
& element xcon:mixing-mode { mixing-mode-type }?
& element xcon:codecs { codecs-type }?
& element xcon:controls { control-type }?
& anyElement*
# URIs TYPE
uris-type =
anyAttribute
& element entry { uri-type }*
& anyElement*
# URI TYPE
uri-type =
element uri { xsd:anyURI }
& element display-text { text }?
& element purpose { text }?
& element modified { execution-type }?
& element xcon:conference-password { text }*
& anyElement*
& anyAttribute
# USERS TYPE
users-type =
anyAttribute
& element user { user-type }*
& element xcon:join-handling { join-handling-type }?
& element xcon:user-admission-policy { user-admission-policy-type }?
& element xcon:allowed-users-list { allowed-users-list-type }?
& element xcon:deny-users-list { deny-user-list-type }?
& anyElement*
# USER TYPE
user-type =
attribute entity { xsd:anyURI }
& anyAttribute
& element display-text { text }?
& element associated-aors { uris-type }?
& element roles {
element entry { single-role-type }+
}?
& element languages {
list { xsd:language }
}?
& element cascaded-focus { xsd:anyURI }?
& element endpoint { endpoint-type }*
& element xcon:provide-anonymity { provide-anonymity-type }?
& element xcon:allow-refer-users-dynamically { xsd:boolean }?
& element xcon:allow-invite-users-dynamically { xsd:boolean }?
& element xcon:allow-remove-users-dynamically { xsd:boolean }?
& anyElement*
# ENDPOINT TYPE
endpoint-type =
attribute entity { text }
& anyAttribute
& element display-text { text }?
& element referred { execution-type }?
& element status { endpoint-status-type }?
& element joining-method { joining-type }?
& element joining-info { execution-type }?
& element disconnection-method { disconnection-type }?
& element disconnection-info { execution-type }?
& element media { media-type }*
& element call-info { call-type }?
& anyElement*
# ENDPOINT STATUS TYPE
endpoint-status-type =
"pending"
| "dialing-out"
| "dialing-in"
| "alerting"
| "on-hold"
| "connected"
| "muted-via-focus"
| "disconnecting"
| "disconnected"
| free-text-extension
# JOINING TYPE
joining-type =
"dialed-in" | "dialed-out" | "focus-owner" | free-text-extension
# DISCONNECTION TYPE
disconnection-type =
"departed" | "booted" | "failed" | "busy" | free-text-extension
# EXECUTION TYPE
execution-type =
element when { xsd:dateTime }?
& element reason { text }?
& element by { xsd:anyURI }?
& anyAttribute
# CALL TYPE
call-type =
element sip { sip-dialog-id-type }
& anyElement*
& anyAttribute
# SIP DIALOG ID TYPE
sip-dialog-id-type =
element display-text { text }?
& element call-id { text }
& element from-tag { text }
& element to-tag { text }
& anyElement*
& anyAttribute
# MEDIA TYPE
media-type =
attribute id { xsd:int }
& anyAttribute
& element display-text { text }?
& element type { text }?
& element label { text }?
& element src-id { text }?
& element status { media-status-type }?
& element xcon:to-mixer { mixer-type }?
& element xcon:from-mixer { mixer-type }?
& anyElement*
# MEDIA STATUS TYPE
media-status-type =
"recvonly"
| "sendonly"
| "sendrecv"
| "inactive"
| free-text-extension
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
anyAttribute
& element entry { conference-type }*
& anyElement*
# CONFERENCE TIME
conferencetime-type =
anyAttribute
& element xcon:entry {
element xcon:base { text },
element xcon:mixing-start-offset {
time-type,
attribute required-participant { single-role-type },
anyAttribute
}?,
element xcon:mixing-end-offset {
time-type,
attribute required-participant { single-role-type },
anyAttribute
}?,
element xcon:can-join-after-offset { time-type }?,
element xcon:must-join-before-offset { time-type }?,
element xcon:request-user { time-type }?,
element xcon:notify-end-of-conference { xsd: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 =
xsd:string "automatic"
| xsd:string "moderator-controlled"
| free-text-extension
# POLICY TYPE
policy-type =
xsd:string "allowed" | xsd:string "disallowed" | free-text-extension
# CONTROL TYPEOkay bestie, the schema is giving a lot of building blocks, so let's keep going 💖
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 }?
& 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*
}*
& 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
| 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
| 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
| 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 🦋
Okay so the conference information data model in this doc is built to be extensible, which is so smart 🧚 You add your own stuff by defining elements or attributes under namespaces that are not urn:ietf:params:xml:ns:conference-info or urn:ietf:params:xml:ns:xcon-conference-info. You can do that anywhere the schema allows it, aka wherever the RELAX NG definition says anyAttribute or anyElement 💅
Elements or attributes from unknown namespaces MUST be ignored.
7. XML Example 🎀
Okay bestie, here's the example! ✨ It's a conference information document for a Formula-1 chat 🏎️ The conference starts on October 17, 2007, at 10:30 a.m. in New York City, finishes the same day at 12:30 p.m., and then repeats every week 🗓️ Right now there are three participants: one administrator, one moderator, and one participant 🫶 Sidebars are allowed, so there's one sidebar going on too 🌈 And Alice and Carol are sharing a floor in the main conference to manage the audio and video resources 🔥 Alice is the one currently 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>
<!--
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
-->okay bestie, the example is still going and the drama is unreal 🎀✨ here's where we pick up with the conference time, the host info, the conference state, and the users (Bob, Alice, and Carol) 💅
<xcon:conference-time>
<xcon:entry>
<xcon:base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20071003T140728Z
UID:20071003T140728Z-345FDA-carol@example.com
ORGANIZER:MAILTO:carol@example.com
DTSTART:20071017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20071217T163000Z
END:VEVENT
END:VCALENDAR</xcon:base>
<xcon:mixing-start-offset
required-participant="moderator"
>2007-10-17T14:29:00Z</xcon:mixing-start-offset>
<xcon:mixing-end-offset
required-participant="participant"
>2007-10-17T16:31:00Z</xcon:mixing-end-offset>
<xcon:must-join-before-offset
>2007-10-17T15:30:00Z
</xcon:must-join-before-offset>
</xcon:entry>
</xcon:conference-time>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page>
<uris>
<entry>
<uri>sip:alice@example.com</uri>
</entry>
<entry>
<uri>sip:carol@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
<xcon:allow-conference-event-subscription
>true</xcon:allow-conference-event-subscription>
</conference-state>
<!--
USERS
-->
<users>
<!--
USER BOB
-->
<user entity="xcon-userid:bob534">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2007-10-17T14:00:00Z</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2007-10-17T14:00:00Z</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
<xcon:provide-anonymity
>semi-private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>false</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>false</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>false</xcon:allow-remove-users-dynamically>
</user>
<!--
USER ALICE
-->
<user entity="xcon-userid:alice334">
<display-text>Alice Kay</display-text>
<associated-aors>
<entry>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>moderator</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:35:08Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
<xcon:floor id="345">true</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user>
<!--
USER CAROL
-->
<user entity="xcon-userid:carol233">
<display-text>Carol More</display-text>
<associated-aors>
<entry>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>administrator</entry>
</roles>
<languages>en-us</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2007-10-17T13:30:05Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<type>video</type>
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="VideoIn">
<xcon:controls>
<xcon:video-layout
>single-view</xcon:video-layout>
</xcon:controls>
</xcon:to-mixer>
</media>
<media id="2">
<type>audio</type>
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
<xcon:to-mixer name="AudioIn">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:to-mixer>
<xcon:from-mixer name="AudioOut">
<xcon:controls>
<xcon:gain>50</xcon:gain>
</xcon:controls>
</xcon:from-mixer>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
<xcon:floor id="345">false</xcon:floor>
</endpoint>
<xcon:provide-anonymity>private</xcon:provide-anonymity>
<xcon:allow-refer-users-dynamically
>true</xcon:allow-refer-users-dynamically>
<xcon:allow-invite-users-dynamically
>true</xcon:allow-invite-users-dynamically>
<xcon:allow-remove-users-dynamically
>true</xcon:allow-remove-users-dynamically>
</user> <xcon:join-handling>allow</xcon:join-handling>
<xcon:user-admission-policy
>openAuthenticated</xcon:user-admission-policy>
<!--
ALLOWED USERS LIST
-->
<xcon:allowed-users-list>
<xcon:target uri="sip:bob@example.com"
method="dial-out"/>
<xcon:target uri="sip:alice@example.com"
method="dial-out"/>
<xcon:target uri="sip:carol@example.com"
method="dial-out"/>
<xcon:target uri="sip:john@example.com"
method="refer"/>
</xcon:allowed-users-list>
<!--
DENY USERS LIST
-->
<xcon:deny-users-list>
<xcon:target uri="sip:charlie@example.com"/>
</xcon:deny-users-list>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref>
<entry>
<uri>xcon:conf223</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="conf223">
<users>
<user entity="xcon-userid:bob534"/>
<user entity="xcon-userid:carol233"/>
</users>
</entry>
</sidebars-by-val>
<!--
FLOOR INFORMATION
-->
<xcon:floor-information>
<xcon:conference-ID>567</xcon:conference-ID>
<xcon:allow-floor-events>true</xcon:allow-floor-events>
<xcon:floor-request-handling
>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="345">
<xcon:media-label>10234</xcon:media-label>
<xcon:media-label>10235</xcon:media-label>
<xcon:algorithm
>moderator-controlled</xcon:algorithm>
<xcon:max-floor-users>1</xcon:max-floor-users>
<xcon:moderator-id>234</xcon:moderator-id>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</conference-info>Quick heads-up 🎀: because of RFC formatting conventions, this document splits lines whose content would exceed 72 characters. So if a line looks chopped up, that's on the formatting, not on you! 💅
8. Security Considerations 🔐✨
okay bestie, this section is SERIOUS and I'm not gonna water it down 😭🔥. 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. So go read those too, no skipping! 🧚
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. Basically every protocol has to show its homework 📚💜.
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. (the vibe is "that's a whole other story, babe" 💅)
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].
This part is really important, so read it twice: the database MUST be locked down, its integrity MUST be protected, and the IDs SHOULD be super hard to guess. No cap, brute force is the enemy 🚨.
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. Yikes, that's giving "accidentally invited the wrong person to the group chat" energy 💀.
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. So privacy is a future-us problem, but it's coming 🌈.
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 }*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>
END9.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>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 💖
okay this section is literally the group chat thank-you list and I'm so here for it 🫶. 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. Iconic cast, honestly 👑🌟.
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
- [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
- [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
- [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
okay bestie, these are the bonus reads 📚✨ the places this spec points you to for extra context. here they are, all of them, no cap 💅
- [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.
- [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>.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
this appendix is the RELAX NG schema written out in XML syntax 🎀 it's non-normative, so it's here to help you see the shape of things. let's go 🦋
<?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">
<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>
</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"/>
</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">
<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>
<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"/>
</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>
</optional>okay bestie, the schema is about to get SO nested 💅✨
</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"/>
</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>
<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>
</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">
<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>
<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>
<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/>
</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> </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>okay so we're picking up right where the persistent list wraps up 💖 this part is all about the type definitions, the little building blocks the schema snaps together like Lego 🧱✨ the time type is a dateTime that has to have a T and a Z in it, which is very "timestamp or it didn't happen" 🕰️
the single role type gives you a menu of roles: none, administrator, moderator, user, observer, participant, plus a free-text-extension escape hatch for anything custom 🎀 literally iconic that it has an extension slot
<!--
MIXING MODE TYPE
-->
<define name="mixing-mode-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">automatic</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
CODECS TYPE
-->
<define name="codecs-type">
<interleave>
<attribute name="decision">
<ref name="decision-type"/>
</attribute>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:codec">
<ref name="codec-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
CODEC TYPE
-->
<define name="codec-type">
<interleave>
<attribute name="name">
<text/>
</attribute>
<attribute name="policy">
<ref name="policy-type"/>
</attribute>
<ref name="anyAttribute"/>
<optional>
<element name="xcon:subtype">
<text/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
DECISION TYPE
-->
<define name="decision-type">
<choice>
<value type="string">automatic</value>
<value type="string">moderator-controlled</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
POLICY TYPE
-->
<define name="policy-type">
<choice>
<value type="string">allowed</value>
<value type="string">disallowed</value>
<ref name="free-text-extension"/>
</choice>
</define>the mixing mode type is giving "who's in charge of the audio mix" 🎧 moderator-controlled, FCFS, or automatic 💅
then we get to codecs 🎶 a codecs element holds a decision attribute plus a bunch of codec children, and each codec has a name, a policy that's either allowed or disallowed, and an optional subtype. the policy menu is literally just allowed, disallowed, or the extension slot again, and I'm obsessed with how consistent the schema is about that free-text escape hatch 🦋
<!--
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
-->
<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>the control type is where the mute, pause-video, gain, and video-layout knobs live 🎛️✨ gain is an int that's allowed to go from -127 all the way up to 127, which is a very specific vibe 🙈 and the video layouts are a whole buffet, from single-view to multiple-5x1, plus automatic and, yes, the extension slot 🌈
<!--
FLOOR INFORMATION TYPE
-->
<define name="floor-information-type">
<interleave>
<ref name="anyAttribute"/>
<optional>
<element name="xcon:conference-ID">
<data type="unsignedLong"/>
</element>
</optional>
<optional>
<element name="xcon:allow-floor-events">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="xcon:floor-request-handling">
<ref name="floor-request-type"/>
</element>
</optional>
<optional>
<element name="xcon:conference-floor-policy">
<ref name="conference-floor-policy"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
FLOOR REQUEST TYPE
-->
<define name="floor-request-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
CONFERENCE FLOOR POLICY
-->
<define name="conference-floor-policy">
<interleave>
<ref name="anyAttribute"/>
<oneOrMore>
<element name="xcon:floor">
<interleave>
<attribute name="id">
<text/>
</attribute>
<ref name="anyAttribute"/>
<oneOrMore>
<element name="xcon:media-label">
<data type="nonNegativeInteger"/>
</element>
</oneOrMore>
<optional>
<element name="xcon:algorithm">
<ref name="algorithm-type"/>
</element>
</optional>
<optional>
<element name="xcon:max-floor-users">
<data type="nonNegativeInteger"/>
</element>
</optional>
<optional>
<element name="xcon:moderator-id">
<data type="nonNegativeInteger"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</element>
</oneOrMore>
</interleave>
</define>
<!--
ALGORITHM POLICY
-->
<define name="algorithm-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">random</value>
<ref name="free-text-extension"/>
</choice>
</define>floor stuff is where it gets spicy 🔥 floor information can carry a conference ID, a yes-or-no on floor events, how floor requests get handled (block or confirm), and a conference floor policy. that policy holds one or more floors, each with an id, one or more media labels, and optional algorithm, max-floor-users, and moderator-id fields. the algorithm options are moderator-controlled, FCFS, random, or the extension slot. the way this schema keeps reusing the same escape hatch is honestly so main character 👑
<!--
USERS ADMISSION POLICY
-->
<define name="user-admission-policy-type">
<choice>
<value type="string">closedAuthenticated</value>
<value type="string">openAuthenticated</value>
<value type="string">anonymous</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
JOIN HANDLING TYPE
-->
<define name="join-handling-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
<value type="string">allow</value>
<value type="string">authenticate</value>
<value type="string">directed-operator</value>
<ref name="free-text-extension"/>
</choice>
</define>
<!--
DENY USERLIST
-->
<define name="deny-user-list-type">
<interleave>
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="xcon:target">
<attribute name="uri">
<data type="anyURI"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</interleave>
</define>
<!--
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>last stretch of this part, and it's all about who gets through the door 🚪💜 the user admission policy is closedAuthenticated, openAuthenticated, or anonymous (plus the extension slot, obviously 🙃). join handling has block, confirm, allow, authenticate, and directed-operator. the deny list is just a bunch of target elements, each with a uri, and the allowed users list has targets plus an optional persistent list of users, each with a name, nickname, and id. the persistent list picks up right where I'm stopping here, so we'll continue in the next part 🫶🎀
Okay so the RELAX NG schema we just went through is the boss 👑, but there's a second, cuter sidekick in here too 🎀, the non-normative W3C XML Schema. Non-normative means it's a helpful buddy, not the rulebook, so the RELAX NG one still wins if they ever disagree 💅.
Here's the vibe check on this schema 🔍. It defines the extension elements in the urn:ietf:params:xml:ns:xcon-conference-info namespace. BUT its <xs:any> extensions are stricter than the normative RELAX NG schema [RELAX] 😬. And the RELAX NG schema [RELAX] lets child elements show up in any order, which is NOT the case here or in the [RFC4575] schema 🙅♀️. Also, this schema lets otherwise valid extension elements show up in spots they aren't allowed, so it's a little too chill about placement 🧚. Last tea: you literally can't pin down how many times an extension element is allowed to appear with this schema, so cardinalities are a no-go here 💀.
<?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"/>
<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 -->okay the schema part is where it gets spicy 💅🎀
<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"
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 -->
<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 -->
<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 -->
<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>
</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>
</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"/>
</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>Bestie, we're in the home stretch of the schema 🎀 Here's the rest of the mixer stuff, the name and anonymity patterns, and the closing tag 🦋
<!-- 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>
</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>Okay and now the people behind all of this 💖 Here are the authors, with their addresses and contact details exactly as they're written:
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.comThat's the whole RFC, babe 🌈👑 😭🫶
📦 where this page comes from
- ietf: rfc6501 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms