RFC 6503

Centralized Conferencing Manipulation Protocol

📅 published March 2012, from ietf

RFC 6503: Centralized Conferencing Manipulation Protocol 🎀

Okay bestie, this is RFC 6503, titled Centralized Conferencing Manipulation Protocol 💅. It's a Standards Track document from the IETF, published in March 2012, with ISSN 2070-1721. The authors are M. Barnes from Polycom, C. Boulton from NS-Technologies, S. Romano from the University of Napoli, and H. Schulzrinne from Columbia University 🦋. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.

Abstract ✨

So the Centralized Conferencing Manipulation Protocol (CCMP) lets an XCON system client create, retrieve, change, and delete objects that describe a centralized conference 🌸. It's how you control the basic and advanced stuff: the conference's state and capabilities, participants, their relative roles, and the details 💖. CCMP is stateless, XML-based, and works client-server style. Its requests and responses carry conference information as XML documents and fragments that follow the centralized conferencing data model schema 🧚.

Status of This Memo 🌈

This is an Internet Standards Track document 💜.

It's a product of the Internet Engineering Task Force (IETF) and 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 the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6503 🔗.

Copyright Notice ⭐

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.

Table of Contents 🗂️

1. Introduction ....................................................4
2. Conventions and Terminology .....................................5
3. XCON Conference Control System Architecture .....................5
   3.1. Conference Objects .........................................7
   3.2. Conference Users ...........................................7
4. Protocol Overview ...............................................8
   4.1. Protocol Operations ........................................9
   4.2. Data Management ...........................................10
   4.3. Data Model Compliance .....................................11
   4.4. Implementation Approach ...................................12
5. CCMP Messages ..................................................13
   5.1. CCMP Request Message Type .................................13
   5.2. CCMP Response Message Type ................................15
   5.3. Detailed Messages .........................................17
        5.3.1. blueprintsRequest and blueprintsResponse ...........20
        5.3.2. confsRequest and confsResponse .....................22
        5.3.3. blueprintRequest and blueprintResponse .............24
        5.3.4. confRequest and confResponse .......................26
        5.3.5. usersRequest and usersResponse .....................30
        5.3.6. userRequest and userResponse .......................32
        5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37
        5.3.8. sidebarByValRequest and sidebarByValResponse .......39
        5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42
        5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44
        5.3.11. extendedRequest and extendedResponse ..............47
        5.3.12. optionsRequest and optionsResponse ................49
   5.4. CCMP Response Codes .......................................53
6. A Complete Example of CCMP in Action ...........................57
   6.1. Alice Retrieves the Available Blueprints ..................58
   6.2. Alice Gets Detailed Information about a Specific
        Blueprint .................................................60

   6.3. Alice Creates a New Conference through a Cloning
        Operation .................................................62
   6.4. Alice Updates Conference Information ......................65
   6.5. Alice Inserts a List of Users into the Conference Object ..66
   6.6. Alice Joins the Conference ................................68
   6.7. Alice Adds a New User to the Conference ...................70
   6.8. Alice Asks for the CCMP Server Capabilities ...............72
   6.9. Alice Makes Use of a CCMP Server Extension ................75
7. Locating a Conference Server ...................................78
8. Managing Notifications .........................................79
9. HTTP Transport .................................................80
10. Security Considerations .......................................82
    10.1. Assuring That the Proper Conference Server Has
          Been Contacted ...........................................83
    10.2. User Authentication and Authorization ....................84
    10.3. Security and Privacy of Identity .........................85
    10.4. Mitigating DoS Attacks ...................................86
11. XML Schema ....................................................87
12. IANA Considerations ..........................................105
    12.1. URN Sub-Namespace Registration ..........................105
    12.2. XML Schema Registration .................................106
    12.3. MIME Media Type Registration for
          'application/ccmp+xml' ..................................106
    12.4. DNS Registrations .......................................107
         12.4.1. Registration of a Conference Server
                 Application Service Tag ..........................108
         12.4.2. Registration of a Conference Server
                 Application Protocol Tag for CCMP ................108
    12.5. CCMP Protocol Registry ..................................108
         12.5.1. CCMP Message Types ...............................109
         12.5.2. CCMP Response Codes ..............................111
13. Acknowledgments ..............................................113
14. References ...................................................113
    14.1. Normative References ....................................113
    14.2. Informative References ..................................114
Appendix A.  Evaluation of Other Protocol Models and
             Transports Considered for CCMP ......................116
   A.1.  Using SOAP for CCMP ......................................117
   A.2.  A RESTful Approach for CCMP ..............................117

1. Introduction 🦋

So "A Framework for Centralized Conferencing" [RFC5239] (the XCON framework) is the signaling-agnostic framework that sets up naming conventions and the logical entities you need for building advanced conferencing systems 🧚. The XCON framework brings in the conference object, which is a logical representation of a conference instance, showing its current state and capabilities 💖.

The Centralized Conferencing Manipulation Protocol (CCMP), defined in this document, lets authenticated and authorized users create, manipulate, and delete conference objects 👑. Conference operations include adding and removing participants, changing their roles, and adding and removing media streams and their associated endpoints 🎀.

CCMP implements the client-server model inside the XCON framework. The conferencing client acts as the client, and the conference server acts as the server 🫶. CCMP uses HTTP [RFC2616] to move requests and responses around, and those carry the domain-specific XML-encoded data objects defined in [RFC6501] "Conference Information Data Model for Centralized Conferencing (XCON)" 💅.

Here's the roadmap 🗺️. Section 2 covers the conventions and terminology used in the document. Section 3 gives an overview of the XCON framework's conference control functionality, along with the main targets CCMP deals with, which are conference objects and conference users 🌈. Section 4 describes the protocol operations in general and the implementation details. Section 5 gets into the specifics of individual CCMP messages. Section 6 is a complete, non-normative example of CCMP in action, walking through a typical call flow for creating and manipulating a conference 📚. Section 7 surveys the methods you can use to locate a conference server, and Section 8 talks about possible approaches to managing notifications ⭐. CCMP transport over HTTP gets the spotlight in Section 9 ✨. Security considerations are in Section 10 (and they are serious, so read them 😭). Last but not least, Section 11 has the XML schema 🍓.

2. Conventions and Terminology 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

On top of the terms defined in "A Framework for Centralized Conferencing" [RFC5239], this document uses the following terms and acronyms 🌸:

XCON-aware client: An XCON conferencing system client that is able to issue CCMP requests 💖.
First-Party Request: A request issued by the client to manipulate its own conferencing data 🦋.
Third-Party Request: A request issued by a client to manipulate the conference data of another client 👑.

3. XCON Conference Control System Architecture ✨

okay so CCMP is literally the bestie of the XCON framework 🫶 Figure 1 shows a slice of the "Conferencing System Logical Decomposition" architecture from the XCON framework document, and it's giving exactly how CCMP fits into the big centralized setup 💜

........................................................
.  Conferencing System                                 .
.                                                      .
.        +---------------------------------------+     .
.        |   C O N F E R E N C E   O B J E C T   |     .
.      +-+-------------------------------------+ |     .
.      |   C O N F E R E N C E   O B J E C T   | |     .
.    +-+-------------------------------------+ | |     .
.    |   C O N F E R E N C E   O B J E C T   | | |     .
.    |                                       | |-+     .
.    |                                       |-+       .
.    +---------------------------------------+         .
.                        ^                             .
.                        |                             .
.                        v                             .
.               +-------------------+                  .
.               | Conference Control|                  .
.               | Server            |                  .
.               +-------------------+                  .
.                        ^                             .
.........................|..............................
                          |
                          |Centralized
                          |Conferencing
                          |Manipulation
                          |Protocol
                          |
.........................|..............................
.                        V                             .
.                +----------------+                    .
.                | Conference     |                    .
.                | Control        |                    .
.                | Client         |                    .
.                +----------------+                    .
.                                                      .
.  Conferencing Client                                 .
........................................................

              Figure 1: Conferencing Client Interaction

The Centralized Conferencing Manipulation Protocol (CCMP) lets the conference control client (conferencing client) talk to the conference object that the conferencing system keeps, as shown in Figure 1 🎀 Extra stuff the conferencing client and conferencing system can do is covered in the XCON framework and related documents, so go check those out too 📚

This section spills the tea on the identifiers that are REQUIRED to address and manage the clients tied to a conferencing system using CCMP 🔥

3.1. Conference Objects

Conference objects have a super simple dynamic inheritance-and-override vibe 🌸 They get linked into a tree called a "cloning tree" (see Section 7.1 of [RFC5239]). Every node in that tree inherits attributes from its parent node. The roots of these trees are conference templates, also known as "blueprints" 📋 Nodes in the inheritance tree can be active conferences, or just descriptions that don't have any resources attached yet (i.e., conference reservations) ✨ An object can mark some of its properties as unalterable, so they can't be overridden, which is so iconic 💅 Per the framework, a client can name a parent object (a conference or blueprint) to inherit values from when it creates a conference using the conference control protocol 🦋

Conference objects get a unique identifier, the XCON-URI, within the scope of the conferencing system. The XCON-URI is introduced in the XCON framework and defined in the XCON common data model 🔗

Conference objects are fully represented through XML documents that follow the XML schema from the XCON data model [RFC6501] 💜 The root element of those documents, called <conference-info>, is of type "conference-type". It holds other XML elements that describe the different conference features and users too 🧚 With CCMP, conferencing clients can use these XML structures to say what they want when they create or update a conference, and a conference server can send conference information back to the clients using those same XML elements 💖

3.2. Conference Users

Each conference can have zero or more users 🌈 All conference participants are users, but some users might only have administrative functions and don't send or receive media 🙈 Users get added one at a time to make error reporting easier 🍓 When a conference is cloned from a parent object, its users get inherited as well, so setting up a conference with the same crew or the same admin is super easy 🫶 The conference server creates individual users and gives each one a unique conference user identifier (XCON-USERID). The XCON-USERID, which identifies each conferencing system client, is introduced in the XCON framework and defined in the XCON common data model ✨ Every CCMP request must carry the XCON-USERID of the requestor in the proper <confUserID> parameter, except for the one case called out in Section 5.3.6, where a user is making their very first entrance into the system as a conference participant 🦋

The XCON-USERID points to the user's profile as a conference actor, like their signaling URI and other XCON protocol URIs in general, their role (moderator, participant, observer, etc.), their display text, their joining information, and more 👑 The XCON data model describes users using a bunch of elements in the common <conference-info> element, including the <users> element and each <user> element inside it 💅 For example, you can figure out how a specific user is expected and allowed to join a conference by checking the <allowed-users-list> in <users>. Each <target> element in that list represents a user and has a 'method' attribute that says how the user is expected to join: "dial-in" for users who are allowed to dial in, and "dial-out" for users the conference focus will be trying to reach (with "dial-in" being the default mode) 📞 If the conference is currently active, dial-out users get contacted right away; otherwise they get contacted when the conference starts 🎉 CCMP, as the conference control protocol, gives you a way to manipulate these and other kinds of user-related features 🌸

Here's the lowkey important part 👀 Once a user registers with a specific XCON conferencing system, conferencing clients usually get log-in credentials (a username and password) on top of the XCON-USERID 🔐 Those credentials can be used to authenticate the XCON-aware client sending CCMP requests. So both username and password should be carried in a CCMP request as part of the "subject" parameter whenever a registered conferencing client wants to contact a CCMP server 🫶 CCMP doesn't keep track of a user's subscriptions at the conference server, so it doesn't offer any specific mechanism for clients to register their conferencing accounts 🙅‍♀️ The "subject" parameter is just for carrying authentication data tied to pre-registered clients, and how that registration happens is outside the scope of this document 📝

4. Protocol Overview

CCMP is a client-server, XML-based protocol for creating, retrieving, modifying, and deleting conference objects 🎀 It's stateless, which means implementations can handle transactions totally independently from each other 🦋 CCMP messages are XML documents or XML document fragments that follow the XCON data model representation [RFC6501] 💜

Section 4.1 lays out the basic operations that can create, retrieve, modify, and delete conference-related information in a centralized conference ✨ The core set of objects CCMP works with includes conference blueprints, the conference object, users, and sidebars 🍓

Each operation in the protocol model, which is summarized in Section 4.1, is atomic: it either succeeds or fails as a whole 💥 The conference server MUST ensure that operations are atomic, meaning the operation invoked by one conferencing client finishes before another client's operation on the same conference object can happen 🔒 The details of this data locking are out of scope for the CCMP specification and are implementation specific for a conference server 🙈 Some core functionality for keeping the data intact is still provided by CCMP, as described in Section 4.2 🛡️

The XML documents carried in CCMP need to comply with the XCON data model, but sometimes the client doesn't know the values for mandatory elements 🤔 The mechanism for keeping things compliant with the data model in those cases is described in Section 4.3 🌈

CCMP is completely independent of underlying protocols, so there can be different ways to carry CCMP messages from a conferencing client to a conference server 🧚 This spec describes using HTTP as the transport, with CCMP requests going in HTTP POST messages and CCMP responses coming back in HTTP 200 OK replies 💌 That approach is further described in Section 4.4 💅

4.1. Protocol Operations

The main operations CCMP provides fall into four general categories 👑

create: for making a conference object, a conference user, a sidebar, or a blueprint ✨
retrieve: for getting info about the current state of either a conference object (whether that's an actual conference, a blueprint, or a sidebar) or a conference user. A retrieve operation can also be used to get the XCON-URIs of the current conferences (active or registered) handled by the conferencing server and/or the available blueprints 🔍
update: for modifying the current features of a specified conference or conference user 🎀
delete: for removing a conference object or a conference user from the system 🗑️

So the main targets of CCMP operations are:

conference objects associated with either active or registered conferences,
conference objects associated with blueprints,
conference objects associated with sidebars, both embedded in the main conference (i.e., <entry> elements in <sidebars-by-value>) and external to it (i.e., whose XCON-URIs are included in the <entry> elements of <sidebars-by-ref>),
<user> elements associated with conference users, and
the list of XCON-URIs related to conferences and blueprints available at the server, for which only retrieval operations are allowed 📜

4.2. Data Management ✨

okay bestie, so the XCON framework has the conference server be the one central place that stores and maintains all the conference info 🏠. The problem is that lots of clients can edit the same conference objects, so a client might be working off an old copy when it sends an operation 😬. To check whether a client is up to date, CCMP uses versioning 🔢. Every conference object gets a version number. Any CCMP response that carries a conference document (or a piece of one) MUST contain a <version> parameter 💅. When a client sends an update that changes a conference object and every change is applied successfully, the server MUST return a response with a <response-code> of "200" that includes the version number of the modified object 🎉.

Here's the iykyk part. If a client was working on version "X" and gets back a "200" response with version "X+1", it can be certain it was already working on the newest version 🙌. But if the version is at least "X+2", the server's modified object was newer than the one the client was touching, so the client knows it was behind 😭. To make sure the client always has the latest copy, it can ask the conference server to retrieve the conference object 📥. Then it can update the relevant data elements before running a specific operation ✨. Also, a client that's subscribed to the XCON event package [RFC6502] gets notified about changes to conference objects, so it receives the most up-to-date version of the object as soon as the notification comes in 🔔.

The "version" parameter is OPTIONAL for requests, and that's because the server doesn't actually need it 🤷‍♀️. As long as the changes can go into the target conference object with no conflicts, the server doesn't care whether the client has an up-to-date view of things 💁‍♀️. Also, for data integrity, the conference server checks all the parameters first, before it changes anything inside the conference object 🛡️. Like, it would be totally messy to change the <subject> of the conference, then find an invalid URI in one of the <service-uris> and stop the remaining updates 💀.

4.3. Data Model Compliance 🎀

The XCON data model [RFC6501] says some elements and attributes are mandatory 📋. The XML documents inside CCMP requests and responses have to follow the XCON data model, so there's a problem when clients start operations themselves, like creating a brand new conference object or adding a new element such as a new user 😩. In those cases the client can't know all the mandatory data ahead of time. For example, when a client sends a conference creation request, it has no idea what XCON-URI the server is going to assign to the new conference, so it can't fill in the mandatory entity attribute of the conference document with the right value 🫠.

Here's the fix 🪄. The CCMP client fills every mandatory data model field that it doesn't have a value for, at the time it builds the request, with a placeholder wildcard string: AUTO_GENERATE_X (all uppercase), where X is a unique numeric index for each field whose value is unknown 🔤. The wildcard is built this way, instead of using random unique strings (like FOO_BAR_LA) or non-numeric values for X, to keep things simple for the server to process 🧠. The AUTO_GENERATE_X values are only unique within the context of that one specific request 📌. The placeholder AUTO_GENERATE_X values MUST be within the value part of an attribute or element, for example <userinfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> 💖.

When the server gets a request with values in the AUTO_GENERATE_X form, it does the following 👀:

(a) It generates the proper identifier for each instance of AUTO_GENERATE_X in the document. If an instance of AUTO_GENERATE_X is not within the value part of the attribute or element, the server MUST send a <response-code> of "400 Bad Request". If AUTO_GENERATE_X only shows up in the user part of a URI (so, in the case of XCON-USERIDs or XCON-URIs), the server needs to check that the domain name is one within its own domain of responsibility 🌐. If the domain name is not within the server's domain of responsibility, the server MUST send a <response-code> of "427 Invalid Domain Name" 🚫. The server MUST replace each instance of a specific wildcard field (for example AUTO_GENERATE_1) with the same identifier 🔁. The identifiers MUST be unique for each instance of AUTO_GENERATE_X within the same XML document received in the request. For example, the value that replaces AUTO_GENERATE_1 MUST NOT be the same as the value that replaces AUTO_GENERATE_2 🙅‍♀️. Also, the values that replace the AUTO_GENERATE_X instances are not the same across all conference objects. For example, different values can replace AUTO_GENERATE_1 in two different documents 🔄.
(b) It sends a response in which all the AUTO_GENERATE_X values received in the request have been replaced by the newly created ones 📨.

So with this approach, the data model requirements stay happy 😌, and the client can still start changes to conference objects on the server's side 🎉. The mechanism could be skipped in some cases by using multiple operations instead, like creating a new user and then adding that user to an existing conference 🔀. But the AUTO_GENERATE_X mechanism lets one single operation make the same change to the conference object 🦋.

4.4. Implementation Approach 🌸

CCMP is implemented over HTTP 🌐. The CCMP request messages go into the body of an HTTP POST operation, and the CCMP responses go into the body of the HTTP response messages 📦. There's a non-exhaustive summary of the other approaches that were considered, plus the perceived advantages of the HTTP solution this document describes, in Appendix A 📖.

Most CCMP commands can pend indefinitely 😵. That means pending requests can keep piling up when a server gets more requests than it can process in a given time period 📈. In this case, a server SHOULD return a <response-code> of "510" to the pending requests 🙏. To help with this, clients MUST NOT wait indefinitely for a response. They MUST implement a timer, and when it expires, the client MUST close the connection ⏰. Thirty seconds is RECOMMENDED as the default value for this timer ⭐. Sixty seconds is considered a reasonable upper range 🎀. Heads up, there can be cases where a response message gets lost even though the request succeeded (like a user getting added to a conference) 😬. The client won't know and will close the connection anyway. But remember from Section 4.2 that there's a versioning mechanism for conference objects, so the client has a way to bring its stored conference object back up to date 🔄✨.

CCMP messages have a MIME type of application/ccmp+xml, which shows up inside the Content-Type and Accept header fields of HTTP requests and responses 🏷️. The XML documents in the CCMP messages MUST be encoded in UTF-8 💜. This specification follows the recommendations and conventions in [RFC3023], including the naming convention of the type (the +xml suffix) and the use of the charset parameter 📚. The charset parameter MUST be included with the XML document 💅. Section 9 has the complete requirements for an HTTP implementation to support CCMP 🧚.

5. CCMP Messages 💌

CCMP messages are either requests or responses 🎀. The general CCMP request message is defined in Section 5.1. The general CCMP response message is defined in Section 5.2. The details of the specific message type carried in the CCMP request and response messages are described in Section 5.3. And the CCMP response codes are listed in Section 5.4 🌈.

5.1. CCMP Request Message Type ✨

okay so a CCMP request message is basically a bundle of parameters, and we're going through them one by one bestie 💅

subject: OPTIONAL 💖 This is the username and password of the client registered at the conferencing system. Every user who subscribes is assumed to have those credentials, and they SHOULD enclose them in each CCMP request they send. These fields can be used to check that the person sending the request is actually allowed to do the thing, and the same fields can also be used for other authorization and authentication procedures 🔐
confUserID: OPTIONAL 🎀 This is the XCON-USERID of the client. The XCON-USERID is how any conferencing client gets identified inside the conferencing system, and the conference server assigns one to each client who interacts with it. The <confUserID> parameter is REQUIRED in the CCMP request and response messages, except for a user who has no XCON-USERID and wants to enter a conference via CCMP whose identifier is already known. In that case, a side effect of the request is that the user gets an appropriate XCON-USERID ✨ An example of this case is in Section 5.3.6.
confObjID: OPTIONAL 🦋 This is the XCON-URI of the target conference object.
operation: OPTIONAL 🧚 This refines the type of specialized request message. The <operation> parameter is REQUIRED in all requests except the blueprintsRequest and confsRequest specialized messages 🌸
conference-password: OPTIONAL, except it MUST be inserted in every request whose target conference object is password-protected 🔒 (that is, the one that contains the <conference-password> element in [RFC6501]). If a conference-password is needed but not included, the server MUST return a CCMP <response-code> of "423" 😭
specialized request message: This is a specialization of the generic request message (like blueprintsRequest), with parameters that depend on the specific request sent to the server. A specialized request message MUST be included in the CCMP request message. You can find all the details for the specialized messages and their parameters in Section 5.3 🍓

<!-- Definition of CCMP Request -->

<xs:element name="ccmpRequest" type="ccmp-request-type" />

<!-- Definition of ccmp-request-type-->

<xs:complexType name="ccmp-request-type">
    <xs:sequence>
        <xs:element name="ccmpRequest"
                    type="ccmp-request-message-type" />
    </xs:sequence>
</xs:complexType>

 <!--  Definition of ccmp-request-message-type -->

 <xs:complexType abstract="true"
                 name="ccmp-request-message-type">
     <xs:sequence>
         <xs:element name="subject" type="subject-type"
                     minOccurs="0" maxOccurs="1" />
         <xs:element name="confUserID" type="xs:string"
                     minOccurs="0" maxOccurs="1" />
         <xs:element name="confObjID" type="xs:string"
                     minOccurs="0" maxOccurs="1" />
         <xs:element name="operation" type="operationType"
                     minOccurs="0" maxOccurs="1" />
         <xs:element name="conference-password" type="xs:string"
                     minOccurs="0" maxOccurs="1" />
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 2: Structure of CCMP Request Messages 🧩

5.2. CCMP Response Message Type 🌈

a CCMP response message is also a bundle of parameters, just the reply side of the convo 💬

confUserID: REQUIRED 🫶 This is the XCON-USERID of the conferencing client that issued the CCMP request message.
confObjID: OPTIONAL 🦋 This is the XCON-URI of the target conference object.
operation: OPTIONAL 🧚 This is an OPTIONAL parameter in CCMP response messages. It is REQUIRED in all responses except the "blueprintsResponse" and "confsResponse" specialized messages 🌸
response-code: REQUIRED 👑 This holds the response code associated with the request. The response code MUST be chosen from the codes listed in Section 5.4 💅
response-string: OPTIONAL 💖 This is a reason string for the response. If something went wrong, this is where the server can give the client detailed info about the error itself 🙈
version: OPTIONAL ⭐ This reflects the current version number of the conference object referred to by the confObjID. The number lives in the 'version' attribute of the <conference-info> element for that conference. This parameter is REQUIRED in CCMP response messages and SHOULD NOT be included in CCMP request messages 🔥
specialized response message: This is a specialization of the generic response message, with parameters that depend on the specific request sent to the server (like "blueprintsResponse"). A specialized response message SHOULD be included in the CCMP response message, except in an error situation where the CCMP request message didn't contain a valid specialized message. In that case, the conference server MUST return a <response-code> of "400" 💀 The details for the specialized messages and their parameters are in Section 5.3 🦋

<!-- Definition of CCMP Response -->

<xs:element name="ccmpResponse" type="ccmp-response-type" />

<!-- Definition of ccmp-response-type -->

<xs:complexType name="ccmp-response-type">
    <xs:sequence>
        <xs:element name="ccmpResponse"
                    type="ccmp-response-message-type" />
    </xs:sequence>
</xs:complexType>

<!--  Definition of ccmp-response-message-type -->

<xs:complexType abstract="true"
                name="ccmp-response-message-type">
    <xs:sequence>
        <xs:element name="confUserID" type="xs:string"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="confObjID" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="operation" minOccurs="0"
                    maxOccurs="1" />
        <xs:element name="response-code"
                    type="response-codeType"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="response-string" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="version" type="xs:positiveInteger"
                    minOccurs="0" maxOccurs="1" />
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 3: Structure of CCMP Response Message ✨

5.3. Detailed Messages ✨

okay so, building on the request and response structures from Sections 5.1 and 5.2, here's the full lineup of the specialized CCMP request/response pairs in this doc 💖

blueprintsRequest/blueprintsResponse
confsRequest/confsResponse
blueprintRequest/blueprintResponse
confRequest/confResponse
usersRequest/usersResponse
userRequest/userResponse
sidebarsByValRequest/sidebarsByValResponse
sidebarsByRefRequest/sidebarsByRefResponse
sidebarByValRequest/sidebarByValResponse
sidebarByRefRequest/sidebarByRefResponse
extendedRequest/extendedResponse
optionsRequest/optionsResponse

these pairs all use the fundamental CCMP operations from Section 4.1 to manipulate the conference data, and they're included in an IANA registry (Section 12.5) 🧚

now, Table 1 is basically your cheat sheet for the remaining operations and which ones are valid for each request type 💅 neither blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse need an <operation> parameter. an entity MUST support the response message for each request message it supports, and the corresponding response message MUST contain the same <operation> parameter 🫶 "N/A" means the operation is invalid for that request type. an "N/A*" means the operation MAY be allowed for specific privileged users or system administrators, but it's not part of the functionality in this document 🙈

+---------------+------------+------------+------------+------------+
| Operation     |  Retrieve  |   Create   |   Update   |   Delete   |
| ------------- |            |            |            |            |
| Request Type  |            |            |            |            |
+---------------+------------+------------+------------+------------+
| blueprints    |  Get list  |     N/A    |     N/A    |     N/A    |
| Request       |     of     |            |            |            |
|               | blueprints |            |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprint     |     Get    |    N/A*    |    N/A*    |    N/A*    |
| Request       |  blueprint |            |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest  |  Get list  |     N/A    |     N/A    |     N/A    |
|               |  of confs  |            |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confRequest   |     Get    |   Create   |   Change   |   Delete   |
|               | conference | conference | conference | conference |
|               |   object   |   object   |   object   |   object   |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest  |     Get    |   N/A(**)  |   Change   |   N/A(**)  |
|               |   <users>  |            |   <users>  |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest   |     Get    |    Add a   |   Change   |   Delete   |
|               |  specified |  <user> to |  specified |  specified |
|               |   <user>   |   a conf   |   <user>   |   <user>   |
|               |            |    (***)   |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByVal |     Get    |     N/A    |     N/A    |     N/A    |
| Request       | <sidebars- |            |            |            |
|               |   by-val>  |            |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByRef |     Get    |     N/A    |     N/A    |     N/A    |
| Request       | <sidebars- |            |            |            |
|               |   by-ref>  |            |            |            |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByValR |     Get    |   Create   |   Change   |   Delete   |
| equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
|               |   by-val   |   by-val   |   by-val   |   by-val   |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByRefR |     Get    |   Create   |   Change   |   Delete   |
| equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
|               |   by-ref   |   by-ref   |   by-ref   |   by-ref   |
+---------------+------------+------------+------------+------------+

Table 1: Request Type Operation-Specific Processing

(**): these operations are not allowed for a usersRequest message 😭 the <users> section is the target element of that request, and it gets created and removed along with the creation and deletion of the associated conference document. so "update" and "retrieve" are the only semantically correct operations here 💜

(***): this operation can involve creating an XCON-USERID, if the sender doesn't add it in the <confUserID> parameter and/or if the entity field of the <userInfo> parameter is void ✨

other parameters for the specialized CCMP request and response messages are covered in the sections that follow. if a required parameter is missing from a request, the conference server MUST return a <response-code> of "400" per Section 5.4 🚨

5.3.1. blueprintsRequest and blueprintsResponse

a blueprintsRequest (Figure 4) message is how a client asks the conference server for the list of XCON-URIs tied to the available blueprints 🎀 those XCON-URIs can then be used to get detailed info about a specific blueprint with a blueprintRequest message (Section 5.3.3) 🦋

the <confUserID> parameter MUST be included in every blueprintsRequest/Response message, and it reflects the XCON-USERID of the conferencing client that issued the request 🫶 since a blueprintsRequest message isn't aimed at a specific conference instance and is a "retrieve-only" request, the <confObjID> and <operation> parameters MUST NOT be included in the blueprintsRequest/Response messages 🙅‍♀️

to get a specific subset of the available blueprints, a client can pass along a selection filter with an appropriate xpath query in the OPTIONAL "xpathFilter" parameter of the request 🔍 the info in the blueprints usually covers general capabilities and characteristics. for example, to select blueprints that have both audio and video stream support, a possible xpathFilter value could be:

/conference-info[conference-description/available-media/entry/type='audio' and conference-description/available-media/entry/type='video']

and a conference server SHOULD NOT provide any sensitive information (e.g., passwords) in the blueprints 🔒

the associated blueprintsResponse message SHOULD contain, as shown in Figure 4, a "blueprintsInfo" parameter containing the XCON-URI list we just talked about 🌈

 <!-- blueprintsRequest -->
 <xs:complexType name="ccmp-blueprints-request-message-type">
     <xs:complexContent>
         <xs:extension base="tns:ccmp-request-message-type">
             <xs:sequence>
                 <xs:element ref="blueprintsRequest" />
             </xs:sequence>
         </xs:extension>
     </xs:complexContent>
 </xs:complexType>

 <!-- blueprintsRequestType -->

 <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>

 <xs:complexType name="blueprintsRequestType">
     <xs:sequence>
         <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
 </xs:complexType>

 <!-- blueprintsResponse -->

 <xs:complexType name="ccmp-blueprints-response-message-type">
     <xs:complexContent>
         <xs:extension base="tns:ccmp-response-message-type">
             <xs:sequence>
                 <xs:element ref="blueprintsResponse" />
             </xs:sequence>
         </xs:extension>
     </xs:complexContent>
 </xs:complexType>
 <!-- blueprintsResponseType -->

 <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>

 <xs:complexType name="blueprintsResponseType">
     <xs:sequence>
         <xs:element name="blueprintsInfo"
                     type="info:uris-type" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
 </xs:complexType>

Figure 4: Structure of the blueprintsRequest and blueprintsResponse Messages

5.3.2. confsRequest and confsResponse ✨

okay so a confsRequest is how a client asks the server for the list of XCON-URIs for the active and registered conferences the system is handling right now 📋🎀 the <confUserID> parameter MUST be in every confsRequest/Response message, and it has to match the XCON-USERID of whoever sent the request 🫶 the <confObjID> parameter MUST NOT show up in a confsRequest 🙈 this message is retrieve-only, because all it does is pull info off the conference server, so an <operation> parameter MUST NOT be in there either 💅 if you only want a slice of the conferences, you can add an OPTIONAL "xpathFilter" parameter with an xpath query. for example, to get only the registered conferences, you could use "/ conference-info[conference-description/conference-state/ active='false']" 🦋 the matching confsResponse SHOULD carry the XCON-URIs in the "confsInfo" parameter, and then the user can poke at those conference objects with more CCMP messages. main character energy 👑

<!-- confsRequest -->

<xs:complexType name="ccmp-confs-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="confsRequest" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- confsRequestType -->

<xs:element name="confsRequest" type="confsRequestType" />

<xs:complexType name="confsRequestType">
    <xs:sequence>
        <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- confsResponse -->

<xs:complexType name="ccmp-confs-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="confsResponse" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- confsResponseType -->

<xs:element name="confsResponse" type="confsResponseType"/>

<xs:complexType name="confsResponseType">
    <xs:sequence>
        <xs:element name="confsInfo" type="info:uris-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 5: Structure of the confsRequest and confsResponse Messages

5.3.3. blueprintRequest and blueprintResponse ✨

with a blueprintRequest, a client can mess with the conference object linked to a specific blueprint 🎨 along with <confUserID>, the request MUST include the <confObjID> and <operation> parameters. again, <confUserID> MUST be in every blueprintRequest/Response message and match the XCON-USERID of the client sending it 🫶 the <confObjID> parameter MUST contain the XCON-URI of the blueprint, which you might already have grabbed from a blueprintsRequest message 🔍

the blueprintRequest SHOULD NOT carry an <operation> parameter with any value other than "retrieve" 🙅‍♀️ an <operation> of "create", "update", or "delete" SHOULD NOT be in a blueprintRequest either, unless it's a privileged user (like the conference server admin staff) who proves who they are with the "subject" request parameter 🔐

⚠️ if a blueprintRequest/retrieve has a <confObjID> that doesn't match any of the system's blueprints, the server will send back a blueprintResponse with a <response-code> of "404" 💀 same deal if that <confObjID> points to a conference document on the server that's tied to an actual conference (active or registered) or to a sidebar instead of a blueprint 🙈

for a <response-code> of "200" in a "retrieve" operation, the <blueprintInfo> parameter MUST be in the blueprintResponse 🎀 it holds the conference document for the blueprint named by the <confObjID> in the blueprintRequest 🌸

<!--  blueprintRequest -->

<xs:complexType name="ccmp-blueprint-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="blueprintRequest" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- blueprintRequestType -->

<xs:element name="blueprintRequest" type="blueprintRequestType" />

<xs:complexType name="blueprintRequestType">
    <xs:sequence>
        <xs:element name="blueprintInfo"
                    type="info:conference-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- blueprintResponse -->

<xs:complexType name="ccmp-blueprint-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="blueprintResponse" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->

<xs:element name="blueprintResponse" type="blueprintResponseType"/>

<xs:complexType name="blueprintResponseType">
    <xs:sequence>
        <xs:element name="blueprintInfo" type="info:conference-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded">
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 6: Structure of the blueprintRequest and blueprintResponse Messages

5.3.4. confRequest and confResponse ✨

Okay bestie, confRequest is where CCMP clients get to glam up conference objects 💅, whether those conferences are active or registered. The <confUserID> parameter MUST be included in every confRequest/Response message, and it has to reflect the XCON-USERID of the conferencing client sending the request 🫶. confRequest and confResponse messages MUST also include an <operation> parameter. ConfResponse messages MUST return a <response-code> to the requestor, and they MAY contain a <response-string> explaining it. Depending on the operation, a <confObjID> and <confInfo> parameter MAY be included in the confRequest and response. The text below spells out, for each operation, whether those parameters need to show up 🍓.

The creation case is giving main character energy, so pay attention 👑. There are two ways to create a new conference through a confRequest:

Creation through explicit cloning: the <confObjID> parameter MUST contain the XCON-URI of the blueprint or of the conference to be cloned, while the <confInfo> parameter MUST NOT be included in the confRequest. Note that cloning of an active conference is only done in the case of a sidebar operation per the XCON framework and as described in Section 5.3.8.
Creation through implicit cloning (also known as "direct creation"): the <confObjID> parameter MUST NOT be included in the request, and the CCMP client can describe the desired conference to be created using the <confInfo> parameter. If no <confInfo> parameter is provided in the request, the new conference will be created as a clone of the system default blueprint.

In both creation cases, the confResponse for a successful "create" operation contains a <response-code> of "200" and MUST contain the XCON-URI of the newly created conference in the <confObjID> parameter 🌸. That's how the conferencing client gets to keep manipulating that conference through later CCMP requests. The <confInfo> parameter containing the conference document that was created MAY be included, at the discretion of the conferencing system implementation, along with the REQUIRED <version> parameter initialized at "1". That makes sense, because at creation time the conference object is at its very first version 🦋.

For a confRequest with an <operation> parameter of "retrieve", the <confObjID> parameter representing the XCON-URI of the target conference MUST be included, and the <confInfo> parameter MUST NOT be included in the request. The conference server MUST ignore any <confInfo> parameter received in a confRequest "retrieve" operation 🙈. If the confResponse for the retrieve operation contains a <response-code> of "200", the <confInfo> parameter MUST be included in the response. The <confInfo> parameter MUST contain the entire conference document describing the target conference object in its current state. The current state of the retrieved conference object MUST also be reported in the proper "version" response parameter 🔥.

For a confRequest with an <operation> parameter of "update", the <confInfo> and <confObjID> parameters MUST be included in the request. The <confInfo> represents an object of type "conference-type" containing all the changes to be applied to the conference whose identifier has the same value as the <confObjID> parameter. Here's the tea: even though the <confInfo> parameter has to follow the rules in the XCON data model, it does not represent the entire updated version of the target conference. It only conveys the modifications to apply 💅. For example, to change the conference title, the <confInfo> parameter looks like this:

<confInfo entity="xcon:8977777@example.com">
  <conference-description>
    <display-text> *** NEW CONFERENCE TITLE *** </display-text>
  </conference-description>
</confInfo>

Figure 7: Updating a Conference Object: Modifying the Title of a Conference

And if you want to remove the title of an existing conference, a confRequest/update carrying the following <confInfo> parameter does the trick 🧚.

<confInfo entity="xcon:8977777@example.com">
  <conference-description>
    <display-text/>
  </conference-description>
</confInfo>

Figure 8: Updating a Conference Object: Removing the Title of a Conference

For a confResponse/update with a <response-code> of "200", no additional information is REQUIRED in the response message, which means that returning a <confInfo> parameter is OPTIONAL 💜. A later confRequest/retrieve transaction might give the CCMP client the current status of the conference after the change, or the notification protocol might handle that job too. A <response-code> of "200" means the conference server has changed the conference object according to the request. The <version> parameter MUST be enclosed in the confResponse/update message, so the client knows the current conference-object version after the changes were applied ✨. A <response-code> of "409" means the changes in the <confInfo> parameter of the request are not feasible. That could be because of policies, requestor roles, specific privileges, unacceptable values, and so on, and the exact reason depends on the conferencing system and its configuration 🙅‍♀️. Together with a <response-code> of "409", the <version> parameter MUST be attached in the confResponse/update. That lets the client retrieve the current version of the target conference later, in case the one it tried to modify wasn't the most up to date 🫠.

For a confRequest with an <operation> parameter of "delete", the <confObjID> parameter representing the XCON-URI of the target conference MUST be included, while the <confInfo> parameter MUST NOT be included in the request. The conference server MUST ignore any <confInfo> parameter received within such a request. The confResponse MUST contain the same value for the <confObjID> parameter that was included in the confRequest 🎀. If the confResponse/delete contains a <response-code> of "200", the conference indicated in the <confObjID> parameter has been successfully deleted. A confResponse/delete with a <response-code> of "200" MUST NOT contain the <confInfo> parameter. The <version> parameter SHOULD NOT be returned in any confResponse/delete. If the conference server cannot delete the conference referenced by the <confObjID> parameter received in the confRequest, because it is the parent of another conference object that is in use, the conference server MUST return a <response-code> of "425" 💀.

A confRequest with an <operation> parameter of "retrieve", "update", or "delete" that carries a <confObjID> parameter not associated with any of the conferences (active or registered) the system is holding will generate, on the server's side, a confResponse message containing a <response-code> of "404" 🥲. The same goes when the <confObjID> parameter points to an existing conference object stored at the server but associated with a blueprint or a sidebar rather than an actual conference.

The schema for the confRequest/confResponse pair is shown in Figure 9 🌈.

<!-- confRequest -->

<xs:complexType name="ccmp-conf-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="confRequest" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- confRequestType -->

<xs:element name="confRequest" type="confRequestType" />

<xs:complexType name="confRequestType">
    <xs:sequence>
        <xs:element name="confInfo" type="info:conference-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponse -->

<xs:complexType name="ccmp-conf-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="confResponse" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- confResponseType -->

<xs:element name="confResponse" type="confResponseType" />

<xs:complexType name="confResponseType">
    <xs:sequence>
        <xs:element name="confInfo" type="info:conference-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 9: Structure of the confRequest and confResponse Messages

5.3.5. usersRequest and usersResponse ✨

okay bestie, this is the users drama 💅 usersRequest lets a client mess with the <users> element of the conference object picked out by <confObjID> 🎀 That element holds the list of <user> elements for conference participants, the users who get access allowed or denied, conference participation policies, and more 🫶 The <confObjID> parameter MUST be included in a usersRequest message, no exceptions 😭

A <usersInfo> parameter MAY be included in a usersRequest message, depending on the operation 🦋 If you do include it, it MUST be compliant with the <users> field of the XCON data model. Main character energy means following the data model 👑

There are two operations allowed for a usersRequest message 🌈

"retrieve": this one is the chill read 🍓 The request MUST NOT include a <usersInfo> parameter, and the successful response MUST contain the desired <users> element in its <usersInfo> parameter. The conference server MUST ignore a <usersInfo> parameter if it shows up in a request whose <operation> parameter is "retrieve" 💀
"update": here the <usersInfo> parameter MUST contain the modifications to be applied to the indicated <users> element ✏️ If the <response-code> is "200", the <usersInfo> parameter SHOULD NOT be returned, and any <usersInfo> that does come back SHOULD be ignored. A <response-code> of "426" means the conferencing client isn't allowed to make the changes in the <usersInfo> of the usersRequest 🙈 That could be because of policies, roles, specific privileges, etc., and the exact reason depends on the conferencing system and how it's configured.

"create" and "delete" are not it, bestie 🙅 They aren't applicable to a usersRequest message, so the server MUST NOT consider them, and a <response-code> of "403" MUST be included in the usersResponse message. Wild, but that's the rule 😤

Here's the full structure, figure 10 style 📜

<!-- usersRequest -->

<xs:complexType name="ccmp-users-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="usersRequest" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- usersRequestType -->

<xs:element name="usersRequest" type="usersRequestType" />

<xs:complexType name="usersRequestType">
    <xs:sequence>
        <xs:element name="usersInfo"
                    type="info:users-type" minOccurs="0" />
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse -->

<xs:complexType name="ccmp-users-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="usersResponse" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- usersResponseType -->

<xs:element name="usersResponse" type="usersResponseType" />

<xs:complexType name="usersResponseType">
    <xs:sequence>
        <xs:element name="usersInfo" type="info:users-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 10: Structure of the usersRequest and usersResponse Messages 🧚

5.3.6. userRequest and userResponse ✨

okay bestie, so a userRequest is the message for poking at <user> elements inside a conference document 💖. The <confObjID> param tells you which conference you mean. You can look up a specific user, or ask the conference server to create, modify, or delete user info 🫶. Every userRequest MUST include the <confObjID> and <operation> params 🎀. It MAY also carry a <userInfo> param with the juicy details, depending on the operation and on whether that user's <userInfo> is already filled in 🌸. And ngl, not everyone in a conference is a conferencing control client. Some participants are just not "XCON aware" 🙈

Every subscribed user SHOULD get an XCON-USERID ✨. That way, even someone who isn't a conference participant yet can make requests (as long as they pass the authorization and authentication checks 🔐), like creating a conference or retrieving conference info 💅.

Conference users can be created in a few different ways 🧚. In every one of these cases, the <operation> param MUST be set to "create" in the userRequest. Each userResponse for these cases MUST include the <confObjID>, <confUserID>, <operation>, and <response-code> params 💜. When the <response-code> is "200", the userResponse MAY include the <userInfo> param, depending on how the user was created:

A conferencing client with an XCON-USERID adds itself to the conference 🦋: The <userInfo> param MAY be included in the userRequest. It MUST contain a <user> element (compliant with the XCON data model), and the 'entity' attribute MUST be set to the XCON-USERID of the user making the request. Nothing else is needed in the userResponse when the <response-code> is "200".
A conferencing client acts on behalf of another user whose XCON-USERID is known 👑: Here the <userInfo> param MUST be included in the userRequest. It MUST contain a <user> element, and the 'entity' attribute value MUST be set to the XCON-USERID of the other user. Nothing else is needed in the userResponse when the <response-code> is "200".
A conferencing client with no XCON-USERID wants to join a conference via CCMP, and it knows the conference identifier 🌈: Here, a side effect of the request is that the user gets a brand new XCON-USERID, created by the server and carried in the <confUserID> param of the response. This is the only case where a CCMP request can be valid while carrying a void <confUserID> param 😭. A <userInfo> param MUST be enclosed in the request, providing at least a contact URI for the joining client, so the focus can start the signaling phase needed to add her to the conference. The mandatory 'entity' attribute of the request's <userInfo> param MUST be filled with a placeholder value. Its user part contains AUTO_GENERATE_X, as described in Section 4.3, so it follows the rules of the XCON data model XML schema. The messages (userRequest and userResponse) in this case should look like this:

Request fields:

confUserID=null;
confObjID=confXYZ;
operation=create;
userInfo=

<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
        <endpoint entity="sip:GHIL345@example.com">
        ...


Response fields (in case of success):

confUserID=user345;
confObjID=confXYZ;
operation=create;
response-code=200;
userInfo=null; //or the entire userInfo object

             Figure 11: userRequest and userResponse in the
                       Absence of an xcon-userid

A conferencing client doesn't know the XCON-USERID of a third user 🧚‍♀️: In this case, the <confUserID> in the request is the sender's own XCON-USERID. The 'entity' attribute of the attached <userInfo> param is filled with the placeholder value "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for the third user MUST be returned to the client that issued the request, in the 'entity' attribute of the response's <userInfo> param, if the <response-code> is "200". This scenario is meant to cover two situations: a brand new conferencing system user being added to a conference by a third party (someone who doesn't have an XCON-USERID yet), and a CCMP client that doesn't know the to-be-added user's XCON-USERID, even though one might already exist on the server for that user. In that last case, the conference server is in charge of avoiding XCON-URI duplicates for the same conferencing client. It does this by looking at key fields in the <userInfo> param of the request, like the signaling URI 🔍. If the joining user is brand new, a new XCON-USERID has to be generated. Otherwise, if the user already exists, the server must recover the corresponding XCON-USERID.

For a userRequest with an <operation> param of "retrieve" 🔎, the <confObjID> param (the XCON-URI of the target conference) MUST be included. The <confUserID> param, holding the CCMP client's XCON-USERID, MUST also be included in the userRequest. If the client wants to see her own profile in that conference, no <userInfo> param is needed. But if she wants someone else's info in the conference, she MUST include a <userInfo> param in the userRequest/retrieve whose 'entity' attribute conveys that user's XCON-USERID. If the userResponse for the retrieve operation has a <response-code> of "200", the <userInfo> param MUST be included in the response.

For a userRequest with an <operation> param of "update" ✏️, the <confObjID>, <confUserID>, and <userInfo> params MUST all be included in the request. The <userInfo> param is of type "user-type" and contains all the changes to be applied to a specific <user> element in the conference object identified by the <confObjID> param. The user to be modified is identified through the 'entity' attribute of the request's <userInfo> param. When the userResponse has a <response-code> of "200", no additional information is needed in the userResponse. A "200" means the referenced <user> element has been updated by the conference server 🎉. A <response-code> of "426" means the conferencing client isn't allowed to make the changes in the initial request's <userInfo>. This could be because of policies, roles, specific privileges, and so on. The exact reason depends on the conferencing system and its configuration.

For a userRequest with an <operation> param of "delete" 🗑️, the <confObjID> param (the XCON-URI of the target conference) MUST be included. The <confUserID> param, holding the CCMP client's XCON-USERID, MUST be included in the userRequest message. If the client wants to leave the conference, no <userInfo> param is needed in the delete request. But if the client wants to remove another participant, she MUST include a <userInfo> param in the userRequest/delete whose 'entity' attribute conveys that participant's XCON-USERID. The userResponse MUST contain the same <confObjID> value that was in the userRequest. The userResponse MUST contain a <response-code> of "200" if the target <user> element has been successfully deleted. If the userResponse for the delete operation has a <response-code> of "200", the userResponse MUST NOT contain the <userInfo> param.

And here's the schema, the exact vibe check 📜💅:

<!-- userRequest -->

<xs:complexType name="ccmp-user-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="userRequest" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- userRequestType -->

<xs:element name="userRequest" type="userRequestType" />

<xs:complexType name="userRequestType">
    <xs:sequence>
        <xs:element name="userInfo"
                    type="info:user-type" minOccurs="0" />
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- userResponse -->

<xs:complexType name="ccmp-user-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="userResponse" />
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- userResponseType -->

<xs:element name="userResponse" type="userResponseType" />

<xs:complexType name="userResponseType">
    <xs:sequence>
        <xs:element name="userInfo" type="info:user-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

  Figure 12: Structure of the userRequest and userResponse Messages

Part 9 wrap-up: that's the whole userRequest and userResponse vibe 🦋✨

5.3.7. sidebarsByValRequest and sidebarsByValResponse ✨

okay so a sidebarsByValRequest is how you do a retrieve-only operation on the <sidebars-by-val> field of the conference object that <confObjID> points to 👀 it's retrieve-only, so an <operation> parameter MUST NOT be in a sidebarsByValRequest. no edits here, bestie 💅 just reading. 🎀 Like blueprints and conferences, CCMP lets you use xpath filters when the client only wants a selected subset of the sidebars on the server. That works for sidebars by reference AND sidebars by value, so it's giving flexibility 🦋

A sidebarsByValResponse with a <response-code> of "200" MUST contain a <sidebarsByValInfo> parameter holding the <sidebars-by-val> element you asked for 🌸 And it MUST also hand back a <version> element tied to the current version of the main conference object (the one whose ID is in <confObjID> in the request) that those sidebars are linked to. the version matters, obsessed with this for you 🫶

The <sidebarsByValInfo> parameter has the list of the conference objects linked to the sidebars by value that came from the main conference. then you can update or delete those retrieved sidebars with the sidebarByValRequest message, which is in Section 5.3.8 🧚

<!-- sidebarsByValRequest -->

<xs:complexType name="ccmp-sidebarsByVal-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="sidebarsByValRequest"/>
            </xs:sequence>
        </xs:extension>
   </xs:complexContent>
</xs:complexType>

<!-- sidebarsByValRequestType -->

<xs:element name="sidebarsByValRequest"
            type="sidebarsByValRequestType" />

<xs:complexType name="sidebarsByValRequestType">
    <xs:sequence>
        <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>


<!-- sidebarsByValResponse -->

<xs:complexType name="ccmp-sidebarsByVal-response-message-type">
        <xs:complexContent>
         <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
           <xs:element ref="sidebarsByValResponse"/>
          </xs:sequence>
         </xs:extension>
        </xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->

<xs:element name="sidebarsByValResponse"
            type="sidebarsByValResponseType" />

<xs:complexType name="sidebarsByValResponseType">
    <xs:sequence>
        <xs:element name="sidebarsByValInfo"
                    type="info:sidebars-by-val-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 13: Structure of the sidebarsByValRequest and sidebarsByValResponse Messages

5.3.8. sidebarByValRequest and sidebarByValResponse 🍓

okay this section is the big one, so get ready 😭 A sidebarByValRequest MUST contain the <operation> parameter. that's how it tells apart retrieval, creation, modification, and deletion of one specific sidebar. the other required params depend on which operation you picked 🔥

Create: for a "create" operation, the <confObjID> parameter MUST be in the sidebyValRequest message. here <confObjID> holds the XCON-URI of the main conference where the sidebar is going to be made 🌈 If there's no "sidebarByValInfo" parameter, the sidebar gets made by cloning the main conference, like the XCON framework [RFC5239] pictured, following the implementation-specific cloning rules. If there IS a "sidebarByValInfo", then (like direct creation) the sidebar conference object gets built from whatever the requestor gave in that param ✨

When a sidebar-by-val gets created, the conference server MUST update the main conference object reflected by <confObjID> in the sidebarbyValRequest/create message, adding the new sidebar object as a new <entry> in the right <sidebars-by-val> section. The newly created sidebar conference object MAY be included in the sidebarByValResponse, in the <sidebarByValInfo> parameter, if the <response-code> is "200". And the XCON-URI of the new sidebar MUST show up in the <confObjID> parameter of the response 💖 The conference server can also notify any conferencing clients that subscribed to the conference event package and are authorized to hear about the sidebar being added to the conference 📣

Retrieve: for a sidebarByValRequest with an <operation> of "retrieve", the URI of the sidebar's conference object (the one you got back from a create or from a sidebarsByValResponse) MUST be in the <confObjID> parameter of the request. the server handles this exactly like a "retrieve" in a confRequest message, which is covered in Section 5.3.4 🦋

Update: for a sidebarByValRequest with an <operation> of "update", the <sidebarByValInfo> MUST also be in the request. the <confObjID> in the request names the specific sidebar instance to update 🎀 The server handles the update on that sidebar instance (the one in <sidebarByValInfo>) the same way it handles an update on a conference instance reflected by the <confInfo> param of a confRequest message, as detailed in Section 5.3.4. And a sidebarByValResponse MUST return a <version> element tied to the current version of the sidebar whose ID is in the <confObjID> field of the request 🫶

Delete: if an <operation> of "delete" is in the sidebarByVal request, the <sidebarByValInfo> parameter MUST NOT be included 🙈 Any <sidebarByValInfo> that sneaks in anyway MUST be ignored by the conference server. The URI of the sidebar's conference object MUST be in the <confObjID> parameter of the request. If the conferencing user (as reflected by <confUserID>) is authorized to delete the conference, the server deletes the conference object reflected by <confObjID> and updates the data in the conference object the sidebar was cloned from 💀 The conference server can notify subscribed, authorized conferencing clients about the sidebar being deleted from the conference 🌸

Errors: if a sidebarByValRequest with an <operation> of "retrieve", "update", or "delete" has a <confObjID> that isn't tied to any existing sidebar-by-val, a confResponse message with a <response-code> of "404" gets generated on the server's side 😤 This also goes for when the <confObjID> belongs to an existing conference object on the server, but that object is tied to a blueprint or to an actual conference, or to a sidebar-by-ref instead of a sidebar-by-val. no sneaking past the 404 🚫

<!-- sidebarByValRequest -->

<xs:complexType name="ccmp-sidebarByVal-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="sidebarByValRequest"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- sidebarByValRequestType -->

<xs:element name="sidebarByValRequest"
            type="sidebarByValRequestType" />

<xs:complexType name="sidebarByValRequestType">
    <xs:sequence>
        <xs:element name="sidebarByValInfo"
                    type="info:conference-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>


<!-- sidebarByValResponse -->

<xs:complexType name="ccmp-sidebarByVal-response-message-type">
 <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
         <xs:sequence>
                <xs:element ref="sidebarByValResponse"/>
         </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>
<!-- sidebarByValResponseType -->

<xs:element name="sidebarByValResponse"
            type="sidebarByValResponseType" />

<xs:complexType name="sidebarByValResponseType">
  <xs:sequence>
     <xs:element name="sidebarByValInfo"
                 type="info:conference-type" minOccurs="0"/>
     <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 14: Structure of the sidebarByValRequest and sidebarByValResponse Messages

5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 💖

okay so, the sidebarsByRefRequest is basically the sidebarsByValRequest's sibling 👯‍♀️. It lets you grab the <sidebars-by-ref> element from the conference object that the <confObjID> parameter points to. This one is retrieve-only, so an <operation> parameter MUST NOT be included in a sidebarsByRefRequest message 🙅‍♀️. If the <response-code> is "200", the <sidebarsByRefInfo> parameter (the one holding the <sidebars-by-ref> element) MUST be included in the response ✨.

Quick tea on what that element actually is: it's the set of URIs for the sidebars attached to the main conference, but the sidebars' descriptions (written as a standard XCON conference document) live outside the main conference itself 🗺️. Once you've got those URIs, you can poke at individual sidebars with the sidebarByRefRequest message, which is covered in Section 5.3.10 🔍. And a sidebarsByRefResponse message MUST carry back to the client a <version> element for the current version of the main conference object (the one whose identifier is in the <confObjId> field of the request) that those sidebars are linked to 🦋.

<!-- sidebarsByRefRequest -->

<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="sidebarsByRefRequest"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- sidebarsByRefRequestType -->

<xs:element name="sidebarsByRefRequest"
            type="sidebarsByRefRequestType" />

<xs:complexType name="sidebarsByRefRequestType">
    <xs:sequence>
        <xs:element name="xpathFilter"
                    type="xs:string" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- sidebarsByRefResponse -->

<xs:complexType name="ccmp-sidebarsByref-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="sidebarsByRefResponse"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->

<xs:element name="sidebarsByRefResponse"
            type="sidebarsByRefResponseType" />

<xs:complexType name="sidebarsByRefResponseType">
    <xs:sequence>
        <xs:element name="sidebarsByRefInfo"
                    type="info:uris-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 15: Structure of the sidebarsByRefRequest and sidebarsByRefResponse Messages

5.3.10. sidebarByRefRequest and sidebarByRefResponse 🧚

this is where it gets spicy 🌶️. First things first: a sidebarByValResponse message MUST return to the client a <version> element for the current version of the sidebar whose identifier is in the <confObjID> field of the request 💅.

Create: when you're making a brand new sidebar, the <confObjID> parameter MUST be included in the sidebyRefRequest message 📝. Here it holds the XCON-URI of the main conference where the sidebar is going to live 🏠. If there's no <sidebarByRefInfo> parameter, then following the XCON framework [RFC5239], the sidebar gets made by cloning the main conference, using whatever implementation-specific cloning rules the server has 👯. Otherwise, it's like direct creation, where the sidebar conference object is built from the <sidebarByRefInfo> parameter the requestor gave 🧱. If the sidebar gets created successfully, the conference server MUST update the <sidebars-by-ref> element in the conference object the sidebar came from (the one identified by the <confObjID> in the original sidebarByRefRequest) so it includes the URI of the new sidebar 🔗. The newly created conference object MAY be included in the response in the <sidebarByRefInfo> parameter with a <response-code> of "200" 🎁. The URI for the conference object of the new sidebar MUST appear in the <confObjID> parameter of the response 🎀. The conference server can notify any conferencing clients that subscribed to the conference event package and are authorized to hear about the sidebar being added 📣.

Retrieve: for a sidebarByRefRequest with an <operation> parameter of "retrieve", the URI for the sidebar's conference object MUST be included in the <confObjID> parameter of the request 👀. The server handles a retrieve on the <sidebarByRefInfo> the exact same way it handles a retrieve on the confInfo inside a confRequest message, which is detailed in Section 5.3.4 🔁.

Update: for a sidebarByRefRequest with an <operation> parameter of "update", the sidebar's conference object URI MUST be included in the <confObjID> parameter 🔑. The <sidebarByRefInfo> MUST also be included in the request for an "update" operation 🧾. The server treats the update on <sidebarByRefInfo> just like an update on the <confInfo> inside a confRequest message, as detailed in Section 5.3.4 🛠️. A sidebarByRefResponse message MUST carry back to the client a <version> element for the current version of the sidebar whose identifier is in the <confObjID> field of the request 🦋.

Delete: if an <operation> parameter of "delete" is in the sidebarByRefRequest, the <sidebarByRefInfo> parameter MUST NOT be included in the request 🗑️. Anything in <sidebarByRefInfo> that does get sent MUST be ignored by the conference server 🙈. The URI for the sidebar's conference object MUST be included in the <confObjID> parameter of the request 📍. If the conferencing user in the <confUserID> parameter is authorized to delete the conference, the conference server SHOULD delete the conference object in <confObjID>, and SHOULD also update the <sidebars-by-ref> element in the conference object the sidebar was originally cloned from 🧹. The conference server can notify subscribed conferencing clients that are authorized to hear about the sidebar's deletion too 📣.

Heads up: if a sidebarByRefRequest with an <operation> parameter of "retrieve", "update", or "delete" has a <confObjID> that isn't tied to any existing sidebar-by-ref, the server will generate a confResponse message with a <response-code> of "404" 🚨. The same thing happens when the <confObjID> points to an existing conference object on the server that's tied to a blueprint, an actual conference, or a sidebar-by-val instead of a sidebar-by-ref 💀.

<!-- sidebarByRefRequest -->

<xs:complexType name="ccmp-sidebarByRef-request-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-request-message-type">
            <xs:sequence>
                <xs:element ref="sidebarByRefRequest"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

<!-- sidebarByRefRequestType -->

<xs:element name="sidebarByRefRequest"
            type="sidebarByRefRequestType" />

<xs:complexType name="sidebarByRefRequestType">
    <xs:sequence>
        <xs:element name="sidebarByRefInfo"
                    type="info:conference-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- sidebarByRefResponse -->

<xs:complexType name="ccmp-sidebarByRef-response-message-type">
    <xs:complexContent>
        <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                <xs:element ref="sidebarByRefResponse"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->

<xs:element name="sidebarByRefResponse"
            type="sidebarByRefResponseType" />

<xs:complexType name="sidebarByRefResponseType">
    <xs:sequence>
        <xs:element name="sidebarByRefInfo"
                    type="info:conference-type" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

Figure 16: Structure of the sidebarByRefRequest and sidebarByRefResponse Messages

5.3.11. extendedRequest and extendedResponse ✨

okay bestie, CCMP wants to be future-proof 🔮 so it gives you extendedRequest and extendedResponse, a skeleton where you can carry info for conference control stuff the spec didn't explicitly dream up. Those mechanisms are called "extensions" 🧩 and each one needs an appropriate name that MUST be carried in the pair's <extensionName> field. Extension-specific info rides along as schema-defined XML elements inside the <any> element that shows up in both messages 💖

The conferencing client SHOULD be able to figure out which extensions a CCMP server supports, and grab the XML schema that defines their elements, through an optionsRequest/optionsResponse transaction (see Section 5.3.12) 🕵️‍♀️

And the common CCMP parameters that extendedRequest and extendedResponse inherit from the basic request and response messages? Their meaning SHOULD be preserved and used properly when you're designing an extension 🫶

<!-- extendedRequest -->

<xs:complexType name="ccmp-extended-request-message-type">
   <xs:complexContent>
       <xs:extension base="tns:ccmp-request-message-type">
          <xs:sequence>
                         <xs:element ref="extendedRequest"/>
          </xs:sequence>
       </xs:extension>
   </xs:complexContent>
</xs:complexType>

<!-- extendedRequestType -->

<xs:element name="extendedRequest" type="extendedRequestType"/>

<xs:complexType name="extendedRequestType">
  <xs:sequence>
        <xs:element name="extensionName"
                    type="xs:string" minOccurs="1"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0"
            maxOccurs="unbounded" />
 </xs:sequence>
</xs:complexType>

<!-- extendedResponse -->

<xs:complexType name="ccmp-extended-response-message-type">
   <xs:complexContent>
       <xs:extension base="tns:ccmp-response-message-type">
           <xs:sequence>
                         <xs:element ref="extendedResponse"/>
           </xs:sequence>
       </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->

<xs:element name="extendedResponse" type="extendedResponseType"/>

<xs:complexType name="extendedResponseType">
        <xs:sequence>
                <xs:element name="extensionName"
                            type="xs:string"
                            minOccurs="1"/>
                <xs:any namespace="##other"
                        processContents="lax"
                        minOccurs="0" maxOccurs="unbounded" />
        </xs:sequence>
</xs:complexType>

           Figure 17: Structure of the extendedRequest and
                      extendedResponse Messages

5.3.12. optionsRequest and optionsResponse ✨

the optionsRequest message (Figure 18) is your "what can this server do?" 🔍 It grabs general info about conference server capabilities, covering both the standard CCMP request/response pairs and any extension messages the server supports. Because of that, it's a basic CCMP message and NOT a specialization of the general CCMP request 🙈

Hmm, correction, bestie: it's a basic CCMP message rather than a specialization of the general CCMP request. The optionsResponse hands back a list of the supported CCMP message pairs (as defined in this spec) inside the <options> field. That list is a <standard-message-list>, with one <standard-message> element per supported message. There's also an <extended-message-list>, which holds extra message types that are currently undefined, so the protocol can grow later 🌱

For both kinds of messages, here's what you get:

<name> (REQUIRED): for standard messages, it's one of the 10 standard message names defined in this document (like "blueprintsRequest", "confsRequest", etc.). For extensions, this element MUST carry the same value as the <extension-name> inserted in the matching extendedRequest/extendedResponse pair 🏷️
<operations> (OPTIONAL): a list of <operation> entries, each one a Create, Read, Update, Delete (CRUD) operation the server supports for that message. If this element is missing, the client SHOULD assume the server can handle the whole set of CRUD operations or, for standard messages, all the operations this document envisions for that message 💅
<schema-ref> (OPTIONAL): all CCMP messages can potentially contain XML elements not in the CCMP schema (thanks to <any> elements and attributes), so this field can send clients a reference to a schema defining those new elements or attributes. If this element is missing, no new elements show up in the messages beyond the ones the CCMP specification explicitly defines 📎
<description> (OPTIONAL): human-readable info about the related message 📝

The only parameter the optionsRequest needs is the sender confUserID, and that gets mirrored in the same parameter of the matching optionsResponse 🎀

The CCMP server MUST include a <standard-message-list> containing at least one <operation> element in the optionsResponse, because a CCMP server is REQUIRED to handle both the request and response messages for at least one of the operations. No exceptions, periodt 👑

<!-- optionsRequest -->

<xs:complexType name="ccmp-options-request-message-type">
        <xs:complexContent>
                <xs:extension base="tns:ccmp-request-message-type"/>
        </xs:complexContent>
</xs:complexType>

<!-- optionsResponse -->

<xs:complexType name="ccmp-options-response-message-type">
   <xs:complexContent>
      <xs:extension base="tns:ccmp-response-message-type">
        <xs:sequence>
          <xs:element ref="optionsResponse"/>
        </xs:sequence>
      </xs:extension>
  </xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->

<xs:element name="optionsResponse"
               type="optionsResponseType" />

<xs:complexType name="optionsResponseType">
  <xs:sequence>
   <xs:element name="options"
            type="options-type" minOccurs="0"/>
   <xs:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- options-type -->

<xs:complexType name="options-type">
   <xs:sequence>
        <xs:element name="standard-message-list"
                type="standard-message-list-type"
                minOccurs="1"/>
    <xs:element name="extended-message-list"
                type="extended-message-list-type"
                minOccurs="0"/>
    <xs:any namespace="##other" processContents="lax"
            minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- standard-message-list-type -->

<xs:complexType name="standard-message-list-type">
  <xs:sequence>
        <xs:element name="standard-message"
                    type="standard-message-type"
                    minOccurs="1" maxOccurs="10"/>
    <xs:any namespace="##other" processContents="lax"
            minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->

<xs:complexType name="standard-message-type">
   <xs:sequence>
        <xs:element name="name"
                    type="standard-message-name-type"
                    minOccurs="1"/>
        <xs:element name="operations"
                    type="operations-type"
                    minOccurs="0"/>
        <xs:element name="schema-def"
                    type="xs:string" minOccurs="0"/>
        <xs:element name="description"
                    type="xs:string" minOccurs="0"/>
    <xs:any namespace="##other" processContents="lax"
            minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<!-- standard-message-name-type -->

<xs:simpleType name="standard-message-name-type">
   <xs:restriction base="xs:token">
    <xs:enumeration value="confsRequest"/>
    <xs:enumeration value="confRequest"/>
    <xs:enumeration value="blueprintsRequest"/>
    <xs:enumeration value="blueprintRequest"/>
    <xs:enumeration value="usersRequest"/>
    <xs:enumeration value="userRequest"/>
    <xs:enumeration value="sidebarsByValRequest"/>
    <xs:enumeration value="sidebarByValRequest"/>
    <xs:enumeration value="sidebarsByRefRequest"/>
    <xs:enumeration value="sidebarByRefRequest"/>
   </xs:restriction>
</xs:simpleType>
<!-- operations-type -->

<xs:complexType name="operations-type">
  <xs:sequence>
     <xs:element name="operation" type="operationType"
                 minOccurs="1" maxOccurs="4"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

           Figure 18: Structure of the optionsRequest and
                      optionsResponse Messages

5.4. CCMP Response Codes ✨

okay bestie, every single CCMP response message MUST include a <response-code> 💖 no exceptions. This doc sets up an IANA registry for these codes (see Section 12.5.2) 📋 and here's the vibe-check summary 💅

200 Success ✅: the requested operation finished successfully 🎀
400 Bad Request 🙈: the request is syntactically malformed
401 Unauthorized 🔒: the user isn't allowed to do the required operation
403 Forbidden 🚫: the operation isn't allowed (e.g., cancelling a blueprint)
404 Object Not Found 🔍: the target conference object doesn't exist at the server (the object in the error message is the <confObjID> parameter in the generic request message) 🧐
409 Conflict 💥: a generic catch-all for when the server can't finish a requested client operation. For example, a modification can't be applied because the client's copy of the object is obsolete and the requested changes collide with the up-to-date state on the server. This code is also used when a client tries to create an object (conference or user) with an entity that already exists 😭
420 User Not Found 👻: the target user is missing at the server (it relates to the XCON-USERID in the 'entity' attribute of the <userInfo> parameter when that is included in userRequests)
421 Invalid confUserID 🪪: the user doesn't exist at the server (returned for requests where the <confUserID> parameter is invalid)
422 Invalid Conference Password 🔑: the password for the target conference object in the request is wrong
423 Conference Password Required 🗝️: "conference-password" is missing from a request to access a password-protected conference object
424 Authentication Required 🛂: the user's authentication information is missing or invalid
425 Forbidden Delete Parent 👑: the cancel failed because the target object is a parent of child objects that depend on it, or because (via the "parent-enforceable" mechanism) it affects the matching element in a child object
426 Forbidden Change Protected 🛡️: the server refused the update because the target element can't be changed, since it implicitly depends on a parent object's value ("parent-enforceable" mechanism)
427 Invalid Domain Name 🌐: the domain name in an AUTO_GENERATE_X instance in the conference object is outside the CCMP server's domain of responsibility
500 Server Internal Error 🔥: the server can't finish the required service because of a system internal error
501 Not Implemented 🧩: the operation is defined by the protocol but this server doesn't implement it
510 Request Timeout ⏰: serving the request took longer than the configured service threshold
511 Resources Not Available 🪫: used when the CCMP server can't run a command because of resource issues. For example, it can't create a sub-conference because the system has hit its sub-conference limit, or a request to add a new user fails because the max number of users has been reached for the conference or for the conferencing system 📉

The handling of a <response-code> of "404", "409", "420", "421", "425", "426", or "427" only applies to specific operations for specialized message responses, and the details live in Section 5.3. The table below sums up these response codes and the specialized message and operation each one applies to 📊

+----------+-------------+--------------+-------------+-------------+
| Response | Create      | Retrieve     | Update      | Delete      |
| code     |             |              |             |             |
+----------+-------------+--------------+-------------+-------------+
| 404      | userRequest | All retrieve | All update  | All delete  |
|          | sidebarBy   | requests     | requests    | requests    |
|          | ValRequest, | EXCEPT:      |             |             |
|          | sidebarsBy  | blueprints   |             |             |
|          | RefRequest  | Request,     |             |             |
|          |             | confsRequest |             |             |
| -------- | ----------- | ------------ | ----------- | ----------- |
| 409      | N/A         | N/A          | All update  | N/A         |
|          |             |              | requests    |             |
| -------- | ----------- | -----------  | ----------- | ----------- |
| 420      | userRequest | userRequest  | userRequest | userRequest |
|          | (third-     |              |             |             |
|          | party       |              |             |             |
|          | invite with |              |             |             |
|          | third-user  |              |             |             |
|          | entity) (*) |              |             |             |
| -------- | ----------- | -----------  | ----------- | ----------- |
| 421      | All create  | All retrieve | All update  | All delete  |
|          | requests    | requests     | requests    | requests    |
|          | EXCEPT:     |              |             |             |
|          | userRequest |              |             |             |
|          | with no     |              |             |             |
|          | confUserID  |              |             |             |
|          | (**)        |              |             |             |
| -------- | ----------- | -----------  | ----------- | ----------- |
| 425      | N/A         | N/A          | N/A         | All delete  |
|          |             |              |             | request     |
| -------- | ----------- | -----------  | ----------- | ----------- |
| 426      | N/A         | N/A          | All update  | N/A         |
|          |             |              | requests    |             |
| -------- | ----------- | -----------  | ----------- | ----------- |
| 427      | ConfRequest | N/A          | All update  | N/A         |
|          | UserRequest |              | requests    |             |
+----------+-------------+--------------+-------------+-------------+

             Table 2: Response Codes and Associated Operations

(*) "420" in answer to a "userRequest/create" operation: in the case of a third-party invite, this code can come back if the <confUserID> (contained in the 'entity' attribute of the <userInfo> parameter) of the user being added is unknown. If it's actually the <confUserID> parameter of the request's sender that's invalid, a <response-code> of "421" goes back to the client instead 🕵️

(**) "421" is never sent in answer to userRequest/create messages with a "null" confUserID 🫶 because that case belongs to a user who doesn't know their own XCON-USERID but still wants to join a known conference 🥹

If you get a <response-code> of "510", a conferencing client MAY re-attempt the request after a period of time that's specific to the conferencing client or conference server ⏳

A <response-code> of "400" means the conferencing client sent a malformed request, which points to an error in the client or in the conference server 🤒 How to handle it is up to the client implementation (for example, write a log, show an error message, and so on). It is NOT RECOMMENDED that the client re-attempt the request in this case 🚫

A <response-code> of "401" or "403" means the client doesn't have the right permissions, or there's a problem with the permissions themselves. Re-attempting would likely fail too, so it is NOT RECOMMENDED 🙅‍♀️

Any unexpected or unknown <response-code> SHOULD be handled by the client the same way as a <response-code> of "500", and how that's done is up to the conferencing client implementation 🧃

6. A Complete Example of CCMP in Action ✨

okay so this section walks through a typical scenario where CCMP shows up, and it's totally non-normative 💜 we show the actual composition of the different CCMP messages so you can see the whole flow in action 🎬 In the call flows, the conferencing client is a CCMP-enabled client and the conference server is a CCMP-enabled server 🖥️ The client is Alice 👩‍🦰, whose XCON-USERID is "xcon-userid:alice@example.com", and that shows up in the <confUserID> parameter of every request. Here's her journey:

Alice retrieves the list of available blueprints from the server (Section 6.1) 📜;
Alice asks for detailed info about one specific blueprint (Section 6.2) 🔎;
Alice decides to create a new conference by cloning the blueprint she retrieved (Section 6.3) 🐑;
Alice modifies information (for example, the XCON-URI, name, and description) tied to the newly created blueprint (Section 6.4) ✏️;
Alice specifies a list of users to contact once the conference is activated (Section 6.5) 📞;
Alice joins the conference (Section 6.6) 🎉;
Alice lets a new user, Ciccio (whose XCON-USERID is "xcon-userid:Ciccio@example.com"), join the conference (Section 6.7) 👯;
Alice asks for the CCMP server's capabilities (Section 6.8) 🧠;
Alice exploits an extension of the CCMP server (Section 6.9) 🦋.

Note that the examples don't include any details beyond the basic operation 🌸

In the following sections, we deal with each of the aforementioned actions separately 💅

6.1. Alice Retrieves the Available Blueprints ✨

okay so this part shows the blueprints transaction, plus a dump of the two messages that get swapped (blueprintsRequest and blueprintsResponse) 💖 The cute bit is that the blueprintsResponse carries a <blueprintsInfo> parameter with the list of available blueprints. Each one comes as its standard XCON-URI, plus some extra (and optional) stuff like its display-text and purpose 🎀

Alice asks the server for the list of available blueprints:

    CCMP Client                                             CCMP Server
         |                                                       |
         | CCMP blueprintsRequest message                        |
         |   - confUserID: Alice                                 |
         |   - confObjID: (null)                                 |
         |------------------------------------------------------>|
         |                                                       |
         |                     CCMP blueprintsResponse message   |
         |                      - confUserID: Alice              |
         |                      - confObjID: (null)              |
         |                      - response-code: 200             |
         |                      - blueprintsInfo: bp123,bp124,.. |
         |<------------------------------------------------------|
         |                                                       |
         .                                                       .
         .                                                       .

blueprintsRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-blueprints-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <ccmp:blueprintsRequest/>
    </ccmpRequest>
</ccmp:ccmpRequest>

blueprintsResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
 xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
 xmlns:info="urn:ietf:params:xml:ns:conference-info"
 xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:type="ccmp:ccmp-blueprints-response-message-type">
   <confUserID>xcon-userid:alice@example.com</confUserID>
   <response-code>200</response-code>
     <ccmp:blueprintsResponse>
      <blueprintsInfo>
       <info:entry>
        <info:uri>xcon:AudioRoom@example.com</info:uri>
        <info:display-text>AudioRoom</info:display-text>
        <info:purpose>Simple Room:
           conference room with public access,
           where only audio is available, more users
           can talk at the same time
           and the requests for the AudioFloor
           are automatically accepted.
        </info:purpose>
       </info:entry>
       <info:entry>
        <info:uri>xcon:VideoRoom@example.com</info:uri>
        <info:display-text>VideoRoom</info:display-text>
        <info:purpose>Video Room:
            conference room with public access,
            where both audio and video are available,
            8 users can talk and be seen at the same time,
            and the floor requests are automatically accepted.
        </info:purpose>

       </info:entry>
       <info:entry>
        <info:uri>xcon:AudioConference1@example.com</info:uri>
        <info:display-text>AudioConference1</info:display-text>
        <info:purpose>Public Audio Conference:
             conference with public access,
             where only audio is available,
             only one user can talk at the same time,
             and the requests for the AudioFloor MUST
             be accepted by a Chair.
        </info:purpose>
       </info:entry>
       <info:entry>
        <info:uri>xcon:VideoConference1@example.com</info:uri>
        <info:display-text>VideoConference1</info:display-text>
          <info:purpose>Public Video Conference: conference
              where both audio and video are available,
              only one user can talk.
          </info:purpose>
        </info:entry>
        <info:entry>
         <info:uri>xcon:AudioConference2@example.com</info:uri>
         <info:display-text>AudioConference2</info:display-text>
         <info:purpose>Basic Audio Conference:
              conference with private access,
              where only audio is available,
              only one user can talk at the same time,
              and the requests for the AudioFloor MUST
              be accepted by a Chair.
         </info:purpose>
        </info:entry>
     </blueprintsInfo>
   </ccmp:blueprintsResponse>
  </ccmpResponse>
</ccmp:ccmpResponse>

Figure 19: Getting Blueprints from the Server

6.2. Alice Gets Detailed Information about a Specific Blueprint 🦋

this is the second transaction in the overall flow 💅 Alice now knows the XCON-URIs of the blueprints on the server, so she sends a drill-down query, a CCMP blueprintRequest message, to get the details of one of them (the one called with XCON-URI "xcon:AudioRoom@example.com"). The picture shows the transaction. Notice that the response has a <blueprintInfo> parameter holding a document that's compliant with the standard XCON data model 🌸

Alice retrieves detailed information about a specified blueprint:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP blueprintRequest message                         |
        |   - confUserID: Alice                                 |
        |   - confObjID: bp123                                  |
        |   - operation: retrieve                               |
        |   - blueprintInfo: (null)                             |
        |------------------------------------------------------>|
        |                                                       |
        |                        CCMP blueprintResponse message |
        |                          - confUserID: Alice          |
        |                          - confObjID: bp123           |
        |                          - operation: retrieve        |
        |                          - response-code: 200         |
        |                          - blueprintInfo: bp123Info   |
        |<------------------------------------------------------|
        |                                                       |
        .                                                       .
        .                                                       .

blueprintRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
  <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-blueprint-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:AudioRoom@example.com</confObjID>
        <operation>retrieve</operation>
        <ccmp:blueprintRequest/>
  </ccmpRequest>
</ccmp:ccmpRequest>

blueprintResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
 <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-blueprint-response-message-type">
 <confUserID>xcon-userid:alice@example.com</confUserID>
 <confObjID>xcon:AudioRoom@example.com</confObjID>
 <operation>retrieve</operation>
 <response-code>200</response-code>
 <response-string>Success</response-string>
 <ccmp:blueprintResponse>
   <blueprintInfo entity="xcon:AudioRoom@example.com">
    <info:conference-description>
       <info:display-text>AudioRoom</info:display-text>
       <info:available-media>
          <info:entry label="audioLabel">
             <info:display-text>audio stream</info:display-text>
             <info:type>audio</info:type>
          </info:entry>
       </info:available-media>
    </info:conference-description>
    <info:users>
      <xcon:join-handling>allow</xcon:join-handling>
     </info:users>
    <xcon:floor-information>
     <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
      <xcon:conference-floor-policy>
          <xcon:floor id="audioFloor">
              <xcon:media-label>audioLabel</xcon:media-label>
          </xcon:floor>
      </xcon:conference-floor-policy>
    </xcon:floor-information>
   </blueprintInfo>
  </ccmp:blueprintResponse>
 </ccmpResponse>
</ccmp:ccmpResponse>

Figure 20: Getting Information about a Specific Blueprint

6.3. Alice Creates a New Conference through a Cloning Operation 🎀

this is the third transaction in the flow, and it's giving main character energy 👑 Alice decides to make a brand new conference by cloning the blueprint with XCON-URI "xcon:AudioRoom@example.com", the one she just pulled details for with the blueprintRequest message. She does it by sending a confRequest/create message with the blueprint's URI in the <confObjID> parameter 🧚 The picture shows the transaction. The response carries the document for the newly created conference in the <confInfo> parameter, and that document is compliant with the standard XCON data model. The <confObjID> in the response is set to the XCON-URI of the new conference, which in this case is "xcon:8977794@example.com". We also notice that this value matches the value of the 'entity' attribute on the <conference-info> element of the document describing the new conference object 🫶

Alice creates a new conference by cloning the "xcon:AudioRoom@example.com" blueprint:

CCMP Client                                             CCMP Server
       |                                                       |
       | CCMP confRequest message                              |
       |   - confUserID: Alice                                 |
       |   - confObjID: AudioRoom                              |
       |   - operation: create                                 |
       |   - confInfo: (null)                                  |
       |------------------------------------------------------>|
       |                                                       |
       |                            CCMP confResponse message  |
       |                              - confUserID: Alice      |
       |                              - confObjID: newConfId   |
       |                              - operation: create      |
       |                              - response-code: 200     |
       |                              - version: 1             |
       |                              - confInfo: newConfInfo  |
       |<------------------------------------------------------|
       |                                                       |
       .                                                       .
       .                                                       .

confRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
   <ccmpRequest
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-conf-request-message-type">
      <confUserID>xcon-userid:alice@example.com</confUserID>
      <confObjID>xcon:AudioRoom@example.com</confObjID>
      <operation>create</operation>
      <ccmp:confRequest/>
   </ccmpRequest>
</ccmp:ccmpRequest>

confResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-conf-response-message-type">
 <confUserID>xcon-userid:alice@example.com</confUserID>
 <confObjID>xcon:8977794@example.com</confObjID>
 <operation>create</operation>
 <response-code>200</response-code>
 <response-string>Success</response-string>
 <version>1</version>
 <ccmp:confResponse>
   <confInfo entity="xcon:8977794@example.com">
     <info:conference-description>
       <info:display-text>
              New conference by Alice cloned from AudioRoom
       </info:display-text>
       <info:available-media>
               <info:entry label="333">
                 <info:display-text>audio stream</info:display-text>
                 <info:type>audio</info:type>
               </info:entry>
        </info:available-media>
      </info:conference-description>
      <info:users>
           <xcon:join-handling>allow</xcon:join-handling>
      </info:users>
      <xcon:floor-information>
      <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
       <xcon:conference-floor-policy>
          <xcon:floor id="11">
             <xcon:media-label>333</xcon:media-label>
          </xcon:floor>
       </xcon:conference-floor-policy>
      </xcon:floor-information>
     </confInfo>
    </ccmp:confResponse>
  </ccmpResponse>
</ccmp:ccmpResponse>

Figure 21: Creating a New Conference by Cloning a Blueprint

6.4. Alice Updates Conference Information ✨

Okay bestie, this is the fourth transaction in the whole flow 💅 Alice decides she wants to tweak a few details on the conference she just made. Specifically, she's changing the <display-text> element sitting under <conference-description> in the conference document. She does this with a confRequest/update message, and that message carries just the fragment of the conference document that needs the changes applied. 🫶

The response comes back with a code of "200", which means the server acknowledged what Alice asked for. It also bumps the conference version from 1 to 2, and you can see that in the "version" parameter. Iconic behaviour, honestly 🔥

Alice updates information about the conference she just created:

CCMP Client                                             CCMP Server
     |                                                       |
     | CCMP confRequest message                              |
     |   - confUserID: Alice                                 |
     |   - confObjID: 8977794                                |
     |   - operation: update                                 |
     |   - confInfo: confUpdates                             |
     |------------------------------------------------------>|
     |                                                       |
     |                            CCMP confResponse message  |
     |                              - confUserID: Alice      |
     |                              - confObjID: 8977794     |
     |                              - operation: update      |
     |                              - response-code: 200     |
     |                              - version: 2             |
     |                              - confInfo: (null)       |
     |<------------------------------------------------------|
     |                                                       |
     .                                                       .
     .                                                       .

confRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
            xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
   <ccmpRequest
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-conf-request-message-type">
     <confUserID>xcon-userid:alice@example.com</confUserID>
     <confObjID>xcon:8977794@example.com</confObjID>
     <operation>update</operation>
     <ccmp:confRequest>
          <confInfo entity="xcon:8977794@example.com">
             <info:conference-description>
               <info:display-text>
                  Alice's conference
               </info:display-text>
             </info:conference-description>
          </confInfo>
       </ccmp:confRequest>
   </ccmpRequest>
</ccmp:ccmpRequest>

confResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
     xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
     xmlns:info="urn:ietf:params:xml:ns:conference-info"
     xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-conf-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>update</operation>
        <response-code>200</response-code>
        <response-string>Success</response-string>
        <version>2</version>
        <ccmp:confResponse/>
    </ccmpResponse>
</ccmp:ccmpResponse>

Figure 22: Updating Conference Information

6.5. Alice Inserts a List of Users into the Conference Object 🦋

This one's the fifth transaction in the flow 🌸 Alice edits the <allowed-users-list> under the <users> element, inside the document for the conference she created. To pull it off, she uses the usersRequest message that CCMP gives her. Main character energy, ngl ✨

Alice updates information about the list of users who are allowed into the conference:

CCMP Client                                             CCMP Server
     |                                                       |
     | CCMP usersRequest message                             |
     |   - confUserID: Alice                                 |
     |   - confObjID: 8977794                                |
     |   - operation: update                                 |
     |   - usersInfo: usersUpdates                           |
     |------------------------------------------------------>|
     |                                                       |
     |                           CCMP usersResponse message  |
     |                             - confUserID: Alice       |
     |                             - confObjID: 8977794      |
     |                             - operation: update       |
     |                             - response-code: 200      |
     |                             - version: 3              |
     |                             - usersInfo: (null)       |
     |<------------------------------------------------------|
     |                                                       |
     .                                                       .
     .                                                       .

usersRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
     xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
         xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-users-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>update</operation>
        <ccmp:usersRequest>
            <usersInfo>
                <xcon:allowed-users-list>
                    <xcon:target method="dial out"
                                 uri="xmpp:cicciolo@pippozzo.com"/>
                    <xcon:target method="refer"
                                 uri="tel:+1-972-555-1234"/>
                    <xcon:target method="refer"
                                 uri="sip:Carol@example.com"/>
                </xcon:allowed-users-list>
            </usersInfo>
        </ccmp:usersRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

usersResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-users-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>retrieve</operation>
        <response-code>200</response-code>
        <response-string>Success</response-string>
        <version>3</version>
        <ccmp:usersResponse/>
    </ccmpResponse>
</ccmp:ccmpResponse>

Figure 23: Updating the List of Allowed Users for the Conference 'xcon:8977794@example.com'

6.6. Alice Joins the Conference ✨

okay bestie, this is the sixth transaction in the whole flow 🦋 Alice uses CCMP to add herself to the brand new conference. She sends a userRequest/create message, and the <userInfo> parameter holds a <user> element that follows the XCON data model 💅 That element carries her Addresses of Record plus her current endpoint. Below is the picture of the transaction. The fun part to notice is that the <confUserID> parameter matches the 'entity' attribute of the <userInfo> element. That tells the server this request is a first-party one 💖

Alice joins the conference by issuing a userRequest/create message with her own ID to the server:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP userRequest message                              |
        |   - confUserID: Alice                                 |
        |   - confObjID: 8977794                                |
        |   - operation: create                                 |
        |   - userInfo: AliceUserInfo                           |
        |------------------------------------------------------>|
        |                                                       |
        |                            CCMP userResponse message  |
        |                              - confUserID: Alice      |
        |                              - confObjID: 8977794     |
        |                              - operation: create      |
        |                              - response-code: 200     |
        |                              - version: 4             |
        |                              - userInfo: (null)       |
        |<------------------------------------------------------|
        |                                                       |
        .                                                       .
        .                                                       .

userRequest message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
       xmlns:info="urn:ietf:params:xml:ns:conference-info"
           xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
           xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
                <operation>create</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:alice@example.com">
                <info:associated-aors>
                    <info:entry>
                        <info:uri>
                           mailto:Alice83@example.com
                        </info:uri>
                        <info:display-text>email</info:display-text>
                    </info:entry>
                </info:associated-aors>
                <info:endpoint entity="sip:alice_789@example.com"/>
            </userInfo>
        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

userResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:type="ccmp:ccmp-user-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>create</operation>
        <response-code>200</response-code>
        <response-string>Success</response-string>
        <version>4</version>
        <ccmp:userResponse/>
    </ccmpResponse>
</ccmp:ccmpResponse>

Figure 24: Alice Joins the Conference through CCMP 🎀

6.7. Alice Adds a New User to the Conference 💜

this is the seventh and final transaction in the overall flow 😭 Alice uses CCMP to add a new conferencing system user, Ciccio, to the conference. This is a "third-party" request, and it's done with a userRequest/create message. The <userInfo> parameter holds a <user> element that follows the XCON data model. That element has Ciccio's Addresses of Record and his current endpoint, but its 'entity' attribute is just a placeholder, "AUTO_GENERATE_1@example.com", as discussed in Section 4.3. Why? Because Alice doesn't know Ciccio's XCON-USERID yet 🙈 So the conference server generates a new XCON-USERID for the user Alice named (Ciccio), puts it in the 'entity' attribute of the <userInfo> parameter in the response, and adds him to the conference. The picture below shows the whole thing ✨

Alice adds user "Ciccio" to the conference by issuing a third-party userRequest/create message to the server:

  CCMP Client                                             CCMP Server
       |                                                       |
       | CCMP userRequest message                              |
       |   - confUserID: Alice                                 |
       |   - confObjID: 8977794                                |
       |   - operation: create                                 |
       |   - userInfo: dummyUserID, CiccioUserInfo             |
       |------------------------------------------------------>|
       |                                                       |
       |                       CCMP optionsResponse message    |
       |                            - confUserID: Alice        |
       |                            - confObjID: 8977794       |
       |                            - operation: create        |
       |                            - response-code: 200       |
       |                            - version: 5               |
       |                            - userInfo: userIDCiccio,  |
       |                                        CiccioUserInfo |
       |                                                       |
       |<------------------------------------------------------|
       |                                                       |
       .                                                       .
       .                                                       .

"third-party" userRequest message from Alice:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
       xmlns:info="urn:ietf:params:xml:ns:conference-info"
       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="ccmp:ccmp-user-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>create</operation>
        <ccmp:userRequest>
            <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
                <info:associated-aors>
                    <info:entry>
                        <info:uri>
                            mailto:Ciccio@example.com
                        </info:uri>
                        <info:display-text>email</info:display-text>
                    </info:entry>
                </info:associated-aors>
                <info:endpoint entity="sip:Ciccio@example.com"/>
            </userInfo>

        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

"third-party" userResponse message from the server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ccmp:ccmpResponse
        xmlns:info="urn:ietf:params:xml:ns:conference-info"
        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="ccmp:ccmp-user-response-message-type">
         <confUserID>xcon-userid:alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>create</operation>
         <response-code>200</response-code>
         <version>5</version>
         <ccmp:userResponse>
                 <userInfo entity="xcon-userid:Ciccio@example.com">
                 <info:associated-aors>
                     <info:entry>
                         <info:uri>
                             mailto:Ciccio@example.com
                         </info:uri>
                         <info:display-text>email</info:display-text>
                     </info:entry>
                 </info:associated-aors>
                 <info:endpoint entity="sip:Ciccio@example.com"/>
             </userInfo>
         </ccmp:userResponse>
     </ccmpResponse>
 </ccmp:ccmpResponse>

Figure 25: Alice Adds a New User to the Conference through CCMP 🌸

6.8. Alice Asks for the CCMP Server Capabilities ✨

okay so this section is about how Alice can find out which standard CCMP messages the server supports, plus any extensions it has 🔍 she does this with an optionsRequest/optionsResponse transaction, and it is giving detective energy 🕵️‍♀️

to make the optionsRequest, Alice just drops her XCON-USERID into the <confUserID> parameter. no cap, that's the whole setup 💅 then she reads the <options> element in the optionsResponse and figures out these server capabilities for standard CCMP messages:

the server doesn't support sidebarsByValRequest or sidebarByValRequest, because neither one shows up in the <standard-message-list> 🙈
the only operation the server has for the blueprintRequest message is "retrieve", since there are no other <operation> entries in its <operations> field 🎀

next up, Alice checks the <extended-message-list> and discovers the server has a bluePrint extension 🧚 in this example it's called "confSummaryRequest" and it's giving main character energy ⭐ this extension lets Alice pull a brief description of a specific conference through CCMP. the XML elements for this extended conference control transaction live at the URL in the <schema-ref> element, and the only operation this extension offers is "retrieve". if you want to see how Alice actually uses "confSummaryRequest" over CCMP, check out Section 6.9 🦋

here's the optionsRequest/optionsResponse exchange between Alice and the CCMP server, as a picture:

CCMP Client                                             CCMP Server
     |                                                       |
     | CCMP optionsRequest message                           |
     |   - confUserID: Alice                                 |
     |------------------------------------------------------>|
     |                                                       |
     |                          CCMP userResponse message    |
     |                            - confUserID: Alice        |
     |                            - response-code: 200       |
     |                            - options (list of both    |
     |                              standard and extended    |
     |                              supported messages)      |
     |<------------------------------------------------------|
     |                                                       |
     .                                                       .
     .                                                       .

optionsRequest (Alice asks for CCMP server capabilities)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest
        xmlns:info="urn:ietf:params:xml:ns:conference-info"
        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-options-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>

    </ccmpRequest>
  </ccmp:ccmpRequest>

optionsResponse (the server returns the list of its conference control capabilities)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse
         xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
         xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="ccmp:ccmp-options-response-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <response-code>200</response-code>
        <response-string>success</response-string>
        <ccmp:optionsResponse>
           <options>
              <standard-message-list>
                 <standard-message>
                    <name>blueprintsRequest</name>
                 </standard-message>
                 <standard-message>
                   <name>blueprintRequest</name>
                   <operations>
                     <operation>retrieve</operation>
                   </operations>
                 </standard-message>
                 <standard-message>
                   <name>confsRequest</name>
                 </standard-message>
                 <standard-message>
                   <name>confRequest</name>
                 </standard-message>
                 <standard-message>
                    <name>usersRequest</name>
                 </standard-message>
                 <standard-message>
                    <name>userRequest</name>
                 </standard-message>
                 <standard-message>
                    <name>sidebarsByRefRequest</name>
                 </standard-message>
                 <standard-message>
                    <name>sidebarByRefRequest</name>
                 </standard-message>
              </standard-message-list>
              <extended-message-list>

                 <extended-message>
                    <name>confSummaryRequest</name>
                    <operations>
                      <operation>retrieve</operation>
                    </operations>
                    <schema-def>
                         http://example.com/ccmp-extension-schema.xsd
                    </schema-def>
                    <description>
                         confSummaryRequest is intended
                         to allow the requestor to retrieve
                         a brief description
                         of the conference indicated in the
                         confObjID request parameter
                    </description>
                 </extended-message>
              </extended-message-list>
           </options>
        </ccmp:optionsResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

Figure 26: Alice Asks for the Server Control Capabilities

6.9. Alice Makes Use of a CCMP Server Extension 🎀

in this section we get a super simple example of CCMP extension support 💖 Alice can find out about this extension, and any other server-supported extensions, by sending an optionsRequest (see Section 6.8) 🫶

the extension is called "confSummaryRequest", and it lets a CCMP client grab synthetic information about a specific conference from the CCMP server ✨ the conference summary comes wrapped in an XML element, like this:

<?xml version="1.0" encoding="UTF-8"?>
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://example.com/ccmp-extension"
            xmlns="http://example.com/ccmp-extension">

  <xs:element name="confSummary" type="conf-summary-type"/>

  <xs:complexType name="conf-summary-type">
    <xs:sequence>
      <xs:element name="title" type="xs:string"/>
      <xs:element name="status" type="xs:string"/>
      <xs:element name="public" type="xs:boolean"/>
      <xs:element name="media" type="xs:string"/>

    </xs:sequence>
  </xs:complexType>

</xs:schema>

Figure 27: Example of XML Schema defining an extension parameter (ccmp-extension-schema.xsd)

as you can tell from the schema file, the <confSummary> element holds conference info about these things:

title
status (active or registered)
participation modality (if everyone is allowed to participate, the boolean <public> element is set to "true") 💅
involved media

so if Alice wants a conference summary for the conference she's in, she sends the CCMP server an extendedRequest with a "confSummaryRequest" <extensionName>, and she puts the conference XCON-URI in the confObjID request parameter. the figure below shows how it goes 🧚‍♀️

CCMP Client                                             CCMP Server
     |                                                       |
     | CCMP extendedRequest message                          |
     |   - confUserID: Alice                                 |
     |   - confObjID: 8977794                                |
     |   - operation: retrieve                               |
     |   - extensionName: confSummaryRequest                 |
     |------------------------------------------------------>|
     |                                                       |
     |                      CCMP extendedResponse message    |
     |                            - confUserID: Alice        |
     |                            - confObjID: 8977794       |
     |                            - operation: retrieve      |
     |                            - response-code: 200       |
     |                            - extensionName:           |
     |                              confSummaryRequest       |
     |                            - confSummary              |
     |<------------------------------------------------------|
     |                                                       |
     .                                                       .
     .                                                       .

extendedRequest (Alice makes use of the "confSummaryRequest")

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
        xmlns:example="http://example.com/ccmp-extension">
    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-extended-request-message-type">
        <confUserID>xcon-userid:alice@example.com</confUserID>
        <confObjID>xcon:8977794@example.com</confObjID>
        <operation>retrieve</operation>
        <ccmp:extendedRequest>
               <extensionName>confRequestSummary</extensionName>
        </ccmp:extendedRequest>
    </ccmpRequest>
  </ccmp:ccmpRequest>

extendedResponse (the server provides Alice with a brief description of the desired conference)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
          xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
          xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
          xmlns:example="http://example.com/ccmp-extension">
    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-extended-response-message-type">
         <confUserID>xcon-userid:alice@example.com</confUserID>
         <confObjID>xcon:8977794@example.com</confObjID>
         <operation>retrieve</operation>
         <response-code>200</response-code>
         <response-string>success</response-string>
         <ccmp:extendedResponse>
           <extensionName>confSummaryRequest</extensionName>
           <example:confSummary>
               <title> Alice's conference </title>
               <status> active </status>
               <public> true </public>
               <media> audio </media>
           </example:confSummary>
         </ccmp:extendedResponse>
    </ccmpResponse>
  </ccmp:ccmpResponse>

Figure 28: Alice Exploits the 'confSummaryRequest' Extension

7. Locating a Conference Server ✨

okay so if a conferencing client isn't pre-configured to use a specific conference server, the client MUST first discover the conference server before it can send any requests 🧚. the result of that discovery is the address of the server that supports conferencing. in this document, that result is an http: or https: URI that identifies a conference server 🔍.

DNS is RECOMMENDED for locating a conference server when the client isn't pre-configured to use one 💖. URI-Enabled NAPTR (U-NAPTR) resolution for conferencing takes a domain name as input and produces a URI that identifies the conference server. it also needs an Application Service tag and an Application Protocol tag, which keep the conferencing-related NAPTR records separate from the other records for that domain 🎀.

Section 12.4.1 defines an Application Service tag of "XCON", which identifies the centralized conferencing (XCON) server for a particular domain 👑. the Application Protocol tag "CCMP", defined in Section 12.4.2, identifies an XCON server that understands CCMP ✨.

the NAPTR records in the example below (Figure 29) show how those tags are used 🦋. iterative NAPTR resolution delegates responsibility for the conferencing service from "zonea.example.com." and "zoneb.example.com." over to "outsource.example.com." 💅.

          zonea.example.com.
          ;;       order pref flags
          IN NAPTR 100   10   ""  "XCON-CCMP" (     ; service
          ""                                        ; regex
          outsource.example.com.                    ; replacement
          )
          zoneb.example.com.
          ;;       order pref flags
          IN NAPTR 100   10   ""  "XCON-CCMP" (     ; service
          ""                                        ; regex
          outsource.example.com.                    ; replacement
          )
          outsource.example.com.
          ;;       order pref flags
          IN NAPTR 100   10   "u"  "XCON-CCMP" (    ; service
          "!*.!https://confs.example.com/!"         ; regex
          .                                         ; replacement
          )

          Figure 29: Sample XCON-CCMP Service NAPTR Records

the details for the "XCON" Application Service tag and the "CCMP" Application Protocol tag are in Section 12.4 🌸.

8. Managing Notifications 🔔

okay so as per [RFC5239], CCMP is one of four protocols that have been formally identified within the XCON framework 🌈:

Conference Control Protocol: mediates between the conference and media control client (conferencing client) and the conference server. this document describes this protocol 💜.
Binary floor Control Protocol: operates between the floor control client and the floor control server. an example is the Binary Floor Control Protocol (BFCP), specified in [RFC4582] 🍓.
Call Signaling Protocol: operates between the Call Signaling Client and the focus. examples include SIP, H.323 and IAX. these protocols can negotiate a conferencing session 📞.
Notification Protocol: operates between the Notification Client and the XCON Notification Service. this specification does not define a new notification protocol. for clients that use SIP as the call signaling protocol, the XCON event package [RFC6502] MUST be used by the client for notifications of changes in the conference data, as described below 🔥.

the protocol in this document is a proactive one 🫶. a conferencing client uses it to send requests to a conference server, to retrieve info about the conference objects the server stores and possibly change them. however, a complete conferencing solution is not prohibited from giving clients a way to receive asynchronous updates about the status of the objects on the server 🦋. the notification protocol is conceptually independent of all the companion protocols mentioned above, but it can still be chosen to fit the overall protocol architecture of a specific deployment, as discussed below ✨.

when the conferencing control client uses SIP [RFC3261] as its signaling protocol to participate in the conference, SIP event notification can be used. in that case, the conferencing control client MUST implement the conference event package for XCON [RFC6502] 💖. this is the default mechanism for conferencing clients, just as SIP is the default for signaling under the XCON framework [RFC5239] 👑.

the interface to the conference server might be entirely web based. in that case there's a common mechanism for web-based systems called a "call back" 🙈. with it, the conferencing client gives the conference server an HTTP URL that gets invoked whenever a change occurs. this is a common implementation mechanism for e-commerce. it works well when the conferencing client is a web server that provides the graphical HTML user interface and uses CCMP as the back-end interface to the conference server 💅.

this model can coexist with the SIP event notification model 🌸. PC-based clients behind NATs could provide a SIP event URI, whereas web-based clients using CCMP in the back end would probably find the HTTP call back approach much easier 🧚. the details of this approach are out of scope for CCMP, so we expect a future specification to document this solution 🎀.

9. HTTP Transport 🚚

this section describes HTTP [RFC2616] and HTTP over TLS [RFC2818] as transport mechanisms for CCMP 💜. a conforming conference server and conferencing client MUST support them 🔥.

okay, so CCMP uses HTTP as a transport, but it only uses a strict subset of HTTP features 💅. because some features are restricted, a conference server might not be a fully compliant HTTP server 🙈. the goal is that a conference server can easily be built on top of an HTTP server with extensibility mechanisms, and that a conferencing client can trivially use existing HTTP libraries 🫶. this subset of requirements helps implementers avoid ambiguity with all the options full HTTP offers ✨.

support for HTTP authentication [RFC2617] and cookies [RFC6265] is OPTIONAL for a conferencing client that conforms to this specification 🌈. these mechanisms are unnecessary because CCMP requests carry their own authentication information (in the "subject" field; see Section 5.1) 💖. a conferencing client SHOULD include support for HTTP proxy authentication 🍓.

a CCMP request is carried in the body of an HTTP POST request 🦋. the conferencing client MUST include a Host header in the request 🎀.

the MIME type of CCMP request and response bodies is "application/ccmp+xml" 💅. the conference server and conferencing client MUST provide this value in the HTTP Content-Type and Accept header fields 👑. if the conference server doesn't receive the appropriate Content-Type and Accept header fields, it SHOULD fail the request and return a 406 (Not Acceptable) response 😭. CCMP responses SHOULD include a Content-Length header 🌸.

conferencing clients MUST NOT use the Expect header or the Range header in CCMP requests 🙅. the conference server MAY return 501 (Not Implemented) errors if either of these HTTP features is used 💀. if the conference server receives a request from the conferencing client containing an If-* (conditional) header, it SHOULD return a 412 (precondition failed) response ✨.

the POST method is the only method REQUIRED for CCMP 🔥. if a conference server chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET 🧐. since a conferencing client only uses POST, the GET or HEAD MUST be either a URL that was found outside its normal context (e.g., somebody found a URL in protocol traces or log files and fed it into their browser), or somebody testing or debugging a system 🕵️‍♀️. the conference server could put information in the CCMP response saying the URL corresponds to a conference server that only responds to CCMP POST requests 🎀. or it could try to avoid leaking information by returning a very generic HTTP error message such as 405 (Method Not Allowed) 🙈.

the conference server populates the HTTP headers of responses so they match the contents of the message 💖. in particular, the CacheControl header SHOULD be set to disable caching of any conference information by HTTP intermediaries 🫣. otherwise there's a risk of stale information and/or unauthorized disclosure of the information 🚨. the HTTP status code MUST indicate a 2xx series response for all CCMP Response and Error messages ✅.

the conference server MAY redirect a CCMP request 🦋. a conference server MUST NOT include CCMP responses in a 3xx response 🙅. a conferencing client MUST handle redirects by using the Location header the server provides in a 3xx response 🌈. when redirecting, the conferencing client MUST observe the delay indicated by the Retry-After header ⏳. the conferencing client MUST authenticate the server that returns the redirect response before following the redirect 🔐. a conferencing client SHOULD authenticate the conference server indicated in a redirect 🫶.

the conference server SHOULD support persistent connections and request pipelining 💜. if pipelining isn't supported, the conference server MUST NOT allow persistent connections 🚫. the conference server MUST support termination of a response by closing the connection 💅.

implementations of CCMP that use HTTP transport MUST implement transport over TLS [RFC2818] 🔒. TLS provides message integrity and confidentiality between the conferencing client and the conference server 🥰. the conferencing client MUST implement the server authentication method described in HTTPS [RFC2818] 🛡️. the device uses the URI obtained during conference server discovery to authenticate the server 🔍. the details of this authentication method are in Section 3.1 of HTTPS [RFC2818] 📖. when TLS is used, the conferencing client SHOULD fail a request if server authentication fails 💀.

10. Security Considerations 🔥

okay bestie, this is the part where we get SERIOUS 😭 The XCON framework [RFC5239] already spilled the tea that conferencing is a lowkey dangerous place. Multiple endpoints, and everyone can poke at the conference data through CCMP 💀 Think: an endpoint sneaking into a call it's not allowed in 👀, an endpoint kicking or muting everyone else 🙅‍♀️, or an endpoint getting free service by making conferences it has no business making. Main character villain energy, and we are NOT here for it 💅

Here's the quick list of security must-knows for CCMP 🎀:

The client MUST determine the proper conference server. Discovery is in Section 7 ✨
The client MUST connect to the proper conference server. The way we handle this is in Section 10.1 🦋
The protocol MUST support a confidentiality and integrity mechanism. As covered in Section 9, implementations of CCMP MUST implement the HTTP transport over TLS [RFC2818] 🔐
There are security issues around who's allowed to do what on the conferencing system and which capabilities they can call. A conference server SHOULD make sure only authorized entities can change the conference data. Details are in Section 10.2 👑
The privacy and security of a user's identity in the conference MUST be assured 🫶
Last but not least, DoS attacks on the conference server itself 😩 How to minimize how likely these are and how bad they hit is in Section 10.4 🛡️

Items 1 and 3 are already handled in the sections we covered earlier in this doc 💖 The rest get the full deep dive in the sections below 🌸

10.1. Assuring That the Proper Conference Server Has Been Contacted 🔐

Section 7 walks through how a conferencing client finds a conference server using DNS 🧚 The big worry here is spoofed DNS replies (yikes 🙈), so using DNS Security (DNSSEC) is RECOMMENDED. That way the client gets a valid answer from the DNS server, at least in cases where that matters 🍓

When the CCMP transaction runs over TLS [RFC5246], the conference server can prove who it is to the client, either as a domain name or as an IP address 🌈 It does this by showing a certificate that has that identifier in its subjectAltName (so as an iPAddress or a dNSName, respectively) ✨ Any CCMP implementation MUST be able to run over TLS so the client can ask for that authentication 💜 Now, for the certificate to count as valid at the client, the client MUST be able to validate it by following the procedures in [RFC2818] when HTTP is the transport 🫶 The big rule is that the certificate's validation path has to end at one of the client's trust anchors, and that anchor can even be the conference server certificate itself 🔥 If the client already has outside info about the expected identity or credentials of the proper conference server, the checks above MAY be skipped 🦋

10.2. User Authentication and Authorization 👑

A ton of policy decisions depend on who the user is or what role they have 💅 The conference server MUST implement ways to authenticate users so it can check their identity 🔐 There are a few different ways a user can prove who they are to the system ✨ If someone joins a conference through one of the call signaling protocols, they can use that protocol's own user authentication 🎀 For example, if a user joins with SIP signaling, the user authentication defined in [RFC3261] MUST be used 📞 If someone joins using CCMP, the CCMP Request messages have a subject field with a username and password that can be used for authentication 🧚 And since CCMP messages are RECOMMENDED to be carried over TLS, that info gets sent securely 🔒

The XCON framework [RFC5239] gives an overview of other authorization mechanisms too 🌸 When a user is authorized through several mechanisms at once, it is RECOMMENDED that the conference server ties the authorization of the CCMP interface to those other mechanisms 💖 A good example is PSTN users who join with a PIN and then control the conference using CCMP 📱 When a conference server shows the identity of authorized users, it MAY include info about how that identity was proven or verified 🔍 A conference server can also let a totally unauthenticated user in 👀 and that fact SHOULD be shared with anyone who cares about it 🫶

Once a user gets authenticated and authorized through whatever mechanisms the conference server has, the conference server MUST allocate a conference user identifier (XCON-USERID) 🆔 It SHOULD also link that XCON-USERID to any signaling-specific user identifiers used during authentication and authorization 🔗 The XCON-USERID can be handed to a user through the conference notification interface, and it MUST be provided to users who interact with the system using CCMP (so in the right CCMP response messages) 💌 The XCON-USERIDs for everyone in the conference live in the entity attribute of the <user> element in the conference object 📋 The XCON-USERID is REQUIRED for any later operations a user does on the conference object, and it rides along in the confUserID parameter of CCMP requests and responses 🎀

Quick note: policy management for an XCON-compliant system is out of scope for this doc, and also out of scope for the XCON working group (WG) 🙈 BUT a policy management framework can still be built on top of the overall XCON architecture, especially with a Role-Based Access Control (RBAC) approach 🧠 RBAC has five pieces: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; (v) Permissions 🍰 Every single one of those maps neatly onto an XCON entity 😍 For example, RBAC objects map onto XCON data model objects, and RBAC operations map onto CCMP operations 🦋

Future documents could define an RBAC framework for XCON 🌈 They'd start by defining roles, then spell out the permission policy sets and the role policy sets (the ones that tie permission sets to specific roles) 💜 Once those policies are in place, access to a conference object that follows the XCON data model can be controlled properly ✨ When it comes to assigning users to roles, RBAC Users map directly onto the <users> element in the conference object 🧚 And the <users> element is made up of <user> elements, one for each specific user in the system 🫶

Each <user> element has an entity attribute holding the XCON-USERID, plus a <role> element 💖 So every authorized user, identified by their XCON-USERID, can be linked to a <role> element 👑

10.3. Security and Privacy of Identity 🫶

The XCON framework [RFC5239] has the overview of what privacy and anonymity users in a conferencing system need 🌸 And the security of identity, in the form of the XCON-USERID, comes from running CCMP over TLS 🔐

The conference server SHOULD support a mechanism that keeps the XCON-USERID private 🙈 The conferencing client says what level of privacy it wants by using the <provide-anonymity> element defined in the XCON data model [RFC6501] 🎭 That element controls how much of their identity a user reveals 🕵️‍♀️ Here are the values for <provide-anonymity> that the client can put in its requests 👀

"hidden": Ensures that other participants are not aware that there
is an additional participant (i.e., the user issuing the request)
in the conference.  This could be used in cases of users that are
authorized with a special role in a conference (e.g., a supervisor
in a call center environment).

"anonymous": Ensures that other participants are aware that there
is another participant (i.e., the user issuing the request);
however, the other participants are not provided information as to
the identity of the user.

"semi-private": Ensures that the user's identity is only to be
revealed to other participants or users that have a higher-level
authorization (e.g., a conferencing system can be configured such
that a human administrator can see all users).

Breaking that down, bestie 💅:

"hidden" 🫥 means other participants don't even know there's an extra person (the one making the request) in the call. This could be used for users with a special role, like a supervisor in a call center 🎧
"anonymous" 👻 means others know someone else is there, but they don't get any info on who that person is 🤫
"semi-private" 🌓 means the user's identity is only shown to people with higher-level authorization. A system can be set up so a human admin sees everyone 👩‍💻

If the client wants privacy, the conferencing client SHOULD include the <provide-anonymity> element in the <confInfo> parameter of a CCMP confRequest message whose <operation> parameter is "update" or "create" 🌸 It should also include it in the <userInfo> parameter of a CCMP userRequest message whose <operation> parameter is "update" or "create" 💜 If the <provide-anonymity> element isn't in the conference object, then other users can see the participant's identity 👀 Participants will be told about other participants who are "anonymous" or "semi-private" when they do later operations on the conference object, when they retrieve it, or when they get subsequent notifications 🔔

Heads up though 🚨: no matter what anonymity level the user asks for, the conferencing system always knows who the user is, because it needs that to do the authorization described in Section 10.2 🔑 How much human administrators can see can be controlled with policies, though (for example, some info in the data model can be hidden from them) 🙈

10.4. Mitigating DoS Attacks 🛡️

[RFC4732] gives an overview of the possible DoS attacks 🧨 To lower the chances of a DoS attack, it is RECOMMENDED that conferencing systems require user authentication and authorization for every client taking part in a conference 🔐 You can do this with the mechanisms in Section 10.2, plus the security mechanisms that come with the specific signaling (like Session Initiation Protocol Secure (SIPS)) and media protocols (like Secure Realtime Transport Protocol (SRTP)) 💖 Also, Section 4.4 describes a timer mechanism for the situation where CCMP messages pend indefinitely, which can make pending requests keep piling up when a server is receiving more requests than it can process 😩 That timer is the fix for that pile-up 🫶

11. XML Schema 💅✨

bestie, this section is the official XML schema definition (🎀 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]) for the "application/ccmp+xml" format. It's basically the formal definition of that format, so it's giving precision. Also, a new XML namespace, a new XML schema, and the MIME type for this schema get registered with IANA, which is covered in Section 12 🦋. Heads up: this XML Schema Definition is NOT meant for on-the-fly validation of the presence XML document 🙈. The whitespace is in there so the lines fit the RFC line length limits, and it doesn't hurt readability one bit 💖. Any conforming processor should remove leading and trailing white spaces 🧹.

<?xml version="1.0" encoding="utf-8"?>

   <xs:schema
      targetNamespace="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:tns="urn:ietf:params:xml:ns:xcon-ccmp"
      xmlns:dm="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">


      <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
                 schemaLocation="DataModel.xsd"/>
      <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
                 schemaLocation="rfc4575.xsd"/>

      <xs:element name="ccmpRequest" type="ccmp-request-type" />
      <xs:element name="ccmpResponse" type="ccmp-response-type" />

<!-- CCMP request definition -->

   <xs:complexType name="ccmp-request-type">
       <xs:sequence>
           <xs:element name="ccmpRequest"
                       type="ccmp-request-message-type" />
       </xs:sequence>
   </xs:complexType>
   <!-- ccmp-request-message-type -->

   <xs:complexType abstract="true"
                   name="ccmp-request-message-type">
       <xs:sequence>
           <xs:element name="subject" type="subject-type"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="confUserID" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="confObjID" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="operation" type="operationType"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="conference-password" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

<!-- CCMP response definition -->

   <xs:complexType name="ccmp-response-type">
       <xs:sequence>
           <xs:element name="ccmpResponse"
                       type="ccmp-response-message-type" />
       </xs:sequence>
   </xs:complexType>

   <!-- ccmp-response-message-type -->

   <xs:complexType abstract="true" name="ccmp-response-message-type">
       <xs:sequence>
           <xs:element name="confUserID" type="xs:string"
                       minOccurs="1" maxOccurs="1" />
           <xs:element name="confObjID" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="operation" type="operationType"
                       minOccurs="0"
                       maxOccurs="1" />
           <xs:element name="response-code"
                       type="response-codeType"
                       minOccurs="1" maxOccurs="1" />
           <xs:element name="response-string" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="version" type="xs:positiveInteger"
                       minOccurs="0" maxOccurs="1" />

           <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

okay the requests section is where the schema gets really structured 💅✨

<!-- CCMP REQUESTS -->

   <!-- blueprintsRequest -->

   <xs:complexType name="ccmp-blueprints-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintsRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- blueprintsRequestType -->

   <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>

   <xs:complexType name="blueprintsRequestType">
       <xs:sequence>
           <xs:element name="xpathFilter" type="xs:string"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!--  blueprintRequest -->

   <xs:complexType name="ccmp-blueprint-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>
   <!-- blueprintRequestType -->

   <xs:element name="blueprintRequest" type="blueprintRequestType" />

   <xs:complexType name="blueprintRequestType">
       <xs:sequence>
           <xs:element name="blueprintInfo"
                       type="info:conference-type" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- confsRequest -->

   <xs:complexType name="ccmp-confs-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="confsRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- confsRequestType -->

   <xs:element name="confsRequest" type="confsRequestType" />
   <xs:complexType name="confsRequestType">
       <xs:sequence>
           <xs:element name="xpathFilter" type="xs:string"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- confRequest -->

   <xs:complexType name="ccmp-conf-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="confRequest" />
               </xs:sequence>
           </xs:extension>

       </xs:complexContent>
    </xs:complexType>

   <!-- confRequestType -->

   <xs:element name="confRequest" type="confRequestType" />

   <xs:complexType name="confRequestType">
       <xs:sequence>
           <xs:element name="confInfo" type="info:conference-type"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- usersRequest -->

   <xs:complexType name="ccmp-users-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="usersRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- usersRequestType -->

   <xs:element name="usersRequest" type="usersRequestType" />

   <xs:complexType name="usersRequestType">
       <xs:sequence>
           <xs:element name="usersInfo" type="info:users-type"
                       minOccurs="0" />
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

   <!-- userRequest -->

   <xs:complexType name="ccmp-user-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">

               <xs:sequence>
                   <xs:element ref="userRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- userRequestType -->

   <xs:element name="userRequest" type="userRequestType" />

   <xs:complexType name="userRequestType">
       <xs:sequence>
           <xs:element name="userInfo" type="info:user-type"
                       minOccurs="0" />
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- sidebarsByValRequest -->

   <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="sidebarsByValRequest" />
                </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

    <!-- sidebarsByValRequestType -->

    <xs:element name="sidebarsByValRequest"
                type="sidebarsByValRequestType" />

    <xs:complexType name="sidebarsByValRequestType">
        <xs:sequence>
            <xs:element name="xpathFilter"
                        type="xs:string" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>
    <!-- sidebarsByRefRequest -->

    <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarsByRefRequest" />
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

   <!-- sidebarsByRefRequestType -->

   <xs:element name="sidebarsByRefRequest"
               type="sidebarsByRefRequestType" />

   <xs:complexType name="sidebarsByRefRequestType">
       <xs:sequence>
           <xs:element name="xpathFilter" type="xs:string"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- sidebarByValRequest -->

   <xs:complexType name="ccmp-sidebarByVal-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="sidebarByValRequest" />
               </xs:sequence>
            </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- sidebarByValRequestType -->

   <xs:element name="sidebarByValRequest"
               type="sidebarByValRequestType"/>

   <xs:complexType name="sidebarByValRequestType">
       <xs:sequence>
           <xs:element name="sidebarByValInfo"
                       type="info:conference-type" minOccurs="0"/>

           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
   <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- sidebarByRefRequest -->

   <xs:complexType name="ccmp-sidebarByRef-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="sidebarByRefRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- sidebarByRefRequestType -->

   <xs:element name="sidebarByRefRequest"
               type="sidebarByRefRequestType" />

   <xs:complexType name="sidebarByRefRequestType">
       <xs:sequence>
           <xs:element name="sidebarByRefInfo"
                       type="info:conference-type" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- extendedRequest -->

   <xs:complexType name="ccmp-extended-request-message-type">
      <xs:complexContent>
          <xs:extension base="tns:ccmp-request-message-type">
             <xs:sequence>
                         <xs:element ref="extendedRequest"/>
             </xs:sequence>
          </xs:extension>
      </xs:complexContent>
   </xs:complexType>
   <!-- extendedRequestType -->

   <xs:element name="extendedRequest" type="extendedRequestType"/>

   <xs:complexType name="extendedRequestType">
     <xs:sequence>
        <xs:element name="extensionName"
                    type="xs:string" minOccurs="1"/>
        <xs:any namespace="##other" processContents="lax" minOccurs="0"
                           maxOccurs="unbounded" />
    </xs:sequence>
   </xs:complexType>

   <!-- optionsRequest -->

        <xs:complexType name="ccmp-options-request-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

Okay bestie, we're deep in the XML schema now, and this part is all about the CCMP responses 💖✨ Every response type follows the same pattern: a message type that extends ccmp-response-message-type, plus a matching element and its own type. It's giving very organised energy 💅

<!-- CCMP RESPONSES -->

   <!-- blueprintsResponse -->

   <xs:complexType name="ccmp-blueprints-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintsResponse" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

   <!-- blueprintsResponseType -->

   <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>

   <xs:complexType name="blueprintsResponseType">
       <xs:sequence>
           <xs:element name="blueprintsInfo" type="info:uris-type"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

   <!-- blueprintResponse -->

   <xs:complexType name="ccmp-blueprint-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintResponse" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
    </xs:complexType>

    <!-- blueprintResponseType -->

    <xs:element name="blueprintResponse" type="blueprintResponseType"/>

    <xs:complexType name="blueprintResponseType">
        <xs:sequence>
          <xs:element name="blueprintInfo" type="info:conference-type"
                        minOccurs="0"/>
          <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- confsResponse -->

    <xs:complexType name="ccmp-confs-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="confsResponse" />
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- confsResponseType -->

    <xs:element name="confsResponse" type="confsResponseType" />

    <xs:complexType name="confsResponseType">
        <xs:sequence>
            <xs:element name="confsInfo" type="info:uris-type"

                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- confResponse -->

    <xs:complexType name="ccmp-conf-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="confResponse"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- confResponseType -->

    <xs:element name="confResponse" type="confResponseType" />

    <xs:complexType name="confResponseType">
        <xs:sequence>
            <xs:element name="confInfo" type="info:conference-type"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- usersResponse -->

    <xs:complexType name="ccmp-users-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="usersResponse" />
                </xs:sequence>
            </xs:extension>
         </xs:complexContent>
    </xs:complexType>
    <!-- usersResponseType -->

    <xs:element name="usersResponse" type="usersResponseType" />

    <xs:complexType name="usersResponseType">
        <xs:sequence>
            <xs:element name="usersInfo" type="info:users-type"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- userResponse -->

    <xs:complexType name="ccmp-user-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="userResponse" />
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- userResponseType -->

    <xs:element name="userResponse" type="userResponseType" />

    <xs:complexType name="userResponseType">
        <xs:sequence>
            <xs:element name="userInfo" type="info:user-type"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- sidebarsByValResponse -->

    <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarsByValResponse" />
                </xs:sequence>

            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- sidebarsByValResponseType -->

    <xs:element name="sidebarsByValResponse"
                type="sidebarsByValResponseType" />

    <xs:complexType name="sidebarsByValResponseType">
        <xs:sequence>
            <xs:element name="sidebarsByValInfo"
                        type="info:sidebars-by-val-type" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- sidebarsByRefResponse -->

    <xs:complexType name="ccmp-sidebarsByRef-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarsByRefResponse" />
                </xs:sequence>
            </xs:extension>
       </xs:complexContent>
    </xs:complexType>

    <!-- sidebarsByRefResponseType -->

    <xs:element name="sidebarsByRefResponse"
                type="sidebarsByRefResponseType" />

    <xs:complexType name="sidebarsByRefResponseType">
        <xs:sequence>
            <xs:element name="sidebarsByRefInfo" type="info:uris-type"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>
    <!-- sidebarByValResponse -->

    <xs:complexType name="ccmp-sidebarByVal-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarByValResponse" />
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- sidebarByValResponseType -->

    <xs:element name="sidebarByValResponse"
                type="sidebarByValResponseType" />

    <xs:complexType name="sidebarByValResponseType">
        <xs:sequence>
            <xs:element name="sidebarByValInfo"
                        type="info:conference-type" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- sidebarByRefResponse -->

    <xs:complexType name="ccmp-sidebarByRef-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarByRefResponse" />
                 </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- sidebarByRefResponseType -->

    <xs:element name="sidebarByRefResponse"
                type="sidebarByRefResponseType" />

    <xs:complexType name="sidebarByRefResponseType">
        <xs:sequence>
            <xs:element name="sidebarByRefInfo"
                        type="info:conference-type" minOccurs="0"/>

            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- extendedResponse -->

    <xs:complexType name="ccmp-extended-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                                 <xs:element ref="extendedResponse"/>
               </xs:sequence>
           </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- extendedResponseType -->

    <xs:element name="extendedResponse" type="extendedResponseType"/>

    <xs:complexType name="extendedResponseType">
        <xs:sequence>
                <xs:element name="extensionName"
                            type="xs:string" minOccurs="1"/>
                <xs:any namespace="##other" processContents="lax"
                        minOccurs="0"
                    maxOccurs="unbounded" />
        </xs:sequence>
    </xs:complexType>

    <!-- optionsResponse -->

        <xs:complexType name="ccmp-options-response-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                <xs:sequence>
                    <xs:element ref="optionsResponse"/>
                 </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <!-- optionsResponseType -->

    <xs:element name="optionsResponse"
                type="optionsResponseType" />

    <xs:complexType name="optionsResponseType">
        <xs:sequence>
            <xs:element name="options"
                        type="options-type" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- CCMP ELEMENT TYPES -->

    <!-- response-codeType-->

    <xs:simpleType name="response-codeType">
         <xs:restriction base="xs:positiveInteger">
                 <xs:pattern value="[0-9][0-9][0-9]" />
         </xs:restriction>
    </xs:simpleType>

    <!-- operationType -->

    <xs:simpleType name="operationType">
      <xs:restriction base="xs:token">
        <xs:enumeration value="retrieve"/>
        <xs:enumeration value="create"/>
        <xs:enumeration value="update"/>
        <xs:enumeration value="delete"/>
      </xs:restriction>
    </xs:simpleType>

   <!-- subject-type -->

   <xs:complexType name="subject-type">
       <xs:sequence>
           <xs:element name="username" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:element name="password" type="xs:string"
                       minOccurs="0" maxOccurs="1" />
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
   <!-- options-type -->

    <xs:complexType name="options-type">
      <xs:sequence>
        <xs:element name="standard-message-list"
                    type="standard-message-list-type"
                    minOccurs="1"/>
        <xs:element name="extended-message-list"
                    type="extended-message-list-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- standard-message-list-type -->

    <xs:complexType name="standard-message-list-type">
      <xs:sequence>
        <xs:element name="standard-message"
                    type="standard-message-type"
                    minOccurs="1" maxOccurs="10"/>
        <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- standard-message-type -->

    <xs:complexType name="standard-message-type">
      <xs:sequence>
        <xs:element name="name"
                    type="standard-message-name-type"
                    minOccurs="1"/>
        <xs:element name="operations"
                    type="operations-type"
                    minOccurs="0"/>
        <xs:element name="schema-def" type="xs:string" minOccurs="0"/>
        <xs:element name="description" type="xs:string" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>
    <!-- standard-message-name-type -->

    <xs:simpleType name="standard-message-name-type">
      <xs:restriction base="xs:token">
        <xs:enumeration value="confsRequest"/>
        <xs:enumeration value="confRequest"/>
        <xs:enumeration value="blueprintsRequest"/>
        <xs:enumeration value="blueprintRequest"/>
        <xs:enumeration value="usersRequest"/>
        <xs:enumeration value="userRequest"/>
        <xs:enumeration value="sidebarsByValRequest"/>
        <xs:enumeration value="sidebarByValRequest"/>
        <xs:enumeration value="sidebarsByRefRequest"/>
        <xs:enumeration value="sidebarByRefRequest"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- operations-type -->

    <xs:complexType name="operations-type">
      <xs:sequence>
        <xs:element name="operation" type="operationType"
                    minOccurs="1" maxOccurs="4"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- extended-message-list-type -->

    <xs:complexType name="extended-message-list-type">
      <xs:sequence>
        <xs:element name="extended-message"
                    type="extended-message-type"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- extended-message-type -->

    <xs:complexType name="extended-message-type">
      <xs:sequence>
        <xs:element name="name" type="xs:string" />
        <xs:element name="operations"
                    type="operations-type"
                    minOccurs="0"/>

        <xs:element name="schema-def" type="xs:string" />
        <xs:element name="description"
                    type="xs:string"
                    minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

 </xs:schema>

                        Figure 30: CCMP XML Schema

12. IANA Considerations 🦋

Okay bestie, this is the part where we tell IANA what we registered 📋✨. We're adding a new XML namespace, a new XML schema, and the MIME type for that schema 🎀. We're also registering the "XCON" Application Service tag and the "CCMP" Application Protocol tag 🌸, and we're setting up registries for CCMP operation types and response codes 💜.

12.1. URN Sub-Namespace Registration 🌸

Here we register a brand new XML namespace, urn:ietf:params:xml:ns:xcon-ccmp 💖.

URI: urn:ietf:params:xml:ns:xcon-ccmp
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com) 🧚
XML:

   BEGIN
     <?xml version="1.0"?>
     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
       <head>
         <title>CCMP Messages</title>
       </head>
       <body>
         <h1>Namespace for CCMP Messages</h1>
         <h2>urn:ietf:params:xml:ns:xcon-ccmp</h2>
         <p>See <a href="http://www.rfc-editor.org/rfc/rfc6503.txt">
            RFC 6503</a>.</p>
       </body>
     </html>
   END

12.2. XML Schema Registration 🎀

This section registers an XML schema following the guidelines in [RFC3688] 📝. It's giving organised and tidy 💅.

URI: urn:ietf:params:xml:schema:xcon-ccmp
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com) 🫶
Schema: The XML for this schema is the entirety of Section 11 of this document 🔥

12.3. MIME Media Type Registration for 'application/ccmp+xml' 💅

Now we register the application/ccmp+xml MIME type 🌈. Here's the full template, bestie:

To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application
MIME subtype name: ccmp+xml
Required parameters: (none)
Optional parameters: charset. This is the same as the charset parameter of application/xml as specified in [RFC3023], Section 3.2 🦋
Encoding considerations: Same as the encoding considerations of application/xml as specified in [RFC3023], Section 3.2 ✨
Security considerations: Okay, this one matters 😭. This content type is designed to carry protocol data related to conference control, and some of that data could be considered private 🙈. This media type does not provide any protection on its own, so other mechanisms such as those described in Section 10 are required to protect the data 🔒. The good news is that this media type does not contain executable content 💜.
Interoperability considerations: None.
Published specification: RFC 6503.
Applications that use this media type: Centralized Conferencing control clients and servers 🧚
Additional Information:
- Magic Number(s): (none)
- File extension(s): .ccmp
- Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: Mary Barnes <mary.ietf.barnes@gmail.com> 💌
Intended usage: LIMITED USE 🍓
Author/Change controller: The IETF
Other information: This media type is a specialization of application/xml [RFC3023], so a lot of the considerations described there also apply to application/ccmp+xml 👑

12.4. DNS Registrations 🌈

Quick overview: Section 12.4.1 defines an Application Service tag of "XCON", which identifies the centralized conferencing (XCON) server for a particular domain 🧚. The Application Protocol tag "CCMP", defined in Section 12.4.2, identifies an XCON server that understands CCMP ✨.

12.4.1. Registration of a Conference Server Application Service Tag 🦋

This section registers a new S-NAPTR/U-NAPTR Application Service tag for XCON, as mandated by [RFC3958] 💖.

Application Service Tag: XCON
Intended usage: Identifies a server that supports centralized conferencing.
Defining publication: RFC 6503
Contact information: The authors of this document
Author/Change controller: The IESG

12.4.2. Registration of a Conference Server Application Protocol Tag for CCMP 🎀

This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for CCMP, as mandated by [RFC3958] 🫶.

Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Manipulation Protocol.
Applicable Service Tag(s): XCON
Terminal NAPTR Record Type(s): U
Defining Publication: RFC 6503
Contact Information: The authors of this document
Author/Change Controller: The IESG

12.5. CCMP Protocol Registry 👑

IANA has set up a new registry for CCMP at http://www.iana.org/assignments/ccmp-parameters 🌸. This document creates the initial sub-registries for CCMP operation types and response codes, so the registry is ready to go and it's giving main character energy 🧚💅.

12.5.1. CCMP Message Types ✨

Okay so this is the message registry, bestie 💖 It's the list of every CCMP message type, what each one is for, and which RFC defines it 📋

Related Registry: CCMP Message Types Registry

Defining RFC: RFC 6503.

Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the CCMP message types for CCMP is Specification Required. 🔒

Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com). 💌

This specification sets up the Message sub-registry under http://www.iana.org/assignments/ccmp-messages. The starter Message table is filled with the CCMP messages from Section 4.1, which are defined in the XML schema in Section 11. So they're all in there, no cap 🫶

  Message              Description                             Reference
  -------              -----------                             ---------
  optionsRequest       Used by a conferencing client           [RFC6503]
                       to query a conference server for
                       its capabilities, in terms of
                       supported messages.

  optionsResponse      Returns a list of CCMP messages         [RFC6503]
                       supported by the specific
                       conference server.

  blueprintsRequest    Used by a conferencing client           [RFC6503]
                       to query a conference server for
                       its capabilities, in terms of
                       available conference blueprints.

  blueprintsResponse   Returns a list of blueprints supported  [RFC6503]
                       by the specific conference server.

  blueprintRequest     Sent to retrieve the conference object  [RFC6503]
                       associated with a specific blueprint.

  blueprintResponse    Returns the conference object           [RFC6503]
                       associated with a specific blueprint.

  confsRequest         Used by a conferencing client           [RFC6503]
                       to query a conference server for
                       its scheduled/active conferences.

  confsResponse        Returns the list of the currently       [RFC6503]
                       activated/scheduled conferences
                       at the server.

  confRequest          Used to create a conference object      [RFC6503]
                       and/or to request an operation on
                       the conference object as a whole.

  confResponse         Indicates the result of the operation   [RFC6503]
                       on the conference object as a whole.

  userRequest          Used to request an operation on the     [RFC6503]
                       <user> element in the conference object.

  userResponse         Indicates the result of the requested   [RFC6503]
                       operation on the <user> element in
                       the conference object.

  usersRequest         Used to manipulate the <users> element  [RFC6503]
                       in the conference object, including
                       parameters such as the <allowed-users-list>,
                       <join-handling>, etc.

  usersResponse        Indicates the result of the request     [RFC6503]
                       to manipulate the <users> element in
                       the conference object.

  sidebarsByValRequest Used to retrieve the <sidebars-by-val>  [RFC6503]
                       element of the target conference object.

  sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503]
                        conferences within the target
                        conference object.

  sidebarsByRefRequest  Used to retrieve the <sidebars-by-ref> [RFC6503]
                        element of the target conference
                        object.

  sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503]
                        conferences associated with the target
                        conference object.

  sidebarByValRequest  Used to request an operation on a       [RFC6503]
                       sidebar-by-val conference.

  sidebarByValResponse Indicates the result of the request to  [RFC6503]
                       manipulate a sidebar-by-val conference.

  sidebarByRefRequest  Used to request an operation on a       [RFC6503]
                       sideber-by-ref conference.

  sidebarByRefResponse Indicates the result of the request to  [RFC6503]
                       manipulate a sidebar-by-ref conference.

12.5.2. CCMP Response Codes ✨

Next up are the response codes, the little status numbers that tell you how a request went 🎀

Related Registry: CCMP Response Code Registry

Defining RFC: RFC 6503.

Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the Response codes for CCMP shall be Specification Required. 🔒

Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com). 💌

This specification sets up the Response-code sub-registry under http://www.iana.org/assignments/ccmp-parameters. The starter Response-code table is filled with the response codes from Section 5.4, laid out like this 🌸

         Default
         Response
  Number String              Description                       Reference
  ------ -------------       ------------                      ---------
   200   Success             The request was successfully      [RFC6503]
                             processed.

   400   Bad Request         The request was badly formed in   [RFC6503]
                             some fashion.

   401   Unauthorized        The user was not authorized for   [RFC6503]
                             the specific operation on the
                             conference object.

   403   Forbidden           The specific operation is not     [RFC6503]
                             valid for the target conference
                             object.

   404   Object Not Found    The specific conference object    [RFC6503]
                             was not found.

   409   Conflict            A requested operation cannot be   [RFC6503]
                             successfully completed by the
                             server. For example, the
                             modification of an object
                             cannot be applied because
                             the client version of the object
                             is obsolete and the requested
                             modifications collide with the
                             up-to-date state of the object
                             stored at the server.

   420   User Not Found      The user who is the target of the [RFC6503]
                             requested operation is unknown.

   421   Invalid confUserID  The <confUserID> parameter of the [RFC6503]
                             sender in the request is invalid.


   422   Invalid Conference  A request to access/manipulate    [RFC6503]
         Password            a password-protected conference
                             object contained an invalid
                             <conference-password> parameter.

   423   Conference Password A request to access/manipulate    [RFC6503]
         Required            a password-protected conference
                             object did not contain a
                             <conference-password> parameter.

   424   Authentication      The server wants to authenticate  [RFC6503]
         Required            the request through the <subject>
                             parameter but the parameter is
                             not provided in the request.

   425   Forbidden Delete    The conferencing system cannot    [RFC6503]
         Parent              delete the specific conference
                             object because it is a
                             parent for another conference object.

   426   Forbidden Change    The target conference object      [RFC6503]
         Protected           cannot be changed (e.g., due to
                             policies, roles or privileges).

   427   Invalid Domain Name The domain name in an             [RFC6503]
                             AUTO_GENERATE_X
                             instance in the conference object
                             is not within the conference
                             server's domain of responsibility.

   500   Server Internal     The conference server experienced [RFC6503]
         Error               some sort of internal error.

   501   Not Implemented     The specific operation is not     [RFC6503]
                             implemented on the conferencing
                             system.

   510   Request Timeout     The request could not be          [RFC6503]
                             processed within a reasonable
                             time (as specified by the
                             conferencing system).

   511   Resources Not       The conference server cannot      [RFC6503]
         Available           execute a command because of
                             resource issues, e.g., it cannot
                             create a conference because
                             the system has reached its limits
                             on the number of conferences.

13. Acknowledgments 🫶

The authors are so grateful for the feedback from Dave Morgan, Pierre Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage, Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian Carpenter (genart review), and Mykyta Yevstifeyev (IANA considerations) 💜 Special shoutout to Roberta Presta, who made a huge contribution to this document 👑 Roberta worked on the CCMP specification at the University of Napoli for her Master thesis. She also built the CCMP prototype used for the trials, and the dumps in Section 6 were pulled from it 🧚

14. References ✨

14.1. Normative References

Okay bestie, the reference list is where the receipts live 🧾✨ These are the docs this one needs you to have read, so no skipping, no cap:

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
[W3C.REC-xmlschema-1-20041028] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028.
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028.

14.2. Informative References

These ones are the background reading 📚🌸 Super helpful, not strictly required to build the thing:

[REST] Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.
[W3C.REC-soap12-part1-20070427] Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M., Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, http://www.w3.org/TR/2007/REC-soap12-part1-20070427.
[W3C.REC-soap12-part2-20070427] Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N., Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, http://www.w3.org/TR/2007/REC-soap12-part2-20070427.

Appendix A. Evaluation of Other Protocol Models and Transports Considered for CCMP

Okay, this appendix is the why behind the design, and it's honestly so good 🧠💅 It explains how HTTP got picked as the transport for the CCMP requests and responses. Besides HTTP, the operations on the objects could be built in at least two different ways: as remote procedure calls (using SOAP, which is covered in Appendix A.1), or by defining resources in a RESTful architecture (covered in Appendix A.2).

Here's the tea ☕ In both the SOAP and RESTful approaches, servers have to rebuild their internal state representation of the object with every update request, checking parameters and triggering function invocations. With SOAP, you could describe a separate operation for each atomic element, but that would make the protocol way more complicated. A coarser-grained approach to CCMP means the server has to process XML elements in updates that haven't changed, and there can be several changes packed into one update. For CCMP, the resource (REST) model might look more attractive, since the conference operations fit the CRUD approach.

But neither of these approaches was considered ideal 🙈 SOAP was considered to bring extra overhead. It's pretty awkward to apply a RESTful approach because CCMP needs a more complex request/response protocol to keep the data in sync in both the server and at the client. That doesn't map very elegantly onto the basic request/response model, where a response usually just says whether the request worked or not, instead of providing extra data to keep the client and server synchronized. On top of that, CCMP clients may also receive the data in notifications. The notification method or protocol used by some conferencing clients can be independent of CCMP, but the same data on the server is used for both CCMP and notifications. That means you need a server application sitting above the transport layer (for example, HTTP) to maintain the data, which in the CCMP model is transparent to the transport protocol.

So the solution for CCMP defined in this document is seen as a good compromise between the most notable past candidates, and it's called "HTTP single-verb transport plus CCMP body" 🎀 With this approach, CCMP can take advantage of existing HTTP functionality. Like with SOAP, CCMP uses a "single HTTP verb" for transport (meaning a single transaction type for each request/response pair), and this lets CCMP messages be decoupled from HTTP messages. Similarly, like with any RESTful approach, CCMP messages go directly in the body of HTTP messages, which avoids unnecessary processing and communication burden from extra intermediaries. With this approach, no modification to the CCMP messages or operations is required to use a different transport protocol. Main character energy, literally 👑

A.1. Using SOAP for CCMP

Let's talk SOAP 🧼 A remote procedure call (RPC) mechanism for CCMP could use SOAP (Simple Object Access Protocol [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]), where conferences and the other objects are modeled as services with associated operations. Conferences and other objects are selected by their own local identifiers, such as email-like names for users. The big win here is that it can easily define atomic operations that have well-defined error conditions ✨

All SOAP operations would use a single HTTP verb. The RESTful approach needs a URI for each object, but SOAP can use any token 🦋

A.2. A RESTful Approach for CCMP

Conference objects can also be modeled as resources identified by URIs, with the basic CRUD operations mapped to the HTTP methods POST/PUT for creating objects, GET for reading objects, PATCH/POST/PUT for changing objects, and DELETE for deleting them. Many of the objects, like conferences, already have natural URIs 🌈

CCMP can be mapped into the CRUD (Create, Read, Update, Delete) design pattern. The basic CRUD operations are used to manipulate conference objects, which are XML documents containing the information that characterizes a specified conference instance. That could be an active conference, or a conference blueprint that the conference server uses to create new conference instances through a simple clone operation 🍓

Following the CRUD approach, CCMP could use a general-purpose protocol such as HTTP [RFC2616] to transfer domain-specific XML-encoded data objects defined in the "Conference Information Data Model for Centralized Conferencing" [RFC6501].

Following on the CRUD approach, CCMP could follow the well-known REST (REpresentational State Transfer) architectural style [REST]. CCMP could map onto the REST philosophy by specifying resource URIs, resource formats, the methods supported at each URI, and the status codes that have to be returned when a certain method is invoked on a specific URI. A REST-style approach must ensure that all operations can be mapped to HTTP operations 💜

Here's the summary of which specific HTTP method could be used for each of the CCMP Requests 💅

Retrieve: GET could be used on XCON-URIs, so that clients can obtain data about conference objects in the form of XML data model documents.
Create: PUT could be used to create a new object as identified by the XCON-URI or XCON-USERID.
Change: Either PATCH or POST could be used to change the conference object identified by the XCON-URI.
Delete: DELETE could be used to delete conference objects and parameters within conference objects identified by the XCON-URI.

Authors' Addresses

Mary Barnes Polycom TX USA

EMail: mary.ietf.barnes@gmail.com

Chris Boulton NS-Technologies

EMail: chris@ns-technologies.com

Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy

EMail: spromano@unina.it

Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027

EMail: hgs+xcon@cs.columbia.edu

That's the whole RFC, bestie 🎉🌈 Every author got their flowers, every reference is in the bag, and it's done. Iconic 🫶💖

📦 where this page comes from

ietf: rfc6503 2012-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms