File: rfc6503.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (6661 lines) | stat: -rw-r--r-- 306,659 bytes
parent folder | download | duplicates (2)
<pre>Internet Engineering Task Force (IETF)                         M. Barnes
Request for Comments: 6503                                       Polycom
Category: Standards Track                                     C. Boulton
ISSN: 2070-1721                                          NS-Technologies
                                                               S. Romano
                                                    University of Napoli
                                                          H. Schulzrinne
                                                     Columbia University
                                                              March 2012


             <span class="h1">Centralized Conferencing Manipulation Protocol</span>

Abstract

   The Centralized Conferencing Manipulation Protocol (CCMP) allows a
   Centralized Conferencing (XCON) system client to create, retrieve,
   change, and delete objects that describe a centralized conference.
   CCMP is a means to control basic and advanced conference features
   such as conference state and capabilities, participants, relative
   roles, and details.  CCMP is a stateless, XML-based, client server
   protocol that carries, in its request and response messages,
   conference information in the form of XML documents and fragments
   conforming to the centralized conferencing data model schema.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6503">http://www.rfc-editor.org/info/rfc6503</a>.













<span class="grey">Barnes, et al.               Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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



<span class="grey">Barnes, et al.               Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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












<span class="grey">Barnes, et al.               Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   "A Framework for Centralized Conferencing" [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>] (XCON framework)
   defines a signaling-agnostic framework, naming conventions, and
   logical entities required for building advanced conferencing systems.
   The XCON framework introduces the conference object as a logical
   representation of a conference instance, representing the current
   state and capabilities of a conference.

   The Centralized Conferencing Manipulation Protocol (CCMP) defined in
   this document allows authenticated and authorized users to create,
   manipulate, and delete conference objects.  Operations on conferences
   include adding and removing participants, changing their roles, as
   well as adding and removing media streams and associated endpoints.

   CCMP implements the client-server model within the XCON framework,
   with the conferencing client and conference server acting as client
   and server, respectively.  CCMP uses HTTP [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>] as the protocol
   to transfer requests and responses, which contain the domain-specific
   XML-encoded data objects defined in [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>] "Conference Information
   Data Model for Centralized Conferencing (XCON)".

   <a href="#section-2">Section 2</a> clarifies the conventions and terminology used in the
   document.  <a href="#section-3">Section 3</a> provides an overview of the conference control
   functionality of the XCON framework, together with a description of
   the main targets CCMP deals with, namely conference objects and
   conference users.  A general description of the operations associated
   with protocol messages is given in <a href="#section-4">Section 4</a> together with
   implementation details.  <a href="#section-5">Section 5</a> delves into the details of
   specific CCMP messages.  A complete, non-normative, example of the
   operation of CCMP, describing a typical call flow associated with
   conference creation and manipulation, is provided in <a href="#section-6">Section 6</a>.  A
   survey of the methods that can be used to locate a conference server
   is provided in <a href="#section-7">Section 7</a>, and <a href="#section-8">Section 8</a> discusses potential
   approaches to notifications management.  CCMP transport over HTTP is
   highlighted in <a href="#section-9">Section 9</a>.  Security considerations are presented in
   <a href="#section-10">Section 10</a>.  Finally, <a href="#section-11">Section 11</a> provides the XML schema.














<span class="grey">Barnes, et al.               Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions and Terminology</span>

   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
   [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   In addition to the terms defined in "A Framework for Centralized
   Conferencing" [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>], 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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  XCON Conference Control System Architecture</span>

   CCMP supports the XCON framework.  Figure 1 depicts a subset of the
   "Conferencing System Logical Decomposition" architecture from the
   XCON framework document.  It illustrates the role that CCMP assumes
   within the overall centralized architecture.

























<span class="grey">Barnes, et al.               Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   ........................................................
   .  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) allows the
   conference control client (conferencing client) to interface with the
   conference object maintained by the conferencing system, as depicted
   in Figure 1.  Note that additional functionality of the conferencing
   client and conferencing system is discussed in the XCON framework and
   related documents.





<span class="grey">Barnes, et al.               Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   This section provides details of the identifiers REQUIRED to address
   and manage the clients associated with a conferencing system using
   CCMP.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Conference Objects</span>

   Conference objects feature a simple dynamic inheritance-and-override
   mechanism.  Conference objects are linked into a tree known as a
   "cloning tree" (see <a href="./rfc5239#section-7.1">Section&nbsp;7.1 of [RFC5239]</a>).  Each cloning tree
   node inherits attributes from its parent node.  The roots of these
   inheritance trees are conference templates also known as
   "blueprints".  Nodes in the inheritance tree can be active
   conferences or simply descriptions that do not currently have any
   resources associated with them (i.e., conference reservations).  An
   object can mark certain of its properties as unalterable, so that
   they cannot be overridden.  Per the framework, a client may specify a
   parent object (a conference or blueprint) from which to inherit
   values when a conference is created using the conference control
   protocol.

   Conference objects are uniquely identified by 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 comprehensively represented through XML
   documents compliant with the XML schema defined in the XCON data
   model [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>].  The root element of such documents, called
   &lt;conference-info&gt;, is of type "conference-type".  It encompasses
   other XML elements describing different conference features and users
   as well.  Using CCMP, conferencing clients can use these XML
   structures to express their preferences in creating or updating a
   conference.  A conference server can convey conference information
   back to the clients using the XML elements.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Conference Users</span>

   Each conference can have zero or more users.  All conference
   participants are users, but some users may have only administrative
   functions and do not contribute or receive media.  Users are added
   one user at a time to simplify error reporting.  When a conference is
   cloned from a parent object, users are inherited as well, so that it
   is easy to set up a conference that has the same set of participants
   or a common administrator.  The conference server creates individual
   users, assigning them a unique conference user identifier (XCON-
   USERID).  The XCON-USERID as identifier of each conferencing system
   client is introduced in the XCON framework and defined in the XCON





<span class="grey">Barnes, et al.               Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   common data model.  Each CCMP request, with an exception pointed out
   in <a href="#section-5.3.6">Section 5.3.6</a> representing the case of a user at his first
   entrance in the system as a conference participant, must carry the
   XCON-USERID of the requestor in the proper &lt;confUserID&gt; parameter.

   The XCON-USERID acts as a pointer to the user's profile as a
   conference actor, e.g., her signaling URI and other XCON protocol
   URIs in general, her role (moderator, participant, observer, etc.),
   her display text, her joining information, and so on.  A variety of
   elements defined in the common &lt;conference-info&gt; element as specified
   in the XCON data model are used to describe the users related to a
   conference including the &lt;users&gt; element, as well as each &lt;user&gt;
   element included within it.  For example, it is possible to determine
   how a specific user expects and is allowed to join a conference by
   looking at the &lt;allowed-users-list&gt; in &lt;users&gt;: each &lt;target&gt; element
   involved in such a list represents a user and shows a 'method'
   attribute defining how the user is expected to join the conference,
   i.e., "dial-in" for users that are allowed to dial, "dial-out" for
   users that the conference focus will be trying to reach (with
   "dial-in" being the default mode).  If the conference is currently
   active, dial-out users are contacted immediately; otherwise, they are
   contacted at the start of the conference.  CCMP, acting as the
   conference control protocol, provides a means to manipulate these and
   other kinds of user-related features.

   As a consequence of an explicit user registration to a specific XCON
   conferencing system, conferencing clients are usually provided
   (besides the XCON-USERID) with log-in credentials (i.e., username and
   password).  Such credentials can be used to authenticate the XCON-
   aware client issuing CCMP requests.  Thus, both username and password
   should be carried in a CCMP request as part of the "subject"
   parameter whenever a registered conferencing client wishes to contact
   a CCMP server.  CCMP does not maintain a user's subscriptions at the
   conference server; hence, it does not provide any specific mechanism
   allowing clients to register their conferencing accounts.  The
   "subject" parameter is just used for carrying authentication data
   associated with pre-registered clients, with the specific
   registration modality outside the scope of this document.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Protocol Overview</span>

   CCMP is a client-server, XML-based protocol for user creation,
   retrieval, modification, and deletion of conference objects.  CCMP is
   a stateless protocol, such that implementations can safely handle
   transactions independently from each other.  CCMP messages are XML
   documents or XML document fragments compliant with the XCON data
   model representation [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>].




<span class="grey">Barnes, et al.               Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   <a href="#section-4.1">Section 4.1</a> specifies the basic operations that can create, retrieve,
   modify, and delete conference-related information in a centralized
   conference.  The core set of objects manipulated by CCMP includes
   conference blueprints, the conference object, users, and sidebars.

   Each operation in the protocol model, as summarized in <a href="#section-4.1">Section 4.1</a>,
   is atomic and either succeeds or fails as a whole.  The conference
   server MUST ensure that the operations are atomic in that the
   operation invoked by a specific conferencing client completes prior
   to another client's operation on the same conference object.  While
   the details for this data locking functionality are out of scope for
   the CCMP specification and are implementation specific for a
   conference server, some core functionality for ensuring the integrity
   of the data is provided by CCMP as described in <a href="#section-4.2">Section 4.2</a>.

   While the XML documents that are carried in CCMP need to comply with
   the XCON data model, there are situations in which the values for
   mandatory elements are unknown by the client.  The mechanism for
   ensuring compliance with the data model in these cases is described
   in <a href="#section-4.3">Section 4.3</a>.

   CCMP is completely independent from underlying protocols, which means
   that there can be different ways to carry CCMP messages from a
   conferencing client to a conference server.  The specification
   describes the use of HTTP as a transport solution, including CCMP
   requests in HTTP POST messages and CCMP responses in HTTP 200 OK
   replies.  This implementation approach is further described in
   <a href="#section-4.4">Section 4.4</a>.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Protocol Operations</span>

   The main operations provided by CCMP belong in four general
   categories:

   create:  for the creation of a conference object, a conference user,
      a sidebar, or a blueprint.

   retrieve:  to get information about the current state of either a
      conference object (be it an actual conference, a blueprint, or a
      sidebar) or a conference user.  A retrieve operation can also be
      used to obtain the XCON-URIs of the current conferences (active or
      registered) handled by the conferencing server and/or the
      available blueprints.

   update:  to modify the current features of a specified conference or
      conference user.





<span class="grey">Barnes, et al.               Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   delete:  to remove from the system a conference object or a
      conference user.

   Thus, the main targets of CCMP operations are as follows:

   o  conference objects associated with either active or registered
      conferences,

   o  conference objects associated with blueprints,

   o  conference objects associated with sidebars, both embedded in the
      main conference (i.e., &lt;entry&gt; elements in &lt;sidebars-by-value&gt;)
      and external to it (i.e., whose XCON-URIs are included in the
      &lt;entry&gt; elements of &lt;sidebars-by-ref&gt;),

   o  &lt;user&gt; elements associated with conference users, and

   o  the list of XCON-URIs related to conferences and blueprints
      available at the server, for which only retrieval operations are
      allowed.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Data Management</span>

   The XCON framework defines a model whereby the conference server
   centralizes and maintains the conference information.  Since multiple
   clients can modify the same conference objects, a conferencing client
   might not have the latest version of a specific conference object
   when it initiates operations.  To determine whether the client has
   the most up-to-date conference information, CCMP defines a versioning
   approach.  Each conference object is associated with a version
   number.  All CCMP response messages containing a conference document
   (or a fragment thereof) MUST contain a &lt;version&gt; parameter.  When a
   client sends an update message to the server, which includes
   modifications to a conference object, if the modifications are all
   successfully applied, the server MUST return a response, with a
   &lt;response-code&gt; of "200", containing the version number of the
   modified object.  With this approach, a client working on version "X"
   of a conference object that receives a response, with a &lt;response-
   code&gt; of "200", with a version number that is "X+1" can be certain
   that the version it manipulated was the most up to date.  However, if
   the response contains a version that is at least "X+2", the client
   knows that the object modified by the server was more up to date than
   the object the client was manipulating.  In order to ensure that the
   client always has the latest version of the modified object, the
   client can send a request to the conference server to retrieve the
   conference object.  The client can then update the relevant data
   elements in the conference object prior to invoking a specific
   operation.  Note that a client subscribed to the XCON event package



<span class="grey">Barnes, et al.               Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   [<a id="ref-RFC6502">RFC6502</a>] notifications about conference object modifications, will
   receive the most up-to-date version of that object upon receipt of a
   notification.

   The "version" parameter is OPTIONAL for requests, since it is not
   needed by the server: as long as the required modifications can be
   applied to the target conference object without conflicts, the server
   does not care whether the client has stored an up-to-date view of the
   information.  In addition, to ensure the integrity of the data, the
   conference server first checks all the parameters, before making any
   changes to the internal representation of the conference object.  For
   example, it would be undesirable to change the &lt;subject&gt; of the
   conference, but then detect an invalid URI in one of the &lt;service-
   uris&gt; and abort the remaining updates.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Data Model Compliance</span>

   The XCON data model [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>] identifies some elements and attributes
   as mandatory.  Since the XML documents carried in the body of the
   CCMP requests and responses need to be compliant with the XCON data
   model, there can be a problem in cases of client-initiated
   operations, such as the initial creation of conference objects and
   cases whereby a client updates a conference object adding new
   elements, such as a new user.  In such cases, not all of the
   mandatory data can be known in advance by the client issuing a CCMP
   request.  As an example, a client cannot know, at the time it issues
   a conference creation request, the XCON-URI that the server will
   assign to the yet-to-be-created conference; hence, it is not able to
   populate the mandatory 'entity' attribute of the conference document
   contained in the request with the correct value.  To solve this
   issue, the CCMP client fills all mandatory data model fields, for
   which no value is available at the time the request is constructed,
   with placeholder values in the form of a wildcard string,
   AUTO_GENERATE_X (all uppercase), with X being a unique numeric index
   for each data model field for which the value is unknown.  This form
   of wildcard string is chosen, rather than the use of random unique
   strings (e.g., FOO_BAR_LA) or non-numeric values for X, to simplify
   processing at the server.  The values of AUTO_GENERATE_X are only
   unique within the context of the specific request.  The placeholder
   AUTO_GENERATE_X values MUST be within the value part of an attribute
   or element (e.g., &lt;userinfo
   entity="xcon-userid:AUTO_GENERATE_1@example.com"&gt;).









<span class="grey">Barnes, et al.               Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   When the server receives requests containing values in the form of
   AUTO_GENERATE_X, the server does the following:

   (a)  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/
        element, the server MUST send a &lt;response-code&gt; of "400 Bad
        Request".  In cases where AUTO_GENERATE_X appears only in the
        user part of a URI (i.e., in the case of XCON-USERIDs or XCON-
        URIs), the server needs to ensure that the domain name is one
        that is within the server's domain of responsibility.  If the
        domain name is not within the server's domain of responsibility,
        then the server MUST send a &lt;response-code&gt; of "427 Invalid
        Domain Name".  The server MUST replace each instance of a
        specific wildcard field (e.g., 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.
        Note that the values that replace the instances of
        AUTO_GENERATE_X are not the same across all conference objects;
        for example, different values can be used to replace
        AUTO_GENERATE_1 in two different documents.

   (b)  Sends a response in which all values of AUTO_GENERATE_X received
        in the request have been replaced by the newly created one(s).

   With this approach, compatibility with the data model requirements is
   maintained, while allowing for client-initiated manipulation of
   conference objects at the server's side.  Note that the use of this
   mechanism could be avoided in come cases by using multiple
   operations, such as creating a new user and then adding the new user
   to an existing conference.  However, the AUTO_GENERATE_X mechanism
   allows a single operation to be used to effect the same change on the
   conference object.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Implementation Approach</span>

   CCMP is implemented using HTTP, placing the CCMP request messages
   into the body of an HTTP POST operation and placing the CCMP
   responses into the body of the HTTP response messages.  A non-
   exhaustive summary of the other approaches that were considered and
   the perceived advantages of the HTTP solution described in this
   document are provided in <a href="#appendix-A">Appendix A</a>.

   Most CCMP commands can pend indefinitely, thus increasing the
   potential that pending requests can continue to increase when a
   server is receiving more requests than it can process within a



<span class="grey">Barnes, et al.               Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   specific time period.  In this case, a server SHOULD return a
   &lt;response-code&gt; of "510" to the pending requests.  In addition, to
   mitigate the situation, clients MUST NOT wait indefinitely for a
   response and MUST implement a timer such that 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.  Note that there may be cases where a
   response message is lost and a request has been successful (e.g.,
   user added to a conference); yet, the client will be unaware and
   close the connection.  However, as described in <a href="#section-4.2">Section 4.2</a>, there is
   a versioning mechanism for the conference objects; thus, there is a
   mechanism for the conference object stored by the client to be
   brought up to date.

   CCMP messages have a MIME-type of "application/ccmp+xml", which
   appears 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 described in [<a href="./rfc3023" title="&quot;XML Media Types&quot;">RFC3023</a>], including the naming
   convention of the type ('+xml' suffix) and the usage of the 'charset'
   parameter.  The 'charset' parameter MUST be included with the XML
   document.  <a href="#section-9">Section 9</a> provides the complete requirements for an HTTP
   implementation to support CCMP.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  CCMP Messages</span>

   CCMP messages are either requests or responses.  The general CCMP
   request message is defined in <a href="#section-5.1">Section 5.1</a>.  The general CCMP response
   message is defined in <a href="#section-5.2">Section 5.2</a>.  The details of the specific
   message type that is carried in the CCMP request and response
   messages are described in <a href="#section-5.3">Section 5.3</a>.  CCMP response codes are
   listed in <a href="#section-5.4">Section 5.4</a>.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  CCMP Request Message Type</span>

   A CCMP request message is comprised of the following parameters:

   subject:  An OPTIONAL parameter containing the username and password
      of the client registered at the conferencing system.  Each user
      who subscribes to the conferencing system is assumed to be
      equipped with those credentials and SHOULD enclose them in each
      CCMP request she issues.  These fields can be used to control that
      the user sending the CCMP request has the authority to perform the
      requested operation.  The same fields can also be used for other
      authorization and authentication procedures.






<span class="grey">Barnes, et al.               Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   confUserID:  An OPTIONAL parameter containing the XCON-USERID of the
      client.  The XCON-USERID is used to identify any conferencing
      client within the context of the conferencing system and it is
      assigned by the conference server for each conferencing client who
      interacts with it.  The &lt;confUserID&gt; parameter is REQUIRED in the
      CCMP request and response messages with the exception of the case
      of a user who has no XCON-USERID and who wants to enter, via CCMP,
      a conference whose identifier is known.  In such case, a side
      effect of the request is that the user is provided with an
      appropriate XCON-USERID.  An example of the aforementioned case
      will be provided in <a href="#section-5.3.6">Section 5.3.6</a>.

   confObjID:  An OPTIONAL parameter containing the XCON-URI of the
      target conference object.

   operation:  An OPTIONAL parameter refining the type of specialized
      request message.  The &lt;operation&gt; parameter is REQUIRED in all
      requests except for the blueprintsRequest and confsRequest
      specialized messages.

   conference-password:  The parameter is OPTIONAL except that it MUST
      be inserted in all requests whose target conference object is
      password-protected i.e., contains the &lt;conference-password&gt;
      element in [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>]).  A CCMP &lt;response-code&gt; of "423" MUST be
      returned if a conference-password is not included in the request
      when required.

   specialized request message:  This is a specialization of the generic
      request message (e.g., blueprintsRequest), containing parameters
      that are dependent on the specific request sent to the server.  A
      specialized request message MUST be included in the CCMP request
      message.  The details for the specialized messages and associated
      parameters are provided in <a href="#section-5.3">Section 5.3</a>.


















<span class="grey">Barnes, et al.               Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- Definition of CCMP Request --&gt;

   &lt;xs:element name="ccmpRequest" type="ccmp-request-type" /&gt;

   &lt;!-- Definition of ccmp-request-type--&gt;

   &lt;xs:complexType name="ccmp-request-type"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="ccmpRequest"
                       type="ccmp-request-message-type" /&gt;
       &lt;/xs:sequence&gt;
   &lt;/xs:complexType&gt;

    &lt;!--  Definition of ccmp-request-message-type --&gt;

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

               Figure 2: Structure of CCMP Request Messages

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  CCMP Response Message Type</span>

   A CCMP response message is comprised of the following parameters:

   confUserID:  A REQUIRED parameter in CCMP response messages
      containing the XCON-USERID of the conferencing client that issued
      the CCMP request message.

   confObjID:  An OPTIONAL parameter containing the XCON-URI of the
      target conference object.





<span class="grey">Barnes, et al.               Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   operation:  An OPTIONAL parameter for CCMP response messages.  This
      parameter is REQUIRED in all responses except for the
      "blueprintsResponse" and "confsResponse" specialized messages.

   response-code:  A REQUIRED parameter containing the response code
      associated with the request.  The response code MUST be chosen
      from the codes listed in <a href="#section-5.4">Section 5.4</a>.

   response-string:  An OPTIONAL reason string associated with the
      response.  In case of an error, in particular, this string can be
      used to provide the client with detailed information about the
      error itself.

   version:  An OPTIONAL parameter reflecting the current version number
      of the conference object referred by the confObjID.  This number
      is contained in the 'version' attribute of the &lt;conference-info&gt;
      element related to that conference.  This parameter is REQUIRED in
      CCMP response messages and SHOULD NOT be included in CCMP request
      messages.

   specialized response message:  This is specialization of the generic
      response message, containing parameters that are dependent on the
      specific request sent to the server (e.g., "blueprintsResponse").
      A specialized response message SHOULD be included in the CCMP
      response message, except in an error situation where the CCMP
      request message did not contain a valid specialized message.  In
      this case, the conference server MUST return a &lt;response-code&gt; of
      "400".  The details for the specialized messages and associated
      parameters are provided in <a href="#section-5.3">Section 5.3</a>.






















<span class="grey">Barnes, et al.               Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- Definition of CCMP Response --&gt;

   &lt;xs:element name="ccmpResponse" type="ccmp-response-type" /&gt;

   &lt;!-- Definition of ccmp-response-type --&gt;

   &lt;xs:complexType name="ccmp-response-type"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="ccmpResponse"
                       type="ccmp-response-message-type" /&gt;
       &lt;/xs:sequence&gt;
   &lt;/xs:complexType&gt;

   &lt;!--  Definition of ccmp-response-message-type --&gt;

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

               Figure 3: Structure of CCMP Response Message

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Detailed Messages</span>

   Based on the request and response message structures described in
   Sections <a href="#section-5.1">5.1</a> and <a href="#section-5.2">5.2</a>, the following summarizes the specialized CCMP
   request and response types described in this document:

   1.   blueprintsRequest/blueprintsResponse

   2.   confsRequest/confsResponse



<span class="grey">Barnes, et al.               Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   3.   blueprintRequest/blueprintResponse

   4.   confRequest/confResponse

   5.   usersRequest/usersResponse

   6.   userRequest/userResponse

   7.   sidebarsByValRequest/sidebarsByValResponse

   8.   sidebarsByRefRequest/sidebarsByRefResponse

   9.   sidebarByValRequest/sidebarByValResponse

   10.  sidebarByRefRequest/sidebarByRefResponse

   11.  extendedRequest/extendedResponse

   12.  optionsRequest/optionsResponse

   These CCMP request/response pairs use the fundamental CCMP operations
   as defined in <a href="#section-4.1">Section 4.1</a> to manipulate the conference data.  These
   request/response pairs are included in an IANA registry as defined in
   <a href="#section-12.5">Section 12.5</a>.  Table 1 summarizes the remaining CCMP operations and
   corresponding actions that are valid for a specific CCMP request
   type, noting that neither the blueprintsRequest/blueprintsResponse
   nor confsRequest/confsResponse require an &lt;operation&gt; parameter.  An
   entity MUST support the response message for each of the request
   messages that is supported.  The corresponding response message MUST
   contain the same &lt;operation&gt; parameter.  Note that some entries are
   labeled "N/A", indicating that the operation is invalid for that
   request type.  In the case of an "N/A*" label, the operation MAY be
   allowed for specific privileged users or system administrators but is
   not part of the functionality included in this document.

















<span class="grey">Barnes, et al.               Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   +---------------+------------+------------+------------+------------+
   | 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(**)  |
   |               |   &lt;users&gt;  |            |   &lt;users&gt;  |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | userRequest   |     Get    |    Add a   |   Change   |   Delete   |
   |               |  specified |  &lt;user&gt; to |  specified |  specified |
   |               |   &lt;user&gt;   |   a conf   |   &lt;user&gt;   |   &lt;user&gt;   |
   |               |            |    (***)   |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarsByVal |     Get    |     N/A    |     N/A    |     N/A    |
   | Request       | &lt;sidebars- |            |            |            |
   |               |   by-val&gt;  |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarsByRef |     Get    |     N/A    |     N/A    |     N/A    |
   | Request       | &lt;sidebars- |            |            |            |
   |               |   by-ref&gt;  |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | 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






<span class="grey">Barnes, et al.               Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   (**): These operations are not allowed for a usersRequest message,
   since the &lt;users&gt; section, which is the target element of such a
   request, is created and removed in conjunction with the creation and
   deletion, respectively, of the associated conference document.  Thus,
   "update" and "retrieve" are the only semantically correct operations
   for such message.

   (***): This operation can involve the creation of an XCON-USERID, if
   the sender does not add it in the &lt;confUserID&gt; parameter and/or if
   the entity field of the &lt;userInfo&gt; parameter is void.

   Additional parameters included in the specialized CCMP request and
   response messages are detailed in the subsequent sections.  If a
   required parameter is not included in a request, the conference
   server MUST return a &lt;response-code&gt; of "400" per <a href="#section-5.4">Section 5.4</a>.

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  blueprintsRequest and blueprintsResponse</span>

   A blueprintsRequest (Figure 4) message is sent to request the list of
   XCON-URIs associated with the available blueprints from the
   conference server.  These XCON-URIs can be subsequently used by the
   client to access detailed information about a specified blueprint
   with a specific blueprintRequest message per <a href="#section-5.3.3">Section 5.3.3</a>.

   The &lt;confUserID&gt; parameter MUST be included in every
   blueprintsRequest/Response message and reflect the XCON-USERID of the
   conferencing client issuing the request.  Since a blueprintsRequest
   message is not targeted to a specific conference instance and is a
   "retrieve-only" request, the &lt;confObjID&gt; and &lt;operation&gt; parameters
   MUST NOT be included in the blueprintsRequest/Response messages.

   In order to obtain a specific subset of the available blueprints, a
   client may specify a selection filter providing an appropriate xpath
   query in the OPTIONAL "xpathFilter" parameter of the request.  The
   information in the blueprints typically represents general
   capabilities and characteristics.  For example, to select blueprints
   having 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']".  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 above mentioned
   XCON-URI list.





<span class="grey">Barnes, et al.               Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- blueprintsRequest --&gt;
 &lt;xs:complexType name="ccmp-blueprints-request-message-type"&gt;
     &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
             &lt;xs:sequence&gt;
                 &lt;xs:element ref="blueprintsRequest" /&gt;
             &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;

 &lt;!-- blueprintsRequestType --&gt;

 &lt;xs:element name="blueprintsRequest" type="blueprintsRequestType"/&gt;

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

 &lt;!-- blueprintsResponse --&gt;

 &lt;xs:complexType name="ccmp-blueprints-response-message-type"&gt;
     &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
             &lt;xs:sequence&gt;
                 &lt;xs:element ref="blueprintsResponse" /&gt;
             &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
















<span class="grey">Barnes, et al.               Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- blueprintsResponseType --&gt;

 &lt;xs:element name="blueprintsResponse" type="blueprintsResponseType"/&gt;

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

             Figure 4: Structure of the blueprintsRequest and
                        blueprintsResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  confsRequest and confsResponse</span>

   A confsRequest message is used to retrieve, from the server, the list
   of XCON-URIs associated with active and registered conferences
   currently handled by the conferencing system.  The &lt;confUserID&gt;
   parameter MUST be included in every confsRequest/Response message and
   reflect the XCON-USERID of the conferencing client issuing the
   request.  The &lt;confObjID&gt; parameter MUST NOT be included in the
   confsRequest message.  The confsRequest message is of a retrieve-only
   type, since the sole purpose is to collect information available at
   the conference server.  Thus, an &lt;operation&gt; parameter MUST NOT be
   included in a confsRequest message.  In order to retrieve a specific
   subset of the available conferences, a client may specify a selection
   filter providing an appropriate xpath query in the OPTIONAL
   "xpathFilter" parameter of the request.  For example, to select only
   the registered conferences, a possible xpathFilter value could be "/
   conference-info[conference-description/conference-state/
   active='false']".  The associated confsResponse message SHOULD
   contain the list of XCON-URIs in the "confsInfo" parameter.  A user,
   upon receipt of the response message, can interact with the available
   conference objects through further CCMP messages.













<span class="grey">Barnes, et al.               Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- confsRequest --&gt;

 &lt;xs:complexType name="ccmp-confs-request-message-type"&gt;
     &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
             &lt;xs:sequence&gt;
                 &lt;xs:element ref="confsRequest" /&gt;
             &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;

 &lt;!-- confsRequestType --&gt;

 &lt;xs:element name="confsRequest" type="confsRequestType" /&gt;

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

 &lt;!-- confsResponse --&gt;

 &lt;xs:complexType name="ccmp-confs-response-message-type"&gt;
     &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
             &lt;xs:sequence&gt;
                 &lt;xs:element ref="confsResponse" /&gt;
             &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;















<span class="grey">Barnes, et al.               Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- confsResponseType --&gt;

 &lt;xs:element name="confsResponse" type="confsResponseType"/&gt;

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

    Figure 5: Structure of the confsRequest and confsResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  blueprintRequest and blueprintResponse</span>

   Through a blueprintRequest, a client can manipulate the conference
   object associated with a specified blueprint.  Along with the
   &lt;confUserID&gt; parameter, the request MUST include the &lt;confObjID&gt; and
   the &lt;operation&gt; parameters.  Again, the &lt;confUserID&gt; parameter MUST
   be included in every blueprintRequest/Response message and reflect
   the XCON-USERID of the conferencing client issuing the request.  The
   &lt;confObjID&gt; parameter MUST contain the XCON-URI of the blueprint,
   which might have been previously retrieved through a
   blueprintsRequest message.

   The blueprintRequest message SHOULD NOT contain an &lt;operation&gt;
   parameter with a value other than "retrieve".  An &lt;operation&gt;
   parameter with a value of "create", "update", or "delete" SHOULD NOT
   be included in a blueprintRequest message except in the case of
   privileged users (e.g., the conference server administration staff),
   who might authenticate themselves by the mean of the "subject"
   request parameter.

   A blueprintRequest/retrieve carrying a &lt;confObjID&gt; parameter whose
   value is not associated with one of the available system's
   blueprints, will generate, on the server's side, a blueprintResponse
   message containing a &lt;response-code&gt; of "404".  This also holds for
   the case in which the mentioned &lt;confObjID&gt; parameter value is
   related to an existing conference document stored at the server, but
   associated with an actual conference (be it active or registered) or
   with a sidebar rather than a blueprint.







<span class="grey">Barnes, et al.               Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   For a &lt;response-code&gt; of "200" in a "retrieve" operation, the
   &lt;blueprintInfo&gt; parameter MUST be included in the blueprintResponse
   message.  The &lt;blueprintInfo&gt; parameter contains the conference
   document associated with the blueprint as identified by the
   &lt;confObjID&gt; parameter specified in the blueprintRequest.

   &lt;!--  blueprintRequest --&gt;

   &lt;xs:complexType name="ccmp-blueprint-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- blueprintRequestType --&gt;

   &lt;xs:element name="blueprintRequest" type="blueprintRequestType" /&gt;

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

   &lt;!-- blueprintResponse --&gt;

   &lt;xs:complexType name="ccmp-blueprint-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;








<span class="grey">Barnes, et al.               Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- blueprintResponseType --&gt;

   &lt;xs:element name="blueprintResponse" type="blueprintResponseType"/&gt;

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

              Figure 6: Structure of the blueprintRequest and
                        blueprintResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  confRequest and confResponse</span>

   With a confRequest message, CCMP clients can manipulate conference
   objects associated with either active or registered conferences.  The
   &lt;confUserID&gt; parameter MUST be included in every confRequest/Response
   message and reflect the XCON-USERID of the conferencing client
   issuing the request. confRequest and confResponse messages MUST also
   include an &lt;operation&gt; parameter.  ConfResponse messages MUST return
   to the requestor a &lt;response-code&gt; and MAY contain a &lt;response-
   string&gt; explaining it.  Depending upon the type of operation, a
   &lt;confObjID&gt; and &lt;confInfo&gt; parameter MAY be included in the
   confRequest and response.  For each type of operation, the text below
   describes whether the &lt;confObjID&gt; and &lt;confInfo&gt; parameters need to
   be included in the confRequest and confResponse messages.

   The creation case deserves care.  To create a new conference through
   a confRequest message, two approaches can be considered:

   1.  Creation through explicit cloning: the &lt;confObjID&gt; parameter MUST
       contain the XCON-URI of the blueprint or of the conference to be
       cloned, while the &lt;confInfo&gt; 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 <a href="#section-5.3.8">Section 5.3.8</a>.

   2.  Creation through implicit cloning (also known as "direct
       creation"): the &lt;confObjID&gt; parameter MUST NOT be included in the
       request and the CCMP client can describe the desired conference
       to be created using the &lt;confInfo&gt; parameter.  If no &lt;confInfo&gt;
       parameter is provided in the request, the new conference will be
       created as a clone of the system default blueprint.



<span class="grey">Barnes, et al.               Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   In both creation cases, the confResponse, for a successful completion
   of a "create" operation, contains a &lt;response-code&gt; of "200" and MUST
   contain the XCON-URI of the newly created conference in the
   &lt;confObjID&gt; parameter, in order to allow the conferencing client to
   manipulate that conference through following CCMP requests.  In
   addition, the &lt;confInfo&gt; parameter containing the conference document
   created MAY be included, at the discretion of the conferencing system
   implementation, along with the REQUIRED &lt;version&gt; parameter
   initialized at "1", since, at creation time, the conference object is
   at its first version.

   In the case of a confRequest with an &lt;operation&gt; parameter of
   "retrieve", the &lt;confObjID&gt; parameter representing the XCON-URI of
   the target conference MUST be included and the &lt;confInfo&gt; parameter
   MUST NOT be included in the request.  The conference server MUST
   ignore any &lt;confInfo&gt; parameter that is received in a confRequest
   "retrieve" operation.  If the confResponse for the retrieve operation
   contains a &lt;response-code&gt; of "200", the &lt;confInfo&gt; parameter MUST be
   included in the response.  The &lt;confInfo&gt; 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.

   In case of a confRequest with an &lt;operation&gt; parameter of "update",
   the &lt;confInfo&gt; and &lt;confObjID&gt; parameters MUST be included in the
   request.  The &lt;confInfo&gt; 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 &lt;confObjID&gt;
   parameter.  Note that, in such a case, though the &lt;confInfo&gt;
   parameter indeed has to follow the rules indicated in the XCON data
   model, it does not represent the entire updated version of the target
   conference, since it conveys just the modifications to apply to that
   conference.  For example, in order to change the conference title,
   the &lt;confInfo&gt; parameter will be of the form:

   &lt;confInfo entity="xcon:8977777@example.com"&gt;
     &lt;conference-description&gt;
       &lt;display-text&gt; *** NEW CONFERENCE TITLE *** &lt;/display-text&gt;
     &lt;/conference-description&gt;
   &lt;/confInfo&gt;

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

   Similarly, to remove the title of an existing conference, a
   confRequest/update carrying the following &lt;confInfo&gt; parameter would
   do the job.



<span class="grey">Barnes, et al.               Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;confInfo entity="xcon:8977777@example.com"&gt;
     &lt;conference-description&gt;
       &lt;display-text/&gt;
     &lt;/conference-description&gt;
   &lt;/confInfo&gt;

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

   In the case of a confResponse/update with a &lt;response-code&gt; of "200",
   no additional information is REQUIRED in the response message, which
   means the return of a &lt;confInfo&gt; parameter is OPTIONAL.  A subsequent
   confRequest/retrieve transaction might provide the CCMP client with
   the current status of the conference after the modification, or the
   notification protocol might address that task as well.  A &lt;response-
   code&gt; of "200" indicates that the conference object has been changed
   according to the request by the conference server.  The &lt;version&gt;
   parameter MUST be enclosed in the confResponse/update message, in
   order to let the client understand what is the current conference-
   object version, upon the applied modifications.  A &lt;response-code&gt; of
   "409" indicates that the changes reflected in the &lt;confInfo&gt;
   parameter of the request are not feasible.  This could be due to
   policies, requestor roles, specific privileges, unacceptable values,
   etc., with the reason specific to a conferencing system and its
   configuration.  Together with a &lt;response-code&gt; of "409", the
   &lt;version&gt; parameter MUST be attached in the confResponse/update,
   allowing the client to later retrieve the current version of the
   target conference if the one she attempted to modify was not the most
   up to date.

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





<span class="grey">Barnes, et al.               Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   A confRequest with an &lt;operation&gt; parameter of "retrieve", "update",
   or "delete" carrying a &lt;confObjID&gt; parameter which is not associated
   with one of the conferences (active or registered) that the system is
   holding will generate, on the server's side, a confResponse message
   containing a &lt;response-code&gt; of "404".  This also holds for the case
   in which the mentioned &lt;confObjID&gt; parameter is related to an
   existing conference object stored at the server, but associated with
   a blueprint or with a sidebar rather than an actual conference.

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

   &lt;!-- confRequest --&gt;

   &lt;xs:complexType name="ccmp-conf-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="confRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- confRequestType --&gt;

   &lt;xs:element name="confRequest" type="confRequestType" /&gt;

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














<span class="grey">Barnes, et al.               Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- confResponse --&gt;

   &lt;xs:complexType name="ccmp-conf-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="confResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- confResponseType --&gt;

   &lt;xs:element name="confResponse" type="confResponseType" /&gt;

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

     Figure 9: Structure of the confRequest and confResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>.  usersRequest and usersResponse</span>

   The usersRequest message allows a client to manipulate the &lt;users&gt;
   element of the conference object represented by the &lt;confObjID&gt;
   parameter.  The &lt;users&gt; element contains the list of &lt;user&gt; elements
   associated with conference participants, the list of the users to
   which access to the conference is allowed/denied, conference
   participation policies, etc.  The &lt;confObjID&gt; parameter MUST be
   included in a usersRequest message.

   A &lt;usersInfo&gt; parameter MAY be included in a usersRequest message
   depending upon the operation.  If the &lt;usersInfo&gt; parameter is
   included in the usersRequest message, the parameter MUST be compliant
   with the &lt;users&gt; field of the XCON data model.

   Two operations are allowed for a usersRequest message:

   1.  "retrieve": In this case the request MUST NOT include a
       &lt;usersInfo&gt; parameter, while the successful response MUST contain
       the desired &lt;users&gt; element in the &lt;usersInfo&gt; parameter.  The



<span class="grey">Barnes, et al.               Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


       conference server MUST ignore a &lt;usersInfo&gt; parameter if it is
       received in a request with an &lt;operation&gt; parameter of
       "retrieve".

   2.  "update": In this case, the &lt;usersInfo&gt; parameter MUST contain
       the modifications to be applied to the &lt;users&gt; element indicated.
       If the &lt;response-code&gt; is "200", then the &lt;usersInfo&gt; parameter
       SHOULD NOT be returned.  Any &lt;usersInfo&gt; parameter that is
       returned SHOULD be ignored.  A &lt;response-code&gt; of "426" indicates
       that the conferencing client is not allowed to make the changes
       reflected in the &lt;usersInfo&gt; contained in the usersRequest
       message.  This could be due to policies, roles, specific
       privileges, etc., with the reason being specific to a
       conferencing system and its configuration.

   Operations of "create" and "delete" are not applicable to a
   usersRequest message and MUST NOT be considered by the server, which
   means that a &lt;response-code&gt; of "403" MUST be included in the
   usersResponse message.

   &lt;!-- usersRequest --&gt;

   &lt;xs:complexType name="ccmp-users-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="usersRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- usersRequestType --&gt;

   &lt;xs:element name="usersRequest" type="usersRequestType" /&gt;

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






<span class="grey">Barnes, et al.               Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- usersResponse --&gt;

   &lt;xs:complexType name="ccmp-users-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="usersResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- usersResponseType --&gt;

   &lt;xs:element name="usersResponse" type="usersResponseType" /&gt;

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

    Figure 10: Structure of the usersRequest and usersResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.6" href="#section-5.3.6">5.3.6</a>.  userRequest and userResponse</span>

   A userRequest message is used to manipulate &lt;user&gt; elements inside a
   conference document associated with a conference identified by the
   &lt;confObjID&gt; parameter.  Besides retrieving information about a
   specific conference user, the message is used to request that the
   conference server either create, modify, or delete information about
   a user.  A userRequest message MUST include the &lt;confObjID&gt; and the
   &lt;operation&gt; parameters, and it MAY include a &lt;userInfo&gt; parameter
   containing the detailed user's information depending upon the
   operation and whether the &lt;userInfo&gt; has already been populated for a
   specific user.  Note that a user may not necessarily be a
   conferencing control client (i.e., some participants in a conference
   are not "XCON aware").

   An XCON-USERID SHOULD be assigned to each and every user subscribed
   to the system.  In such a way, a user who is not a conference
   participant can make requests (provided she has successfully passed
   authorization and authentication checks), like creating a conference
   or retrieving conference information.



<span class="grey">Barnes, et al.               Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   Conference users can be created in a number of different ways.  In
   each of these cases, the &lt;operation&gt; parameter MUST be set to
   "create" in the userRequest message.  Each of the userResponse
   messages for these cases MUST include the &lt;confObjID&gt;, &lt;confUserID&gt;,
   &lt;operation&gt;, and &lt;response-code&gt; parameters.  In the case of a
   &lt;response-code&gt; of "200", the userResponse message MAY include the
   &lt;userInfo&gt; parameter depending upon the manner in which the user was
   created:

   o  A conferencing client with an XCON-USERID adds itself to the
      conference: In this case, the &lt;userInfo&gt; parameter MAY be included
      in the userRequest.  The &lt;userInfo&gt; parameter MUST contain a
      &lt;user&gt; element (compliant with the XCON data model) and the
      'entity' attribute MUST be set to a value that represents the
      XCON-USERID of the user initiating the request.  No additional
      parameters beyond those previously described are required in the
      userResponse message, in the case of a &lt;response-code&gt; of "200".

   o  A conferencing client acts on behalf of another user whose XCON-
      USERID is known: In this case, the &lt;userInfo&gt; parameter MUST be
      included in the userRequest.  The &lt;userInfo&gt; parameter MUST
      contain a &lt;user&gt; element and the 'entity' attribute value MUST be
      set to the XCON-USERID of the other user in question.  No
      additional parameters beyond those previously described are
      required in the userResponse message, in the case of a &lt;response-
      code&gt; of "200".

   o  A conferencing client who has no XCON-USERID and who wants to
      enter, via CCMP, a conference whose identifier is known: In this
      case, a side effect of the request is that the user is provided
      with a new XCON-USERID (created by the server) carried inside the
      &lt;confUserID&gt; parameter of the response.  This is the only case in
      which a CCMP request can be valid though carrying a void
      &lt;confUserID&gt; parameter.  A &lt;userInfo&gt; parameter MUST be enclosed
      in the request, providing at least a contact URI of the joining
      client, in order to let the focus initiate the signaling phase
      needed to add her to the conference.  The mandatory 'entity'
      attribute of the &lt;userInfo&gt; parameter in the request MUST be
      filled with a placeholder value with the user part of the XCON-
      USERID containing a value of AUTO_GENERATE_X as described in
      <a href="#section-4.3">Section 4.3</a>, to conform to the rules contained in the XCON data
      model XML schema.  The messages (userRequest and userResponse) in
      this case should look like the following:








<span class="grey">Barnes, et al.               Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   Request fields:

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

   &lt;userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"&gt;
           &lt;endpoint entity="sip:GHIL345@example.com"&gt;
           ...


   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

   o  A conferencing client is unaware of the XCON-USERID of a third
      user: In this case, the XCON-USERID in the request, &lt;confUserID&gt;,
      is the sender's and the 'entity' attribute of the attached
      &lt;userInfo&gt; parameter 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 issuing the request
      in the 'entity' attribute of the response &lt;userInfo&gt; parameter, if
      the &lt;response-code&gt; is "200".  This scenario is intended to
      support both the case where a brand new conferencing system user
      is added to a conference by a third party (i.e., a user who has
      not yet been provided with an XCON-USERID) and the case where the
      CCMP client issuing the request does not know the to-be-added
      user's XCON-USERID (which means such an identifier could already
      exist on the server's side for that user).  In this last case, the
      conference server is in charge of avoiding XCON-URI duplicates for
      the same conferencing client, looking at key fields in the
      request-provided &lt;userInfo&gt; parameter, such as the signaling URI.
      If the joining user is brand new, then the generation of a new
      XCON-USERID is needed; otherwise, if that user exists already, the
      server must recover the corresponding XCON-USERID.

   In the case of a userRequest with an &lt;operation&gt; parameter of
   "retrieve", the &lt;confObjID&gt; parameter representing the XCON-URI of
   the target conference MUST be included.  The &lt;confUserID&gt;, containing
   the CCMP client's XCON-USERID, MUST also be included in the



<span class="grey">Barnes, et al.               Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   userRequest message.  If the client wants to retrieve information
   about her profile in the specified conference, no &lt;userInfo&gt;
   parameter is needed in the retrieve request.  On the other hand, if
   the client wants to obtain someone else's info within the given
   conference, she MUST include in the userRequest/retrieve a &lt;userInfo&gt;
   parameter whose 'entity' attribute conveys the desired user's XCON-
   USERID.  If the userResponse for the retrieve operation contains a
   &lt;response-code&gt; of "200", the &lt;userInfo&gt; parameter MUST be included
   in the response.

   In case of a userRequest with an &lt;operation&gt; parameter of "update",
   the &lt;confObjID&gt;, &lt;confUserID&gt;, and &lt;userInfo&gt; parameters MUST be
   included in the request.  The &lt;userInfo&gt; parameter is of type "user-
   type" and contains all the changes to be applied to a specific &lt;user&gt;
   element in the conference object identified by the &lt;confObjID&gt;
   parameter in the userRequest message.  The user to be modified is
   identified through the 'entity' attribute of the &lt;userInfo&gt; parameter
   included in the request.  In the case of a userResponse with a
   &lt;response-code&gt; of "200", no additional information is required in
   the userResponse message.  A &lt;response-code&gt; of "200" indicates that
   the referenced &lt;user&gt; element has been updated by the conference
   server.  A &lt;response-code&gt; of "426" indicates that the conferencing
   client is not allowed to make the changes reflected in the &lt;userInfo&gt;
   in the initial request.  This could be due to policies, roles,
   specific privileges, etc., with the reason specific to a conferencing
   system and its configuration.

   In the case of a userRequest with an &lt;operation&gt; parameter of
   "delete", the &lt;confObjID&gt; representing the XCON-URI of the target
   conference MUST be included.  The &lt;confUserID&gt; parameter, containing
   the CCMP client's XCON-USERID, MUST be included in the userRequest
   message.  If the client wants to exit the specified conference, no
   &lt;userInfo&gt; parameter is needed in the delete request.  On the other
   hand, if the client wants to remove another participant from the
   given conference, she MUST include in the userRequest/delete a
   &lt;userInfo&gt; parameter whose 'entity' attribute conveys the XCON-USERID
   of that participant.  The userResponse MUST contain the same value
   for the &lt;confObjID&gt; parameter that was included in the &lt;confObjID&gt;
   parameter in the userRequest.  The userResponse MUST contain a
   &lt;response-code&gt; of "200" if the target &lt;user&gt; element has been
   successfully deleted.  If the userResponse for the delete operation
   contains a &lt;response-code&gt; of "200", the userResponse MUST NOT
   contain the &lt;userInfo&gt; parameter.








<span class="grey">Barnes, et al.               Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- userRequest --&gt;

   &lt;xs:complexType name="ccmp-user-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="userRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- userRequestType --&gt;

   &lt;xs:element name="userRequest" type="userRequestType" /&gt;

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

   &lt;!-- userResponse --&gt;

   &lt;xs:complexType name="ccmp-user-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="userResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;














<span class="grey">Barnes, et al.               Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- userResponseType --&gt;

   &lt;xs:element name="userResponse" type="userResponseType" /&gt;

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

     Figure 12: Structure of the userRequest and userResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.7" href="#section-5.3.7">5.3.7</a>.  sidebarsByValRequest and sidebarsByValResponse</span>

   A sidebarsByValRequest message is used to execute a retrieve-only
   operation on the &lt;sidebars-by-val&gt; field of the conference object
   represented by the &lt;confObjID&gt;.  The sidebarsByValRequest message is
   of a retrieve-only type, so an &lt;operation&gt; parameter MUST NOT be
   included in a sidebarsByValRequest message.  As with blueprints and
   conferences, CCMP allows for the use of xpath filters whenever a
   selected subset of the sidebars available at the server's side has to
   be retrieved by the client.  This applies both to sidebars by
   reference and sidebars by value.  A sidebarsByValResponse message
   with a &lt;response-code&gt; of "200" MUST contain a &lt;sidebarsByValInfo&gt;
   parameter containing the desired &lt;sidebars-by-val&gt; element.  A
   sidebarsByValResponse message MUST return to the client a &lt;version&gt;
   element related to the current version of the main conference object
   (i.e., the one whose identifier is contained in the &lt;confObjID&gt; field
   of the request) with which the sidebars in question are associated.
   The &lt;sidebarsByValInfo&gt; parameter contains the list of the conference
   objects associated with the sidebars by value derived from the main
   conference.  The retrieved sidebars can then be updated or deleted
   using the sidebarByValRequest message, which is described in
   <a href="#section-5.3.8">Section 5.3.8</a>.













<span class="grey">Barnes, et al.               Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- sidebarsByValRequest --&gt;

 &lt;xs:complexType name="ccmp-sidebarsByVal-request-message-type"&gt;
     &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
             &lt;xs:sequence&gt;
                 &lt;xs:element ref="sidebarsByValRequest"/&gt;
             &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
    &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;

 &lt;!-- sidebarsByValRequestType --&gt;

 &lt;xs:element name="sidebarsByValRequest"
             type="sidebarsByValRequestType" /&gt;

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


 &lt;!-- sidebarsByValResponse --&gt;

 &lt;xs:complexType name="ccmp-sidebarsByVal-response-message-type"&gt;
         &lt;xs:complexContent&gt;
          &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                 &lt;xs:sequence&gt;
            &lt;xs:element ref="sidebarsByValResponse"/&gt;
           &lt;/xs:sequence&gt;
          &lt;/xs:extension&gt;
         &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;













<span class="grey">Barnes, et al.               Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 &lt;!-- sidebarsByValResponseType --&gt;

 &lt;xs:element name="sidebarsByValResponse"
             type="sidebarsByValResponseType" /&gt;

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

           Figure 13: Structure of the sidebarsByValRequest and
                      sidebarsByValResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.8" href="#section-5.3.8">5.3.8</a>.  sidebarByValRequest and sidebarByValResponse</span>

   A sidebarByValRequest message MUST contain the &lt;operation&gt; parameter,
   which distinguishes among retrieval, creation, modification, and
   deletion of a specific sidebar.  The other required parameters depend
   upon the type of operation.

   In the case of a "create" operation, the &lt;confObjID&gt; parameter MUST
   be included in the sidebyValRequest message.  In this case, the
   &lt;confObjID&gt; parameter contains the XCON-URI of the main conference in
   which the sidebar has to be created.  If no "sidebarByValInfo"
   parameter is included, the sidebar is created by cloning the main
   conference, as envisioned in the XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>] following
   the implementation specific cloning rules.  Otherwise, similar to the
   case of direct creation, the sidebar conference object is built on
   the basis of the "sidebarByValInfo" parameter provided by the
   requestor.  As a consequence of a sidebar-by-val creation, the
   conference server MUST update the main conference object reflected by
   the &lt;confObjID&gt; parameter in the sidebarbyValRequest/create message
   introducing the new sidebar object as a new &lt;entry&gt; in the proper
   section &lt;sidebars-by-val&gt;.  The newly created sidebar conference
   object MAY be included in the sidebarByValResponse in the
   &lt;sidebarByValInfo&gt; parameter, if the &lt;response-code&gt; is "200".  The
   XCON-URI of the newly created sidebar MUST appear in the &lt;confObjID&gt;
   parameter of the response.  The conference server can notify any
   conferencing clients that have subscribed to the conference event
   package and that are authorized to receive the notification of the
   addition of the sidebar to the conference.





<span class="grey">Barnes, et al.               Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   In the case of a sidebarByValRequest message with an &lt;operation&gt;
   parameter of "retrieve", the URI for the conference object created
   for the sidebar (received in response to a create operation or in a
   sidebarsByValResponse message) MUST be included in the &lt;confObjID&gt;
   parameter in the request.  This retrieve operation is handled by the
   conference server in the same manner as in the case of an &lt;operation&gt;
   parameter of "retrieve" included in a confRequest message, as
   described in <a href="#section-5.3.4">Section 5.3.4</a>.

   In the case of a sidebarByValRequest message with an &lt;operation&gt;
   parameter of "update", the &lt;sidebarByValInfo&gt; MUST also be included
   in the request.  The &lt;confObjID&gt; parameter contained in the request
   message identifies the specific sidebar instance to be updated.  An
   update operation on the specific sidebar instance contained in the
   &lt;sidebarByValInfo&gt; parameter is handled by the conference server in
   the same manner as an update operation on the conference instance as
   reflected by the &lt;confInfo&gt; parameter included in a confRequest
   message as detailed in <a href="#section-5.3.4">Section 5.3.4</a>.  A sidebarByValResponse message
   MUST return to the client a &lt;version&gt; element related to the current
   version of the sidebar whose identifier is contained in the
   &lt;confObjID&gt; field of the request.

   If an &lt;operation&gt; parameter of "delete" is included in the
   sidebarByVal request, the &lt;sidebarByValInfo&gt; parameter MUST NOT be
   included in the request.  Any &lt;sidebarByValInfo&gt; included in the
   request MUST be ignored by the conference server.  The URI for the
   conference object associated with the sidebar MUST be included in the
   &lt;confObjID&gt; parameter in the request.  If the specific conferencing
   user, as reflected by the &lt;confUserID&gt; parameter, in the request is
   authorized to delete the conference, the conference server deletes
   the conference object reflected by the &lt;confObjID&gt; parameter and
   updates the data in the conference object from which the sidebar was
   cloned.  The conference server can notify any conferencing clients
   that have subscribed to the conference event package and that are
   authorized to receive the notification of the deletion of the sidebar
   from the conference.

   If a sidebarByValRequest with an &lt;operation&gt; parameter of "retrieve",
   "update", or "delete" carries a &lt;confObjID&gt; parameter which is not
   associated with any existing sidebar-by-val, a confResponse message
   containing a &lt;response-code&gt; of "404" will be generated on the
   server's side.  This also holds for the case in which the mentioned
   &lt;confObjID&gt; parameter is related to an existing conference object
   stored at the server, but associated with a blueprint or with an
   actual conference or with a sidebar-by-ref rather than a sidebar-by-
   val.





<span class="grey">Barnes, et al.               Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarByValRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarByVal-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByValRequest"/&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarByValRequestType --&gt;

   &lt;xs:element name="sidebarByValRequest"
               type="sidebarByValRequestType" /&gt;

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


   &lt;!-- sidebarByValResponse --&gt;

   &lt;xs:complexType name="ccmp-sidebarByVal-response-message-type"&gt;
    &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
            &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByValResponse"/&gt;
            &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
    &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;












<span class="grey">Barnes, et al.               Standards Track                   [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarByValResponseType --&gt;

   &lt;xs:element name="sidebarByValResponse"
               type="sidebarByValResponseType" /&gt;

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

            Figure 14: Structure of the sidebarByValRequest and
                       sidebarByValResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.9" href="#section-5.3.9">5.3.9</a>.  sidebarsByRefRequest and sidebarsByRefResponse</span>

   Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
   invoked to retrieve the &lt;sidebars-by-ref&gt; element of the conference
   object identified by the &lt;confObjID&gt; parameter.  The
   sidebarsByRefRequest message is of a retrieve-only type, so an
   &lt;operation&gt; parameter MUST NOT be included in a sidebarsByRefRequest
   message.  In the case of a &lt;response-code&gt; of "200", the
   &lt;sidebarsByRefInfo&gt; parameter, containing the &lt;sidebars-by-ref&gt;
   element of the conference object, MUST be included in the response.
   The &lt;sidebars-by-ref&gt; element represents the set of URIs of the
   sidebars associated with the main conference, whose description (in
   the form of a standard XCON conference document) is external to the
   main conference itself.  Through the retrieved URIs, it is then
   possible to access single sidebars using the sidebarByRefRequest
   message, described in <a href="#section-5.3.10">Section 5.3.10</a>.  A sidebarsByRefResponse
   message MUST carry back to the client a &lt;version&gt; element related to
   the current version of the main conference object (i.e., the one
   whose identifier is contained in the &lt;confObjId&gt; field of the
   request) with which the sidebars in question are associated.













<span class="grey">Barnes, et al.               Standards Track                   [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarsByRefRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarsByRef-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarsByRefRequest"/&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
      &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarsByRefRequestType --&gt;

   &lt;xs:element name="sidebarsByRefRequest"
               type="sidebarsByRefRequestType" /&gt;

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

   &lt;!-- sidebarsByRefResponse --&gt;

   &lt;xs:complexType name="ccmp-sidebarsByref-response-message-type"&gt;
           &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                    &lt;xs:sequence&gt;
                           &lt;xs:element ref="sidebarsByRefResponse"/&gt;
                    &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;













<span class="grey">Barnes, et al.               Standards Track                   [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarsByRefResponseType --&gt;

   &lt;xs:element name="sidebarsByRefResponse"
               type="sidebarsByRefResponseType" /&gt;

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

             Figure 15: Structure of the sidebarsByRefRequest
                    and sidebarsByRefResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.10" href="#section-5.3.10">5.3.10</a>.  sidebarByRefRequest and sidebarByRefResponse</span>

   A sidebarByValResponse message MUST return to the client a &lt;version&gt;
   element related to the current version of the sidebar whose
   identifier is contained in the &lt;confObjID&gt; field of the request.

   In the case of a create operation, the &lt;confObjID&gt; parameter MUST be
   included in the sidebyRefRequest message.  In this case, the
   &lt;confObjID&gt; parameter contains the XCON-URI of the main conference in
   which the sidebar has to be created.  If no &lt;sidebarByRefInfo&gt;
   parameter is included, following the XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>], the
   sidebar is created by cloning the main conference, observing the
   implementation-specific cloning rules.  Otherwise, similar to the
   case of direct creation, the sidebar conference object is built on
   the basis of the &lt;sidebarByRefInfo&gt; parameter provided by the
   requestor.  If the creation of the sidebar is successful, the
   conference server MUST update the &lt;sidebars-by-ref&gt; element in the
   conference object from which the sidebar was created (i.e., as
   identified by the &lt;confObjID&gt; in the original sidebarByRefRequest),
   with the URI of the newly created sidebar.  The newly created
   conference object MAY be included in the response in the
   &lt;sidebarByRefInfo&gt; parameter with a &lt;response-code&gt; of "200".  The
   URI for the conference object associated with the newly created
   sidebar object MUST appear in the &lt;confObjID&gt; parameter of the
   response.  The conference server can notify any conferencing clients
   that have subscribed to the conference event package and that are
   authorized to receive the notification of the addition of the sidebar
   to the conference.





<span class="grey">Barnes, et al.               Standards Track                   [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   In the case of a sidebarByRefRequest message with an &lt;operation&gt;
   parameter of "retrieve", the URI for the conference object created
   for the sidebar MUST be included in the &lt;confObjID&gt; parameter in the
   request.  A retrieve operation on the &lt;sidebarByRefInfo&gt; is handled
   by the conference server in the same manner as a retrieve operation
   on the confInfo included in a confRequest message as detailed in
   <a href="#section-5.3.4">Section 5.3.4</a>.

   In the case of a sidebarByRefRequest message with an &lt;operation&gt;
   parameter of "update", the URI for the conference object created for
   the sidebar MUST be included in the &lt;confObjID&gt; parameter in the
   request.  The &lt;sidebarByRefInfo&gt; MUST also be included in the request
   in the case of an "update" operation.  An update operation on the
   &lt;sidebarByRefInfo&gt; is handled by the conference server in the same
   manner as an update operation on the &lt;confInfo&gt; included in a
   confRequest message as detailed in <a href="#section-5.3.4">Section 5.3.4</a>.  A
   sidebarByRefResponse message MUST carry back to the client a
   &lt;version&gt; element related to the current version of the sidebar whose
   identifier is contained in the &lt;confObjID&gt; field of the request.

   If an &lt;operation&gt; parameter of "delete" is included in the
   sidebarByRefRequest, the &lt;sidebarByRefInfo&gt; parameter MUST NOT be
   included in the request.  Any &lt;sidebarByRefInfo&gt; included in the
   request MUST be ignored by the conference server.  The URI for the
   conference object for the sidebar MUST be included in the &lt;confObjID&gt;
   parameter in the request.  If the specific conferencing user as
   reflected by the &lt;confUserID&gt; parameter in the request is authorized
   to delete the conference, the conference server SHOULD delete the
   conference object reflected by the &lt;confObjID&gt; parameter and SHOULD
   update the &lt;sidebars-by-ref&gt; element in the conference object from
   which the sidebar was originally cloned.  The conference server can
   notify any conferencing clients that have subscribed to the
   conference event package and that are authorized to receive the
   notification of the deletion of the sidebar.

   If a sidebarByRefRequest with an &lt;operation&gt; parameter of "retrieve",
   "update", or "delete" carries a &lt;confObjID&gt; parameter that is not
   associated with any existing sidebar-by-ref, a confResponse message
   containing a &lt;response-code&gt; of "404" will be generated on the
   server's side.  This also holds for the case in which the value of
   the mentioned &lt;confObjID&gt; parameter is related to an existing
   conference object stored at the server, but associated with a
   blueprint or with an actual conference or with a sidebar-by-val
   rather than a sidebar-by-ref.







<span class="grey">Barnes, et al.               Standards Track                   [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarByRefRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarByRef-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByRefRequest"/&gt;
                &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarByRefRequestType --&gt;

   &lt;xs:element name="sidebarByRefRequest"
               type="sidebarByRefRequestType" /&gt;

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

   &lt;!-- sidebarByRefResponse --&gt;

   &lt;xs:complexType name="ccmp-sidebarByRef-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByRefResponse"/&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;













<span class="grey">Barnes, et al.               Standards Track                   [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- sidebarByRefResponseType --&gt;

   &lt;xs:element name="sidebarByRefResponse"
               type="sidebarByRefResponseType" /&gt;

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

              Figure 16: Structure of the sidebarByRefRequest
                     and sidebarByRefResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.11" href="#section-5.3.11">5.3.11</a>.  extendedRequest and extendedResponse</span>

   In order to allow specifying new request and response pairs for
   conference control, CCMP defines the extendedRequest and
   extendedResponse messages.  Such messages constitute a CCMP skeleton
   in which implementers can transport the information needed to realize
   conference control mechanisms not explicitly envisioned in the CCMP
   specification; these mechanisms are called, in this context,
   "extensions".  Each extension is assumed to be characterized by an
   appropriate name that MUST be carried in the extendedRequest/
   extendedResponse pair in the provided &lt;extensionName&gt; field.
   Extension-specific information can be transported in the form of
   schema-defined XML elements inside the &lt;any&gt; element present in both
   extendedRequest and extendedResponse.

   The conferencing client SHOULD be able to determine the extensions
   supported by a CCMP server and to recover the XML schema defining the
   related specific elements by means of an optionsRequest/
   optionsResponse CCMP transaction (see <a href="#section-5.3.12">Section 5.3.12</a>).

   The meaning of the common CCMP parameters inherited by the
   extendedRequest and extendedResponse from the basic CCMP request and
   response messages SHOULD be preserved and exploited appropriately
   while defining an extension.









<span class="grey">Barnes, et al.               Standards Track                   [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- extendedRequest --&gt;

   &lt;xs:complexType name="ccmp-extended-request-message-type"&gt;
      &lt;xs:complexContent&gt;
          &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
             &lt;xs:sequence&gt;
                            &lt;xs:element ref="extendedRequest"/&gt;
             &lt;/xs:sequence&gt;
          &lt;/xs:extension&gt;
      &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- extendedRequestType --&gt;

   &lt;xs:element name="extendedRequest" type="extendedRequestType"/&gt;

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

   &lt;!-- extendedResponse --&gt;

   &lt;xs:complexType name="ccmp-extended-response-message-type"&gt;
      &lt;xs:complexContent&gt;
          &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
              &lt;xs:sequence&gt;
                            &lt;xs:element ref="extendedResponse"/&gt;
              &lt;/xs:sequence&gt;
          &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;














<span class="grey">Barnes, et al.               Standards Track                   [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- extendedResponseType --&gt;

   &lt;xs:element name="extendedResponse" type="extendedResponseType"/&gt;

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

              Figure 17: Structure of the extendedRequest and
                         extendedResponse Messages

<span class="h4"><a class="selflink" id="section-5.3.12" href="#section-5.3.12">5.3.12</a>.  optionsRequest and optionsResponse</span>

   The optionsRequest message (Figure 18) retrieves general information
   about conference server capabilities.  These capabilities include the
   standard CCMP messages (request/response pairs) and potential
   extension messages supported by the conference server.  As such, it
   is a basic CCMP message, rather than a specialization of the general
   CCMP request.

   The optionsResponse returns, in the appropriate &lt;options&gt; field, a
   list of the supported CCMP message pairs as defined in this
   specification.  These messages are in the form of a list: &lt;standard-
   message-list&gt; including each of the supported messages as reflected
   by &lt;standard-message&gt; elements.  The optionsResponse message also
   allows for an &lt;extended-message-list&gt;, which is a list of additional
   message types in the form of &lt;extended-message-list&gt; elements that
   are currently undefined, to allow for future extensibility.  The
   following information is provided for both types of messages:

   o  &lt;name&gt; (REQUIRED): in case of standard messages, it can be one of
      the 10 standard message names defined in this document (i.e.,
      "blueprintsRequest", "confsRequest", etc.).  In case of
      extensions, this element MUST carry the same value of the
      &lt;extension-name&gt; inserted in the corresponding extendedRequest/
      extendedResponse message pair.

   o  &lt;operations&gt; (OPTIONAL): this field is a list of &lt;operation&gt;
      entries, each representing the Create, Read, Update, Delete (CRUD)
      operation supported by the server for the message.  If this
      element is absent, the client SHOULD assume the server is able to



<span class="grey">Barnes, et al.               Standards Track                   [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


      handle the entire set of CRUD operations or, in case of standard
      messages, all the operations envisioned for that message in this
      document.

   o  &lt;schema-ref&gt; (OPTIONAL): since all CCMP messages can potentially
      contain XML elements not envisioned in the CCMP schema (due to the
      presence of &lt;any&gt; elements and attributes), a reference to a
      proper schema definition specifying such new elements/attributes
      can also be sent back to the clients by means of such field.  If
      this element is absent, no new elements are introduced in the
      messages other than those explicitly defined in the CCMP
      specification.

   o  &lt;description&gt; (OPTIONAL): human-readable information about the
      related message.

   The only parameter needed in the optionsRequest is the sender
   confUserID, which is mirrored in the same parameter of the
   corresponding optionsResponse.

   The CCMP server MUST include the &lt;standard-message-list&gt; containing
   at least one &lt;operation&gt; element in the optionsResponse, since a CCMP
   server is REQUIRED to be able to handle both the request and response
   messages for at least one of the operations.

   &lt;!-- optionsRequest --&gt;

   &lt;xs:complexType name="ccmp-options-request-message-type"&gt;
           &lt;xs:complexContent&gt;
                   &lt;xs:extension base="tns:ccmp-request-message-type"/&gt;
           &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- optionsResponse --&gt;

   &lt;xs:complexType name="ccmp-options-response-message-type"&gt;
      &lt;xs:complexContent&gt;
         &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
           &lt;xs:sequence&gt;
             &lt;xs:element ref="optionsResponse"/&gt;
           &lt;/xs:sequence&gt;
         &lt;/xs:extension&gt;
     &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;







<span class="grey">Barnes, et al.               Standards Track                   [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- optionsResponseType --&gt;

   &lt;xs:element name="optionsResponse"
                  type="optionsResponseType" /&gt;

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

   &lt;!-- options-type --&gt;

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

   &lt;!-- standard-message-list-type --&gt;

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








<span class="grey">Barnes, et al.               Standards Track                   [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- standard-message-type --&gt;

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

   &lt;!-- standard-message-name-type --&gt;

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















<span class="grey">Barnes, et al.               Standards Track                   [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- operations-type --&gt;

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

              Figure 18: Structure of the optionsRequest and
                         optionsResponse Messages

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  CCMP Response Codes</span>

   All CCMP response messages MUST include a &lt;response-code&gt;.  This
   document defines an IANA registry for the CCMP response codes, as
   described in <a href="#section-12.5.2">Section 12.5.2</a>.  The following summarizes the CCMP
   response codes:

   200 Success:

      Successful completion of the requested operation.

   400 Bad Request:

      Syntactically malformed request.

   401 Unauthorized:

      User not allowed to perform the required operation.

   403 Forbidden:

      Operation not allowed (e.g., cancellation of a blueprint).

   404 Object Not Found:

      The target conference object does not exist at the server (The
      object in the error message refers to the &lt;confObjID&gt; parameter in
      the generic request message).

   409 Conflict:

      A generic error associated with all those situations in which a
      requested client operation cannot be successfully completed by the
      server.  An example of such a situation is when the modification
      of an object cannot be applied due to conflicts arising at the



<span class="grey">Barnes, et al.               Standards Track                   [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


      server's side, e.g., because the client version of the object is
      an obsolete one and the requested modifications collide with the
      up-to-date state of the object stored at the server.  Such code
      would also be used if a client attempts to create an object
      (conference or user) with an entity that already exists.

   420 User Not Found:

      Target user missing at the server (it is related to the XCON-
      USERID in the 'entity' attribute of the &lt;userInfo&gt; parameter when
      it is included in userRequests).

   421 Invalid confUserID:

      User does not exist at the server (This code is returned for
      requests where the &lt;confUserID&gt; parameter is invalid).

   422 Invalid Conference Password:

      The password for the target conference object contained in the
      request is wrong.

   423 Conference Password Required:

      "conference-password" missing in a request to access a password-
      protected conference object.

   424 Authentication Required:

      User's authentication information is missing or invalid.

   425 Forbidden Delete Parent:

      Cancel operation failed since the target object is a parent of
      child objects that depend on it, or because it affects, based on
      the "parent-enforceable" mechanism, the corresponding element in a
      child object.

   426 Forbidden Change Protected:

      Update refused by the server because the target element cannot be
      modified due to its implicit dependence on the value of a parent
      object ("parent-enforceable" mechanism).

   427 Invalid Domain Name:

      The domain name in an AUTO_GENERATE_X instance in the conference
      object is not within the CCMP server's domain of responsibility.



<span class="grey">Barnes, et al.               Standards Track                   [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   500 Server Internal Error:

      The server cannot complete the required service due to a system
      internal error.

   501 Not Implemented:

      Operation defined by the protocol, but not implemented by this
      server.

   510 Request Timeout:

      The time required to serve the request has exceeded the configured
      service threshold.

   511 Resources Not Available:

      This code is used when the CCMP server cannot execute a command
      because of resource issues, e.g., it cannot create a sub-
      conference because the system has reached its limits on the number
      of sub-conferences, or if a request for adding a new user fails
      because the max number of users has been reached for the
      conference or the max number of users has been reached for the
      conferencing system.

   The handling of a &lt;response-code&gt; of "404", "409", "420", "421",
   "425", "426", or "427" is only applicable to specific operations for
   specialized message responses and the details are provided in
   <a href="#section-5.3">Section 5.3</a>.  The following table summarizes these response codes and
   the specialized message and operation to which they are applicable:





















<span class="grey">Barnes, et al.               Standards Track                   [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   +----------+-------------+--------------+-------------+-------------+
   | 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 be returned if the
   &lt;confUserID&gt; (contained in the 'entity' attribute of the &lt;userInfo&gt;
   parameter) of the user to be added is unknown.  In the case above, if
   instead it is the &lt;confUserID&gt; parameter of the sender of the request
   that is invalid, a &lt;response-code&gt; of "421" is returned to the
   client.



<span class="grey">Barnes, et al.               Standards Track                   [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   (**) "421" is not sent in answer to userRequest/create messages
   having a "null" confUserID, since this case is associated with a user
   who is unaware of his own XCON-USERID, but wants to enter a known
   conference.

   In the case of a &lt;response-code&gt; of "510", a conferencing client MAY
   re-attempt the request within a period of time that would be specific
   to a conferencing client or conference server.

   A &lt;response-code&gt; of "400" indicates that the conferencing client
   sent a malformed request, which is indicative of an error in the
   conferencing client or in the conference server.  The handling is
   specific to the conferencing client implementation (e.g., generate a
   log, display an error message, etc.).  It is NOT RECOMMENDED that the
   client re-attempt the request in this case.

   A &lt;response-code&gt; of "401" or "403" indicates the client does not
   have the appropriate permissions, or there is an error in the
   permissions: re-attempting the request would likely not succeed and
   thus it is NOT RECOMMENDED.

   Any unexpected or unknown &lt;response-code&gt; SHOULD be treated by the
   client in the same manner as a &lt;response-code&gt; of "500", the handling
   of which is specific to the conferencing client implementation.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  A Complete Example of CCMP in Action</span>

   In this section a typical, non-normative, scenario in which CCMP
   comes into play is described, by showing the actual composition of
   the various CCMP messages.  In the call flows of the example, the
   conferencing client is a CCMP-enabled client, and the conference
   server is a CCMP-enabled server.  The XCON-USERID of the client,
   Alice, is "xcon-userid:alice@example.com" and it appears in the
   &lt;confUserID&gt; parameter in all requests.  The sequence of operations
   is as follows:

   1.  Alice retrieves the list of available blueprints from the server
       (<a href="#section-6.1">Section 6.1</a>);

   2.  Alice asks for detailed information about a specific blueprint
       (<a href="#section-6.2">Section 6.2</a>);

   3.  Alice decides to create a new conference by cloning the retrieved
       blueprint (<a href="#section-6.3">Section 6.3</a>);

   4.  Alice modifies information (e.g., XCON-URI, name, and
       description) associated with the newly created blueprint
       (<a href="#section-6.4">Section 6.4</a>);



<span class="grey">Barnes, et al.               Standards Track                   [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   5.  Alice specifies a list of users to be contacted when the
       conference is activated (<a href="#section-6.5">Section 6.5</a>);

   6.  Alice joins the conference (<a href="#section-6.6">Section 6.6</a>);

   7.  Alice lets a new user, Ciccio, (whose XCON-USERID is
       "xcon-userid:Ciccio@example.com") join the conference
       (<a href="#section-6.7">Section 6.7</a>).

   8.  Alice asks for the CCMP server capabilities (<a href="#section-6.8">Section 6.8</a>);

   9.  Alice exploits an extension of the CCMP server (<a href="#section-6.9">Section 6.9</a>).

   Note that the examples do not include any details beyond the basic
   operation.

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

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Alice Retrieves the Available Blueprints</span>

   This section illustrates the transaction associated with retrieval of
   the blueprints, together with a dump of the two messages exchanged
   (blueprintsRequest and blueprintsResponse).  As shown in the figure,
   the blueprintsResponse message contains, in the &lt;blueprintsInfo&gt;
   parameter, information about the available blueprints, in the form of
   the standard XCON-URI of the blueprint, plus additional (and
   optional) information, like its display-text and purpose.

   Alice retrieves from the server the list of available blueprints:

    CCMP Client                                             CCMP Server
         |                                                       |
         | CCMP blueprintsRequest message                        |
         |   - confUserID: Alice                                 |
         |   - confObjID: (null)                                 |
         |------------------------------------------------------&gt;|
         |                                                       |
         |                     CCMP blueprintsResponse message   |
         |                      - confUserID: Alice              |
         |                      - confObjID: (null)              |
         |                      - response-code: 200             |
         |                      - blueprintsInfo: bp123,bp124,.. |
         |&lt;------------------------------------------------------|
         |                                                       |
         .                                                       .
         .                                                       .




<span class="grey">Barnes, et al.               Standards Track                   [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


  1. blueprintsRequest message:

  &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
  &lt;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"&gt;
      &lt;ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-blueprints-request-message-type"&gt;
          &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
          &lt;ccmp:blueprintsRequest/&gt;
      &lt;/ccmpRequest&gt;
  &lt;/ccmp:ccmpRequest&gt;

  2. blueprintsResponse message from the server:

  &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
  &lt;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"&gt;
  &lt;ccmpResponse
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ccmp:ccmp-blueprints-response-message-type"&gt;
     &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
     &lt;response-code&gt;200&lt;/response-code&gt;
       &lt;ccmp:blueprintsResponse&gt;
        &lt;blueprintsInfo&gt;
         &lt;info:entry&gt;
          &lt;info:uri&gt;xcon:AudioRoom@example.com&lt;/info:uri&gt;
          &lt;info:display-text&gt;AudioRoom&lt;/info:display-text&gt;
          &lt;info:purpose&gt;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.
          &lt;/info:purpose&gt;
         &lt;/info:entry&gt;
         &lt;info:entry&gt;
          &lt;info:uri&gt;xcon:VideoRoom@example.com&lt;/info:uri&gt;
          &lt;info:display-text&gt;VideoRoom&lt;/info:display-text&gt;
          &lt;info:purpose&gt;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.
          &lt;/info:purpose&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


         &lt;/info:entry&gt;
         &lt;info:entry&gt;
          &lt;info:uri&gt;xcon:AudioConference1@example.com&lt;/info:uri&gt;
          &lt;info:display-text&gt;AudioConference1&lt;/info:display-text&gt;
          &lt;info:purpose&gt;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.
          &lt;/info:purpose&gt;
         &lt;/info:entry&gt;
         &lt;info:entry&gt;
          &lt;info:uri&gt;xcon:VideoConference1@example.com&lt;/info:uri&gt;
          &lt;info:display-text&gt;VideoConference1&lt;/info:display-text&gt;
            &lt;info:purpose&gt;Public Video Conference: conference
                where both audio and video are available,
                only one user can talk.
            &lt;/info:purpose&gt;
          &lt;/info:entry&gt;
          &lt;info:entry&gt;
           &lt;info:uri&gt;xcon:AudioConference2@example.com&lt;/info:uri&gt;
           &lt;info:display-text&gt;AudioConference2&lt;/info:display-text&gt;
           &lt;info:purpose&gt;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.
           &lt;/info:purpose&gt;
          &lt;/info:entry&gt;
       &lt;/blueprintsInfo&gt;
     &lt;/ccmp:blueprintsResponse&gt;
    &lt;/ccmpResponse&gt;
  &lt;/ccmp:ccmpResponse&gt;

               Figure 19: Getting Blueprints from the Server

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Alice Gets Detailed Information about a Specific Blueprint</span>

   This section illustrates the second transaction in the overall flow.
   In this case, Alice, who now knows the XCON-URIs of the blueprints
   available at the server, makes a drill-down query, in the form of a
   CCMP blueprintRequest message, to get detailed information about one
   of them (the one called with XCON-URI "xcon:AudioRoom@example.com").
   The picture shows such a transaction.  Notice that the response
   contains, in the &lt;blueprintInfo&gt; parameter, a document compliant with
   the standard XCON data model.



<span class="grey">Barnes, et al.               Standards Track                   [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   Alice retrieves detailed information about a specified blueprint:

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

 1. blueprintRequest message:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
   &lt;ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:type="ccmp:ccmp-blueprint-request-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
         &lt;confObjID&gt;xcon:AudioRoom@example.com&lt;/confObjID&gt;
         &lt;operation&gt;retrieve&lt;/operation&gt;
         &lt;ccmp:blueprintRequest/&gt;
   &lt;/ccmpRequest&gt;
 &lt;/ccmp:ccmpRequest&gt;

 2. blueprintResponse message from the server:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
  &lt;ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ccmp:ccmp-blueprint-response-message-type"&gt;
  &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


  &lt;confObjID&gt;xcon:AudioRoom@example.com&lt;/confObjID&gt;
  &lt;operation&gt;retrieve&lt;/operation&gt;
  &lt;response-code&gt;200&lt;/response-code&gt;
  &lt;response-string&gt;Success&lt;/response-string&gt;
  &lt;ccmp:blueprintResponse&gt;
    &lt;blueprintInfo entity="xcon:AudioRoom@example.com"&gt;
     &lt;info:conference-description&gt;
        &lt;info:display-text&gt;AudioRoom&lt;/info:display-text&gt;
        &lt;info:available-media&gt;
           &lt;info:entry label="audioLabel"&gt;
              &lt;info:display-text&gt;audio stream&lt;/info:display-text&gt;
              &lt;info:type&gt;audio&lt;/info:type&gt;
           &lt;/info:entry&gt;
        &lt;/info:available-media&gt;
     &lt;/info:conference-description&gt;
     &lt;info:users&gt;
       &lt;xcon:join-handling&gt;allow&lt;/xcon:join-handling&gt;
      &lt;/info:users&gt;
     &lt;xcon:floor-information&gt;
      &lt;xcon:floor-request-handling&gt;confirm&lt;/xcon:floor-request-handling&gt;
       &lt;xcon:conference-floor-policy&gt;
           &lt;xcon:floor id="audioFloor"&gt;
               &lt;xcon:media-label&gt;audioLabel&lt;/xcon:media-label&gt;
           &lt;/xcon:floor&gt;
       &lt;/xcon:conference-floor-policy&gt;
     &lt;/xcon:floor-information&gt;
    &lt;/blueprintInfo&gt;
   &lt;/ccmp:blueprintResponse&gt;
  &lt;/ccmpResponse&gt;
 &lt;/ccmp:ccmpResponse&gt;

         Figure 20: Getting Information about a Specific Blueprint

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Alice Creates a New Conference through a Cloning Operation</span>

   This section illustrates the third transaction in the overall flow.
   Alice decides to create a new conference by cloning the blueprint
   having XCON-URI "xcon:AudioRoom@example.com", for which she just
   retrieved detailed information through the blueprintRequest message.
   This is achieved by sending a confRequest/create message having the
   blueprint's URI in the &lt;confObjID&gt; parameter.  The picture shows such
   a transaction.  Notice that the response contains, in the &lt;confInfo&gt;
   parameter, the document associated with the newly created conference,
   which is compliant with the standard XCON data model.  The
   &lt;confObjID&gt; parameter in the response is set to the XCON-URI of the
   new conference (in this case, "xcon:8977794@example.com").  We also





<span class="grey">Barnes, et al.               Standards Track                   [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   notice that this value is equal to the value of the 'entity'
   attribute of the &lt;conference-info&gt; element of the document
   representing the newly created 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)                                  |
       |------------------------------------------------------&gt;|
       |                                                       |
       |                            CCMP confResponse message  |
       |                              - confUserID: Alice      |
       |                              - confObjID: newConfId   |
       |                              - operation: create      |
       |                              - response-code: 200     |
       |                              - version: 1             |
       |                              - confInfo: newConfInfo  |
       |&lt;------------------------------------------------------|
       |                                                       |
       .                                                       .
       .                                                       .

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. confRequest message:</span>

&lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
&lt;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"&gt;
   &lt;ccmpRequest
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-conf-request-message-type"&gt;
      &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
      &lt;confObjID&gt;xcon:AudioRoom@example.com&lt;/confObjID&gt;
      &lt;operation&gt;create&lt;/operation&gt;
      &lt;ccmp:confRequest/&gt;
   &lt;/ccmpRequest&gt;
&lt;/ccmp:ccmpRequest&gt;







<span class="grey">Barnes, et al.               Standards Track                   [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. confResponse message from the server:</span>

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

        Figure 21: Creating a New Conference by Cloning a Blueprint






<span class="grey">Barnes, et al.               Standards Track                   [Page 64]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-65" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Alice Updates Conference Information</span>

   This section illustrates the fourth transaction in the overall flow.
   Alice decides to modify some of the details associated with the
   conference she just created.  More precisely, she changes the
   &lt;display-text&gt; element under the &lt;conference-description&gt; element of
   the document representing the conference.  This is achieved through a
   confRequest/update message carrying the fragment of the conference
   document to which the required changes have to be applied.  As shown
   in the picture, the response contains a code of "200", which
   acknowledges the modifications requested by the client, while also
   updating the conference version number from 1 to 2, as reflected in
   the "version" parameter.

   Alice updates information about the conference she just created:

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

 1. confRequest message:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
   &lt;ccmpRequest
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-conf-request-message-type"&gt;
     &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 65]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-66" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


     &lt;confObjID&gt;xcon:8977794@example.com&lt;/confObjID&gt;
     &lt;operation&gt;update&lt;/operation&gt;
     &lt;ccmp:confRequest&gt;
          &lt;confInfo entity="xcon:8977794@example.com"&gt;
             &lt;info:conference-description&gt;
               &lt;info:display-text&gt;
                  Alice's conference
               &lt;/info:display-text&gt;
             &lt;/info:conference-description&gt;
          &lt;/confInfo&gt;
       &lt;/ccmp:confRequest&gt;
   &lt;/ccmpRequest&gt;
 &lt;/ccmp:ccmpRequest&gt;

 2. confResponse message from the server:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
     &lt;ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ccmp:ccmp-conf-response-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
         &lt;confObjID&gt;xcon:8977794@example.com&lt;/confObjID&gt;
         &lt;operation&gt;update&lt;/operation&gt;
         &lt;response-code&gt;200&lt;/response-code&gt;
         &lt;response-string&gt;Success&lt;/response-string&gt;
         &lt;version&gt;2&lt;/version&gt;
         &lt;ccmp:confResponse/&gt;
     &lt;/ccmpResponse&gt;
 &lt;/ccmp:ccmpResponse&gt;

                Figure 22: Updating Conference Information

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Alice Inserts a List of Users into the Conference Object</span>

   This section illustrates the fifth transaction in the overall flow.
   Alice modifies the &lt;allowed-users-list&gt; under the &lt;users&gt; element in
   the document associated with the conference she created.  To achieve
   this, she makes use of the usersRequest message provided by CCMP.

   Alice updates information about the list of users to whom access to
   the conference is permitted:







<span class="grey">Barnes, et al.               Standards Track                   [Page 66]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-67" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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

 1. usersRequest message:

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




<span class="grey">Barnes, et al.               Standards Track                   [Page 67]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-68" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 2. usersResponse message from the server:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
     &lt;ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ccmp:ccmp-users-response-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
         &lt;confObjID&gt;xcon:8977794@example.com&lt;/confObjID&gt;
         &lt;operation&gt;retrieve&lt;/operation&gt;
         &lt;response-code&gt;200&lt;/response-code&gt;
         &lt;response-string&gt;Success&lt;/response-string&gt;
         &lt;version&gt;3&lt;/version&gt;
         &lt;ccmp:usersResponse/&gt;
     &lt;/ccmpResponse&gt;
 &lt;/ccmp:ccmpResponse&gt;

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

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Alice Joins the Conference</span>

   This section illustrates the sixth transaction in the overall flow.
   Alice uses CCMP to add herself to the newly created conference.  This
   is achieved through a userRequest/create message containing, in the
   &lt;userInfo&gt; parameter, a &lt;user&gt; element compliant with the XCON data
   model representation.  Notice that such an element includes
   information about the user's Addresses of Record, as well as her
   current endpoint.  The picture below shows the transaction.  Notice
   how the &lt;confUserID&gt; parameter is equal to the 'entity' attribute of
   the &lt;userInfo&gt; element, which indicates that the request issued by
   the client is a first-party one.

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














<span class="grey">Barnes, et al.               Standards Track                   [Page 68]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-69" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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

 1. userRequest message:

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



<span class="grey">Barnes, et al.               Standards Track                   [Page 69]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-70" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


 2. userResponse message from the server:

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
 &lt;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"&gt;
     &lt;ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="ccmp:ccmp-user-response-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
         &lt;confObjID&gt;xcon:8977794@example.com&lt;/confObjID&gt;
         &lt;operation&gt;create&lt;/operation&gt;
         &lt;response-code&gt;200&lt;/response-code&gt;
         &lt;response-string&gt;Success&lt;/response-string&gt;
         &lt;version&gt;4&lt;/version&gt;
         &lt;ccmp:userResponse/&gt;
     &lt;/ccmpResponse&gt;
 &lt;/ccmp:ccmpResponse&gt;

            Figure 24: Alice Joins the Conference through CCMP

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>.  Alice Adds a New User to the Conference</span>

   This section illustrates the seventh and last transaction in the
   overall flow.  Alice uses CCMP to add a new conferencing system user,
   Ciccio, to the conference.  This "third-party" request is realized
   through a userRequest/create message containing, in the &lt;userInfo&gt;
   parameter, a &lt;user&gt; element compliant with the XCON data model
   representation.  Notice that such an element includes information
   about Ciccio's Addresses of Record, as well as his current endpoint,
   but has a placeholder 'entity' attribute,
   "AUTO_GENERATE_1@example.com" as discussed in <a href="#section-4.3">Section 4.3</a>, since the
   XCON-USERID is initially unknown to Alice.  Thus, the conference
   server is in charge of generating a new XCON-USERID for the user
   Alice indicates (i.e., Ciccio), and returning it in the 'entity'
   attribute of the &lt;userInfo&gt; parameter carried in the response, as
   well as adding the user to the conference.  The picture below shows
   the transaction.

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










<span class="grey">Barnes, et al.               Standards Track                   [Page 70]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-71" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. "third-party" userRequest message from Alice:</span>

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



<span class="grey">Barnes, et al.               Standards Track                   [Page 71]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-72" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


        &lt;/ccmp:userRequest&gt;
    &lt;/ccmpRequest&gt;
&lt;/ccmp:ccmpRequest&gt;

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. "third-party" userResponse message from the server:</span>

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

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

<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>.  Alice Asks for the CCMP Server Capabilities</span>

   This section illustrates how Alice can discover which standard CCMP
   messages and what extensions are supported by the CCMP server with
   which she interacts through an optionsRequest/optionsResponse
   transaction.

   To prepare the optionsRequest, Alice just puts her XCON-USERID in the
   &lt;confUserID&gt; parameter.  Looking at the &lt;options&gt; element in the
   received optionsResponse, Alice infers the following server
   capabilities as regards standard CCMP messages:




<span class="grey">Barnes, et al.               Standards Track                   [Page 72]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-73" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   o  the server doesn't support sidebarsByValRequest nor the
      sidebarByValRequest messages, since they do not appear in the
      &lt;standard-message-list&gt;;

   o  the only implemented operation for the blueprintRequest message is
      "retrieve", since no other &lt;operation&gt; entries are included in the
      related &lt;operations&gt; field.

   By analyzing the &lt;extended-message-list&gt;, Alice discovers the server
   implements a bluePrint extension, referred to as "confSummaryRequest"
   in this example.  This extension allows Alice to recover via CCMP a
   brief description of a specific conference; the XML elements involved
   in this extended conference control transaction are available at the
   URL indicated in the &lt;schema-ref&gt; element, and the only operation
   provided by this extension is "retrieve".  To better understand how
   Alice can exploit the "confSummaryRequest" extension via CCMP, see
   <a href="#section-6.9">Section 6.9</a>.

   The figure below shows the optionsRequest/optionsResponse message
   exchange between Alice and the CCMP server.

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

 1. optionsRequest (Alice asks for CCMP server capabilities)

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
   &lt;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"&gt;
     &lt;ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="ccmp:ccmp-options-request-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 73]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-74" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


     &lt;/ccmpRequest&gt;
   &lt;/ccmp:ccmpRequest&gt;

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

 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
   &lt;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"&gt;
     &lt;ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="ccmp:ccmp-options-response-message-type"&gt;
         &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
         &lt;response-code&gt;200&lt;/response-code&gt;
         &lt;response-string&gt;success&lt;/response-string&gt;
         &lt;ccmp:optionsResponse&gt;
            &lt;options&gt;
               &lt;standard-message-list&gt;
                  &lt;standard-message&gt;
                     &lt;name&gt;blueprintsRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                    &lt;name&gt;blueprintRequest&lt;/name&gt;
                    &lt;operations&gt;
                      &lt;operation&gt;retrieve&lt;/operation&gt;
                    &lt;/operations&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                    &lt;name&gt;confsRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                    &lt;name&gt;confRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                     &lt;name&gt;usersRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                     &lt;name&gt;userRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                     &lt;name&gt;sidebarsByRefRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
                  &lt;standard-message&gt;
                     &lt;name&gt;sidebarByRefRequest&lt;/name&gt;
                  &lt;/standard-message&gt;
               &lt;/standard-message-list&gt;
               &lt;extended-message-list&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 74]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-75" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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

         Figure 26: Alice Asks for the Server Control Capabilities

<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>.  Alice Makes Use of a CCMP Server Extension</span>

   In this section, a very simple example of CCMP extension support is
   provided.  Alice can recover information about this and other server-
   supported extensions by issuing an optionsRequest (see <a href="#section-6.8">Section 6.8</a>).

   The extension in question is named "confSummaryRequest" and allows a
   CCMP client to obtain from the CCMP server synthetic information
   about a specific conference.  The conference summary is carried in
   the form of an XML element as follows:

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

       &lt;xs:element name="confSummary" type="conf-summary-type"/&gt;

       &lt;xs:complexType name="conf-summary-type"&gt;
         &lt;xs:sequence&gt;
           &lt;xs:element name="title" type="xs:string"/&gt;
           &lt;xs:element name="status" type="xs:string"/&gt;
           &lt;xs:element name="public" type="xs:boolean"/&gt;
           &lt;xs:element name="media" type="xs:string"/&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 75]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-76" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


         &lt;/xs:sequence&gt;
       &lt;/xs:complexType&gt;

     &lt;/xs:schema&gt;

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

   As can be inferred from the schema file, the &lt;confSummary&gt; element
   contains conference information related to the following:

   o  title

   o  status (active or registered)

   o  participation modality (if everyone is allowed to participate, the
      boolean &lt;public&gt; element is set to "true")

   o  involved media

   In order to retrieve a conference summary related to the conference
   she participates in, Alice sends to the CCMP server an
   extendedRequest with a "confSummaryRequest" &lt;extensionName&gt;,
   specifying the conference XCON-URI in the confObjID request
   parameter, as depicted in the figure below.

  CCMP Client                                             CCMP Server
       |                                                       |
       | CCMP extendedRequest message                          |
       |   - confUserID: Alice                                 |
       |   - confObjID: 8977794                                |
       |   - operation: retrieve                               |
       |   - extensionName: confSummaryRequest                 |
       |------------------------------------------------------&gt;|
       |                                                       |
       |                      CCMP extendedResponse message    |
       |                            - confUserID: Alice        |
       |                            - confObjID: 8977794       |
       |                            - operation: retrieve      |
       |                            - response-code: 200       |
       |                            - extensionName:           |
       |                              confSummaryRequest       |
       |                            - confSummary              |
       |&lt;------------------------------------------------------|
       |                                                       |
       .                                                       .
       .                                                       .




<span class="grey">Barnes, et al.               Standards Track                   [Page 76]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-77" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. extendedRequest (Alice makes use of the "confSummaryRequest")</span>

&lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
  &lt;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"&gt;
    &lt;ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:type="ccmp:ccmp-extended-request-message-type"&gt;
        &lt;confUserID&gt;xcon-userid:alice@example.com&lt;/confUserID&gt;
        &lt;confObjID&gt;xcon:8977794@example.com&lt;/confObjID&gt;
        &lt;operation&gt;retrieve&lt;/operation&gt;
        &lt;ccmp:extendedRequest&gt;
               &lt;extensionName&gt;confRequestSummary&lt;/extensionName&gt;
        &lt;/ccmp:extendedRequest&gt;
    &lt;/ccmpRequest&gt;
  &lt;/ccmp:ccmpRequest&gt;

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. extendedResponse (the server provides Alice with a brief description</span>
<span class="h2">   of the desired conference)</span>

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

       Figure 28: Alice Exploits the 'confSummaryRequest' Extension





<span class="grey">Barnes, et al.               Standards Track                   [Page 77]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-78" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Locating a Conference Server</span>

   If a conferencing client is not pre-configured to use a specific
   conference server for the requests, the client MUST first discover
   the conference server before it can send any requests.  The result of
   the discovery process, is the address of the server supporting
   conferencing.  In this document, the result is an http: or https:
   URI, which identifies a conference server.

   DNS is RECOMMENDED to be used to locate a conference server in the
   case that the client is not pre-configured to use a specific
   conference server.  URI-Enabled NAPTR (U-NAPTR) resolution for
   conferencing takes a domain name as input and produces a URI that
   identifies the conference server.  This process also requires an
   Application Service tag and an Application Protocol tag, which
   differentiate conferencing-related NAPTR records from other records
   for that domain.

   <a href="#section-12.4.1">Section 12.4.1</a> defines an Application Service tag of "XCON", which is
   used to identify the centralized conferencing (XCON) server for a
   particular domain.  The Application Protocol tag "CCMP", defined in
   <a href="#section-12.4.2">Section 12.4.2</a>, is used to identify an XCON server that understands
   CCMP.

   The NAPTR records in the following example (Figure 29) demonstrate
   the use of the Application Service and Application Protocol tags.
   Iterative NAPTR resolution is used to delegate responsibility for the
   conferencing service from "zonea.example.com." and
   "zoneb.example.com." to "outsource.example.com.".






















<span class="grey">Barnes, et al.               Standards Track                   [Page 78]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-79" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


             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

   Details for the "XCON" Application Service tag and the "CCMP"
   Application Protocol tag are included in <a href="#section-12.4">Section 12.4</a>.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Managing Notifications</span>

   As per [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>], CCMP is one of the following four protocols, which
   have been formally identified within the XCON framework:

   Conference Control Protocol:

      mediates between conference and media control client (conferencing
      client) and conference server.  This document describes such a
      protocol.

   Binary floor Control Protocol:

      operates between the floor control client and the floor control
      server.  An example of such a protocol is the Binary Floor Control
      Protocol (BFCP), specified in [<a href="./rfc4582" title="&quot;The Binary Floor Control Protocol (BFCP)&quot;">RFC4582</a>].

   Call Signaling Protocol:

      operates between the Call Signaling Client and the focus.
      Examples of call signaling protocols include SIP, H.323 and IAX.
      Such protocols are capable of negotiating a conferencing session.





<span class="grey">Barnes, et al.               Standards Track                   [Page 79]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-80" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   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 [<a href="./rfc6502" title="&quot;Conference Event Package Data Format Extension for Centralized Conferencing (XCON)&quot;">RFC6502</a>] MUST be used by the
      client for notifications of changes in the conference data as
      described below.

   The protocol specified in this document is a proactive one and is
   used by a conferencing client to send requests to a conference server
   in order to retrieve information about the conference objects stored
   by the server and to possibly manipulate them.  However, a complete
   conferencing solution is not prohibited from providing clients with a
   means for receiving asynchronous updates about the status of the
   objects available at the server.  The notification protocol, while
   conceptually independent of all the mentioned companion protocols,
   can nonetheless be chosen in a way that is consistent with the
   overall protocol architecture characterizing a specific deployment,
   as discussed in the following.

   When the conferencing control client uses SIP [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>] as the
   signaling protocol to participate in the conference, SIP event
   notification can be used.  In such a case, the conferencing control
   client MUST implement the conference event package for XCON
   [<a href="./rfc6502" title="&quot;Conference Event Package Data Format Extension for Centralized Conferencing (XCON)&quot;">RFC6502</a>].  This is the default mechanism for conferencing clients as
   is SIP for signaling per the XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>].

   In the case where the interface to the conference server is entirely
   web based, there is a common mechanism for web-based systems that
   could be used -- a "call back".  With this mechanism, the
   conferencing client provides the conference server with an HTTP URL
   that is invoked when a change occurs.  This is a common
   implementation mechanism for e-commerce.  This works well in the
   scenarios whereby 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; thus, we
   expect a future specification will document this solution.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  HTTP Transport</span>

   This section describes the use of HTTP [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>] and HTTP over TLS
   [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>] as transport mechanisms for CCMP, which a conforming
   conference server and conferencing client MUST support.



<span class="grey">Barnes, et al.               Standards Track                   [Page 80]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-81" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   Although CCMP uses HTTP as a transport, it uses a strict subset of
   HTTP features, and due to the restrictions of some features, a
   conferencing server might not be a fully compliant HTTP server.  It
   is intended that a conference server can easily be built using 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 the many options
   the full HTTP protocol offers.

   Support of HTTP authentication [<a href="./rfc2617" title="&quot;HTTP Authentication: Basic and Digest Access Authentication&quot;">RFC2617</a>] and cookies [<a href="./rfc6265" title="&quot;HTTP State Management Mechanism&quot;">RFC6265</a>] 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 <a href="#section-5.1">Section 5.1</a>).  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 does not receive the appropriate Content-
   Type and Accept header fields, the conference server SHOULD fail the
   request, returning 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 are used.  In
   the case that the conference server receives a request from the
   conferencing client containing an If-* (conditional) header, the
   conference server 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 a POST method, 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 is testing or debugging a system.  The conference server
   could provide information in the CCMP response indicating that the
   URL corresponds to a conference server and only responds to CCMP POST
   requests or the conference server could instead try to avoid any leak
   of information by returning a very generic HTTP error message such as
   405 (Method Not Allowed).





<span class="grey">Barnes, et al.               Standards Track                   [Page 81]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-82" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   The conference server populates the HTTP headers of responses so that
   they are consistent with 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 is
   the risk of stale information and/or the 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 provided by the server 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 is not supported, the conference
   server MUST NOT allow persistent connections.  The conference server
   MUST support termination of a response by the closing of a
   connection.

   Implementations of CCMP that implement HTTP transport MUST implement
   transport over TLS [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>].  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 [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>].  The device uses
   the URI obtained during conference server discovery to authenticate
   the server.  The details of this authentication method are provided
   in <a href="#section-3.1">Section 3.1</a> of HTTPS [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>].  When TLS is used, the
   conferencing client SHOULD fail a request if server authentication
   fails.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   As identified in the XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>], there are a wide
   variety of potential attacks related to conferencing, due to the
   natural involvement of multiple endpoints and the capability to
   manipulate the data on the conference server using CCMP.  Examples of
   attacks include the following: an endpoint attempting to listen to
   conferences in which it is not authorized to participate, an endpoint
   attempting to disconnect or mute other users, and an endpoint theft
   of service in attempting to create conferences it is not allowed to
   create.





<span class="grey">Barnes, et al.               Standards Track                   [Page 82]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-83" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   The following summarizes the security considerations for CCMP:

   1.  The client MUST determine the proper conference server.  The
       conference server discovery is described in <a href="#section-7">Section 7</a>.

   2.  The client MUST connect to the proper conference server.  The
       mechanisms for addressing this security consideration are
       described in <a href="#section-10.1">Section 10.1</a>.

   3.  The protocol MUST support a confidentiality and integrity
       mechanism.  As described in <a href="#section-9">Section 9</a>, implementations of CCMP
       MUST implement the HTTP transport over TLS [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>].

   4.  There are security issues associated with the authorization to
       perform actions on the conferencing system to invoke specific
       capabilities.  A conference server SHOULD ensure that only
       authorized entities can manipulate the conference data.  The
       mechanisms for addressing this security consideration are
       described in <a href="#section-10.2">Section 10.2</a>.

   5.  The privacy and security of the identity of a user in the
       conference MUST be assured.  The mechanisms to ensure the
       security and privacy of identity are discussed in <a href="#section-10.3">Section 10.3</a>.

   6.  A final issue is related to Denial-of-Service (DoS) attacks on
       the conference server itself.  The recommendations to minimize
       the potential and impact of DoS attacks are discussed in
       <a href="#section-10.4">Section 10.4</a>.

   Of the considerations listed above, items 1 and 3 are addressed
   within the referenced sections earlier in this document.  The
   remaining security considerations are addressed in detail in the
   following sections.

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Assuring That the Proper Conference Server Has Been Contacted</span>

   <a href="#section-7">Section 7</a> describes a mechanism using DNS by which a conferencing
   client discovers a conference server.  A primary concern is spoofed
   DNS replies; thus, the use of DNS Security (DNSSEC) is RECOMMENDED to
   ensure that the client receives a valid response from the DNS server
   in cases where this is a concern.

   When the CCMP transaction is conducted using TLS [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>], the
   conference server can authenticate its identity, either as a domain
   name or as an IP address, to the conferencing client by presenting a
   certificate containing that identifier as a subjectAltName (i.e., as
   an iPAddress or dNSName, respectively).  Any implementation of CCMP
   MUST be capable of being transacted over TLS so that the client can



<span class="grey">Barnes, et al.               Standards Track                   [Page 83]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-84" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   request the above authentication.  Note that, in order for the
   presented certificate to be valid at the client, the client MUST be
   able to validate the certificate following the procedures in
   [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>] in the case of HTTP as a transport.  In particular, the
   validation path of the certificate must end in one of the client's
   trust anchors, even if that trust anchor is the conference server
   certificate itself.  If the client has external information as to the
   expected identity or credentials of the proper conference server, the
   authentication checks described above MAY be omitted.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  User Authentication and Authorization</span>

   Many policy authorization decisions are based on the identity of the
   user or the role that a user may have.  The conference server MUST
   implement mechanisms for authentication of users to validate their
   identity.  There are several ways that a user might authenticate its
   identity to the system.  For users joining a conference using one of
   the call signaling protocols, the user authentication mechanisms for
   the specific protocol can be used.  For example, in the case of a
   user joining the conference using SIP signaling, the user
   authentication as defined in [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>] MUST be used.  For the case of
   users joining the conference using CCMP, the CCMP Request messages
   provide a subject field that contains a username and password, which
   can be used for authentication.  Since the CCMP messages are
   RECOMMENDED to be carried over TLS, this information can be sent
   securely.

   The XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>] provides an overview of other
   authorization mechanisms.  In the cases where a user is authorized
   via multiple mechanisms, it is RECOMMENDED that the conference server
   associate the authorization of the CCMP interface with other
   authorization mechanisms; for example, Public Switched Telephone
   Network (PSTN) users that join with a PIN and control the conference
   using CCMP.  When a conference server presents the identity of
   authorized users, it MAY provide information about the way the
   identity was proven or verified by the system.  A conference server
   can also allow a completely unauthenticated user into the system --
   this information SHOULD also be communicated to interested parties.

   Once a user is authenticated and authorized through the various
   mechanisms available on the conference server, the conference server
   MUST allocate a conference user identifier (XCON-USERID) and SHOULD
   associate the XCON-USERID with any signaling specific user
   identifiers that were used for authentication and authorization.
   This XCON-USERID can be provided to a specific user through the
   conference notification interface and MUST be provided to users that
   interact with the conferencing system using CCMP (i.e., in the
   appropriate CCMP response messages).  The XCON-USERIDs for each user/



<span class="grey">Barnes, et al.               Standards Track                   [Page 84]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-85" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   participant in the conference are contained in the 'entity' attribute
   in the &lt;user&gt; element in the conference object.  The XCON-USERID is
   REQUIRED for any subsequent operations by the user on the conference
   object and is carried in the confUserID parameter in the CCMP
   requests and responses.

   Note that the policy management of an XCON-compliant conferencing
   system is out of the scope of this document, as well as of the XCON
   working group (WG).  However, the specification of a policy
   management framework is realizable with the overall XCON
   architecture, in particular with regard to a Role-Based Access
   Control (RBAC) approach.  In RBAC, the following elements are
   identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations;
   (v) Permissions.  For all of the above elements, a direct mapping
   exists onto the main XCON entities.  As an example, RBAC objects map
   onto XCON data model objects and RBAC operations map onto CCMP
   operations.

   Future documents can define an RBAC framework for XCON, by first
   focusing on the definition of roles and then specifying the needed
   permission policy sets and role policy sets (used to associate policy
   permission sets with specific roles).  With these policies in place,
   access to a conference object compliant with the XCON data model can
   be appropriately controlled.  As far as assigning users to roles, the
   Users in the RBAC model relate directly to the &lt;users&gt; element in the
   conference object.  The &lt;users&gt; element is comprised of &lt;user&gt;
   elements representing a specific user in the conferencing system.

   Each &lt;user&gt; element contains an 'entity' attribute with the XCON-
   USERID and a &lt;role&gt; element.  Thus, each authorized user (as
   represented by an XCON-USERID) can be associated with a &lt;role&gt;
   element.

<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>.  Security and Privacy of Identity</span>

   An overview of the required privacy and anonymity for users of a
   conferencing system are provided in the XCON framework [<a href="./rfc5239" title="&quot;A Framework for Centralized Conferencing&quot;">RFC5239</a>].
   The security of the identity in the form of the XCON-USERID is
   provided in CCMP through the use of TLS.

   The conference server SHOULD support the mechanism to ensure the
   privacy of the XCON-USERID.  The conferencing client indicates the
   desired level of privacy by manipulation of the &lt;provide-anonymity&gt;
   element defined in the XCON data model [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>].  The &lt;provide-
   anonymity&gt; element controls the degree to which a user reveals their
   identity.  The following summarizes the values for the &lt;provide-
   anonymity&gt; element that the client includes in their requests:




<span class="grey">Barnes, et al.               Standards Track                   [Page 85]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-86" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


      "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).

   If the client desires privacy, the conferencing client SHOULD include
   the &lt;provide-anonymity&gt; element in the &lt;confInfo&gt; parameter in a CCMP
   confRequest message with an &lt;operation&gt; parameter of "update" or
   "create" or in the &lt;userInfo&gt; parameter in a CCMP userRequest message
   with an &lt;operation&gt; parameter of "update" or "create".  If the
   &lt;provide-anonymity&gt; element is not included in the conference object,
   then other users can see the participant's identity.  Participants
   are made aware of other participants that are "anonymous" or "semi-
   private" when they perform subsequent operations on the conference
   object or retrieve the conference object or when they receive
   subsequent notifications.

   Note that independent of the level of anonymity requested by the
   user, the identity of the user is always known by the conferencing
   system as that is required to perform the necessary authorization as
   described in <a href="#section-10.2">Section 10.2</a>.  The degree to which human administrators
   can see the information can be controlled using policies (e.g., some
   information in the data model can be hidden from human
   administrators).

<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>.  Mitigating DoS Attacks</span>

   [<a id="ref-RFC4732">RFC4732</a>] provides an overview of possible DoS attacks.  In order to
   minimize the potential for DoS attacks, it is RECOMMENDED that
   conferencing systems require user authentication and authorization
   for any client participating in a conference.  This can be
   accomplished through the use of the mechanisms described in
   <a href="#section-10.2">Section 10.2</a>, as well as by using the security mechanisms associated
   with the specific signaling (e.g., Session Initiation Protocol Secure
   (SIPS)) and media protocols (e.g., Secure Realtime Transport Protocol
   (SRTP)).  In addition, <a href="#section-4.4">Section 4.4</a> describes the use of a timer
   mechanism to alleviate the situation whereby CCMP messages pend



<span class="grey">Barnes, et al.               Standards Track                   [Page 86]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-87" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   indefinitely, thus increasing the potential that pending requests
   continue to increase when is a server is receiving more requests than
   it can process.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  XML Schema</span>

   This section gives the XML schema definition
   [<a href="#ref-W3C.REC-xmlschema-1-20041028">W3C.REC-xmlschema-1-20041028</a>] [<a href="#ref-W3C.REC-xmlschema-2-20041028">W3C.REC-xmlschema-2-20041028</a>] of the
   "application/ccmp+xml" format.  This is presented as a formal
   definition of the "application/ccmp+xml" format.  A new XML
   namespace, a new XML schema, and the MIME type for this schema are
   registered with IANA as described in <a href="#section-12">Section 12</a>.  Note that this XML
   Schema Definition is not intended to be used with on-the-fly
   validation of the presence XML document.  Whitespaces are included in
   the schema to conform to the line length restrictions of the RFC
   format without having a negative impact on the readability of the
   document.  Any conforming processor should remove leading and
   trailing white spaces.

&lt;?xml version="1.0" encoding="utf-8"?&gt;

   &lt;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"&gt;


      &lt;xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
                 schemaLocation="DataModel.xsd"/&gt;
      &lt;xs:import namespace="urn:ietf:params:xml:ns:conference-info"
                 schemaLocation="<a href="./rfc4575">rfc4575</a>.xsd"/&gt;

      &lt;xs:element name="ccmpRequest" type="ccmp-request-type" /&gt;
      &lt;xs:element name="ccmpResponse" type="ccmp-response-type" /&gt;

&lt;!-- CCMP request definition --&gt;

   &lt;xs:complexType name="ccmp-request-type"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="ccmpRequest"
                       type="ccmp-request-message-type" /&gt;
       &lt;/xs:sequence&gt;
   &lt;/xs:complexType&gt;




<span class="grey">Barnes, et al.               Standards Track                   [Page 87]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-88" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- ccmp-request-message-type --&gt;

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

&lt;!-- CCMP response definition --&gt;

   &lt;xs:complexType name="ccmp-response-type"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="ccmpResponse"
                       type="ccmp-response-message-type" /&gt;
       &lt;/xs:sequence&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- ccmp-response-message-type --&gt;

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



<span class="grey">Barnes, et al.               Standards Track                   [Page 88]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-89" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


           &lt;xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;/xs:sequence&gt;
       &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
   &lt;/xs:complexType&gt;

&lt;!-- CCMP REQUESTS --&gt;

   &lt;!-- blueprintsRequest --&gt;

   &lt;xs:complexType name="ccmp-blueprints-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintsRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- blueprintsRequestType --&gt;

   &lt;xs:element name="blueprintsRequest" type="blueprintsRequestType"/&gt;

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

   &lt;!--  blueprintRequest --&gt;

   &lt;xs:complexType name="ccmp-blueprint-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;






<span class="grey">Barnes, et al.               Standards Track                   [Page 89]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-90" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- blueprintRequestType --&gt;

   &lt;xs:element name="blueprintRequest" type="blueprintRequestType" /&gt;

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

   &lt;!-- confsRequest --&gt;

   &lt;xs:complexType name="ccmp-confs-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="confsRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- confsRequestType --&gt;

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

   &lt;!-- confRequest --&gt;

   &lt;xs:complexType name="ccmp-conf-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="confRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 90]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-91" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


       &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

   &lt;!-- confRequestType --&gt;

   &lt;xs:element name="confRequest" type="confRequestType" /&gt;

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

   &lt;!-- usersRequest --&gt;

   &lt;xs:complexType name="ccmp-users-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="usersRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- usersRequestType --&gt;

   &lt;xs:element name="usersRequest" type="usersRequestType" /&gt;

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

   &lt;!-- userRequest --&gt;

   &lt;xs:complexType name="ccmp-user-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 91]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-92" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


               &lt;xs:sequence&gt;
                   &lt;xs:element ref="userRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- userRequestType --&gt;

   &lt;xs:element name="userRequest" type="userRequestType" /&gt;

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

   &lt;!-- sidebarsByValRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarsByVal-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarsByValRequest" /&gt;
                &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

    &lt;!-- sidebarsByValRequestType --&gt;

    &lt;xs:element name="sidebarsByValRequest"
                type="sidebarsByValRequestType" /&gt;

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




<span class="grey">Barnes, et al.               Standards Track                   [Page 92]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-93" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


    &lt;!-- sidebarsByRefRequest --&gt;

    &lt;xs:complexType name="ccmp-sidebarsByRef-request-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="sidebarsByRefRequest" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

   &lt;!-- sidebarsByRefRequestType --&gt;

   &lt;xs:element name="sidebarsByRefRequest"
               type="sidebarsByRefRequestType" /&gt;

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

   &lt;!-- sidebarByValRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarByVal-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByValRequest" /&gt;
               &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarByValRequestType --&gt;

   &lt;xs:element name="sidebarByValRequest"
               type="sidebarByValRequestType"/&gt;

   &lt;xs:complexType name="sidebarByValRequestType"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="sidebarByValInfo"
                       type="info:conference-type" minOccurs="0"/&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 93]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-94" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


           &lt;xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;/xs:sequence&gt;
   &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarByRefRequest --&gt;

   &lt;xs:complexType name="ccmp-sidebarByRef-request-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="sidebarByRefRequest" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- sidebarByRefRequestType --&gt;

   &lt;xs:element name="sidebarByRefRequest"
               type="sidebarByRefRequestType" /&gt;

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

   &lt;!-- extendedRequest --&gt;

   &lt;xs:complexType name="ccmp-extended-request-message-type"&gt;
      &lt;xs:complexContent&gt;
          &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
             &lt;xs:sequence&gt;
                         &lt;xs:element ref="extendedRequest"/&gt;
             &lt;/xs:sequence&gt;
          &lt;/xs:extension&gt;
      &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;







<span class="grey">Barnes, et al.               Standards Track                   [Page 94]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-95" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- extendedRequestType --&gt;

   &lt;xs:element name="extendedRequest" type="extendedRequestType"/&gt;

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

   &lt;!-- optionsRequest --&gt;

        &lt;xs:complexType name="ccmp-options-request-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-request-message-type"&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;


&lt;!-- CCMP RESPONSES --&gt;

   &lt;!-- blueprintsResponse --&gt;

   &lt;xs:complexType name="ccmp-blueprints-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintsResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- blueprintsResponseType --&gt;

   &lt;xs:element name="blueprintsResponse" type="blueprintsResponseType"/&gt;

   &lt;xs:complexType name="blueprintsResponseType"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="blueprintsInfo" type="info:uris-type"
                       minOccurs="0"/&gt;
           &lt;xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;/xs:sequence&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 95]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-96" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


       &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
   &lt;/xs:complexType&gt;

   &lt;!-- blueprintResponse --&gt;

   &lt;xs:complexType name="ccmp-blueprint-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                   &lt;xs:element ref="blueprintResponse" /&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- blueprintResponseType --&gt;

    &lt;xs:element name="blueprintResponse" type="blueprintResponseType"/&gt;

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

    &lt;!-- confsResponse --&gt;

    &lt;xs:complexType name="ccmp-confs-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="confsResponse" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- confsResponseType --&gt;

    &lt;xs:element name="confsResponse" type="confsResponseType" /&gt;

    &lt;xs:complexType name="confsResponseType"&gt;
        &lt;xs:sequence&gt;
            &lt;xs:element name="confsInfo" type="info:uris-type"



<span class="grey">Barnes, et al.               Standards Track                   [Page 96]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-97" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


                        minOccurs="0"/&gt;
            &lt;xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/&gt;
        &lt;/xs:sequence&gt;
        &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- confResponse --&gt;

    &lt;xs:complexType name="ccmp-conf-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="confResponse"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- confResponseType --&gt;

    &lt;xs:element name="confResponse" type="confResponseType" /&gt;

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

    &lt;!-- usersResponse --&gt;

    &lt;xs:complexType name="ccmp-users-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="usersResponse" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
         &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;







<span class="grey">Barnes, et al.               Standards Track                   [Page 97]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-98" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


    &lt;!-- usersResponseType --&gt;

    &lt;xs:element name="usersResponse" type="usersResponseType" /&gt;

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

    &lt;!-- userResponse --&gt;

    &lt;xs:complexType name="ccmp-user-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="userResponse" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- userResponseType --&gt;

    &lt;xs:element name="userResponse" type="userResponseType" /&gt;

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

    &lt;!-- sidebarsByValResponse --&gt;

    &lt;xs:complexType name="ccmp-sidebarsByVal-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="sidebarsByValResponse" /&gt;
                &lt;/xs:sequence&gt;



<span class="grey">Barnes, et al.               Standards Track                   [Page 98]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-99" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- sidebarsByValResponseType --&gt;

    &lt;xs:element name="sidebarsByValResponse"
                type="sidebarsByValResponseType" /&gt;

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

    &lt;!-- sidebarsByRefResponse --&gt;

    &lt;xs:complexType name="ccmp-sidebarsByRef-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="sidebarsByRefResponse" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
       &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- sidebarsByRefResponseType --&gt;

    &lt;xs:element name="sidebarsByRefResponse"
                type="sidebarsByRefResponseType" /&gt;

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






<span class="grey">Barnes, et al.               Standards Track                   [Page 99]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-100" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


    &lt;!-- sidebarByValResponse --&gt;

    &lt;xs:complexType name="ccmp-sidebarByVal-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="sidebarByValResponse" /&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- sidebarByValResponseType --&gt;

    &lt;xs:element name="sidebarByValResponse"
                type="sidebarByValResponseType" /&gt;

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

    &lt;!-- sidebarByRefResponse --&gt;

    &lt;xs:complexType name="ccmp-sidebarByRef-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="sidebarByRefResponse" /&gt;
                 &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- sidebarByRefResponseType --&gt;

    &lt;xs:element name="sidebarByRefResponse"
                type="sidebarByRefResponseType" /&gt;

    &lt;xs:complexType name="sidebarByRefResponseType"&gt;
        &lt;xs:sequence&gt;
            &lt;xs:element name="sidebarByRefInfo"
                        type="info:conference-type" minOccurs="0"/&gt;



<span class="grey">Barnes, et al.               Standards Track                  [Page 100]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-101" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


            &lt;xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/&gt;
        &lt;/xs:sequence&gt;
        &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- extendedResponse --&gt;

    &lt;xs:complexType name="ccmp-extended-response-message-type"&gt;
       &lt;xs:complexContent&gt;
           &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
               &lt;xs:sequence&gt;
                                 &lt;xs:element ref="extendedResponse"/&gt;
               &lt;/xs:sequence&gt;
           &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- extendedResponseType --&gt;

    &lt;xs:element name="extendedResponse" type="extendedResponseType"/&gt;

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

    &lt;!-- optionsResponse --&gt;

        &lt;xs:complexType name="ccmp-options-response-message-type"&gt;
        &lt;xs:complexContent&gt;
            &lt;xs:extension base="tns:ccmp-response-message-type"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="optionsResponse"/&gt;
                 &lt;/xs:sequence&gt;
            &lt;/xs:extension&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;

    &lt;!-- optionsResponseType --&gt;

    &lt;xs:element name="optionsResponse"
                type="optionsResponseType" /&gt;



<span class="grey">Barnes, et al.               Standards Track                  [Page 101]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-102" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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

&lt;!-- CCMP ELEMENT TYPES --&gt;

    &lt;!-- response-codeType--&gt;

    &lt;xs:simpleType name="response-codeType"&gt;
         &lt;xs:restriction base="xs:positiveInteger"&gt;
                 &lt;xs:pattern value="[0-9][0-9][0-9]" /&gt;
         &lt;/xs:restriction&gt;
    &lt;/xs:simpleType&gt;

    &lt;!-- operationType --&gt;

    &lt;xs:simpleType name="operationType"&gt;
      &lt;xs:restriction base="xs:token"&gt;
        &lt;xs:enumeration value="retrieve"/&gt;
        &lt;xs:enumeration value="create"/&gt;
        &lt;xs:enumeration value="update"/&gt;
        &lt;xs:enumeration value="delete"/&gt;
      &lt;/xs:restriction&gt;
    &lt;/xs:simpleType&gt;

   &lt;!-- subject-type --&gt;

   &lt;xs:complexType name="subject-type"&gt;
       &lt;xs:sequence&gt;
           &lt;xs:element name="username" type="xs:string"
                       minOccurs="0" maxOccurs="1" /&gt;
           &lt;xs:element name="password" type="xs:string"
                       minOccurs="0" maxOccurs="1" /&gt;
           &lt;xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;/xs:sequence&gt;
       &lt;xs:anyAttribute namespace="##any" processContents="lax"/&gt;
   &lt;/xs:complexType&gt;







<span class="grey">Barnes, et al.               Standards Track                  [Page 102]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-103" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   &lt;!-- options-type --&gt;

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

    &lt;!-- standard-message-list-type --&gt;

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

    &lt;!-- standard-message-type --&gt;

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





<span class="grey">Barnes, et al.               Standards Track                  [Page 103]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-104" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


    &lt;!-- standard-message-name-type --&gt;

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

    &lt;!-- operations-type --&gt;

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

    &lt;!-- extended-message-list-type --&gt;

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

    &lt;!-- extended-message-type --&gt;

    &lt;xs:complexType name="extended-message-type"&gt;
      &lt;xs:sequence&gt;
        &lt;xs:element name="name" type="xs:string" /&gt;
        &lt;xs:element name="operations"
                    type="operations-type"
                    minOccurs="0"/&gt;



<span class="grey">Barnes, et al.               Standards Track                  [Page 104]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-105" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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

 &lt;/xs:schema&gt;

                        Figure 30: CCMP XML Schema

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  IANA Considerations</span>

   This document registers a new XML namespace, a new XML schema, and
   the MIME type for the schema.  This document also registers the
   "XCON" Application Service tag and the "CCMP" Application Protocol
   tag and defines registries for the CCMP operation types and response
   codes.

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  URN Sub-Namespace Registration</span>

   This section registers a 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).




















<span class="grey">Barnes, et al.               Standards Track                  [Page 105]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-106" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


      XML:

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


<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  XML Schema Registration</span>

   This section registers an XML schema per the guidelines in [<a href="./rfc3688" title="&quot;The IETF XML Registry&quot;">RFC3688</a>].

   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 can be found as the entirety of
      <a href="#section-11">Section 11</a> of this document.

<span class="h3"><a class="selflink" id="section-12.3" href="#section-12.3">12.3</a>.  MIME Media Type Registration for 'application/ccmp+xml'</span>

   This section registers the "application/ccmp+xml" MIME type.

   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)






<span class="grey">Barnes, et al.               Standards Track                  [Page 106]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-107" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   Optional parameters:  charset
      Same as the charset parameter of "application/xml" as specified in
      <a href="./rfc3023#section-3.2">[RFC3023], Section&nbsp;3.2</a>.

   Encoding considerations:  Same as the encoding considerations of
      "application/xml" as specified in <a href="./rfc3023#section-3.2">[RFC3023], Section&nbsp;3.2</a>.

   Security considerations:  This content type is designed to carry
      protocol data related to conference control.  Some of the data
      could be considered private.  This media type does not provide any
      protection and thus other mechanisms such as those described in
      <a href="#section-10">Section 10</a> are required to protect the data.  This media type does
      not contain executable content.

   Interoperability considerations:  None.

   Published specification:  <a href="./rfc6503">RFC 6503</a>.

   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 &amp; email address to contact for further information:  Mary
      Barnes &lt;mary.ietf.barnes@gmail.com&gt;

   Intended usage:  LIMITED USE

   Author/Change controller:  The IETF

   Other information:  This media type is a specialization of
      application/xml [<a href="./rfc3023" title="&quot;XML Media Types&quot;">RFC3023</a>], and many of the considerations
      described there also apply to application/ccmp+xml.

<span class="h3"><a class="selflink" id="section-12.4" href="#section-12.4">12.4</a>.  DNS Registrations</span>

   <a href="#section-12.4.1">Section 12.4.1</a> defines an Application Service tag of "XCON", which is
   used to identify the centralized conferencing (XCON) server for a
   particular domain.  The Application Protocol tag "CCMP", defined in
   <a href="#section-12.4.2">Section 12.4.2</a>, is used to identify an XCON server that understands
   CCMP.








<span class="grey">Barnes, et al.               Standards Track                  [Page 107]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-108" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h4"><a class="selflink" id="section-12.4.1" href="#section-12.4.1">12.4.1</a>.  Registration of a Conference Server Application Service Tag</span>

   This section registers a new S-NAPTR/U-NAPTR Application Service tag
   for XCON, as mandated by [<a href="./rfc3958" title="&quot;Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)&quot;">RFC3958</a>].

   Application Service Tag: XCON

   Intended usage: Identifies a server that supports centralized
   conferencing.

   Defining publication: <a href="./rfc6503">RFC 6503</a>

   Contact information: The authors of this document

   Author/Change controller: The IESG

<span class="h4"><a class="selflink" id="section-12.4.2" href="#section-12.4.2">12.4.2</a>.  Registration of a Conference Server Application Protocol Tag</span>
<span class="h4">         for CCMP</span>

   This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
   for CCMP, as mandated by [<a href="./rfc3958" title="&quot;Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)&quot;">RFC3958</a>].

   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: <a href="./rfc6503">RFC 6503</a>

   Contact Information: The authors of this document

   Author/Change Controller: The IESG

<span class="h3"><a class="selflink" id="section-12.5" href="#section-12.5">12.5</a>.  CCMP Protocol Registry</span>

   The IANA has created a new registry for CCMP:
   <a href="http://www.iana.org/assignments/ccmp-parameters">http://www.iana.org/assignments/ccmp-parameters</a>.  The document
   creates initial sub-registries for CCMP operation types and response
   codes.








<span class="grey">Barnes, et al.               Standards Track                  [Page 108]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-109" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h4"><a class="selflink" id="section-12.5.1" href="#section-12.5.1">12.5.1</a>.  CCMP Message Types</span>

   The following summarizes the registry for CCMP messages:

   Related Registry:   CCMP Message Types Registry

   Defining RFC:  <a href="./rfc6503">RFC 6503</a>.

   Registration/Assignment Procedures:  Following the policies outlined
      in [<a href="./rfc5226" title="">RFC5226</a>], 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 establishes the Message sub-registry under
   <a href="http://www.iana.org/assignments/ccmp-messages">http://www.iana.org/assignments/ccmp-messages</a>.  The initial Message
   table is populated using the CCMP messages described in <a href="#section-4.1">Section 4.1</a>
   and defined in the XML schema in <a href="#section-11">Section 11</a>.

  Message              Description                             Reference
  -------              -----------                             ---------
  optionsRequest       Used by a conferencing client           [<a href="./rfc6503">RFC6503</a>]
                       to query a conference server for
                       its capabilities, in terms of
                       supported messages.

  optionsResponse      Returns a list of CCMP messages         [<a href="./rfc6503">RFC6503</a>]
                       supported by the specific
                       conference server.

  blueprintsRequest    Used by a conferencing client           [<a href="./rfc6503">RFC6503</a>]
                       to query a conference server for
                       its capabilities, in terms of
                       available conference blueprints.

  blueprintsResponse   Returns a list of blueprints supported  [<a href="./rfc6503">RFC6503</a>]
                       by the specific conference server.

  blueprintRequest     Sent to retrieve the conference object  [<a href="./rfc6503">RFC6503</a>]
                       associated with a specific blueprint.

  blueprintResponse    Returns the conference object           [<a href="./rfc6503">RFC6503</a>]
                       associated with a specific blueprint.

  confsRequest         Used by a conferencing client           [<a href="./rfc6503">RFC6503</a>]
                       to query a conference server for
                       its scheduled/active conferences.



<span class="grey">Barnes, et al.               Standards Track                  [Page 109]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-110" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


  confsResponse        Returns the list of the currently       [<a href="./rfc6503">RFC6503</a>]
                       activated/scheduled conferences
                       at the server.

  confRequest          Used to create a conference object      [<a href="./rfc6503">RFC6503</a>]
                       and/or to request an operation on
                       the conference object as a whole.

  confResponse         Indicates the result of the operation   [<a href="./rfc6503">RFC6503</a>]
                       on the conference object as a whole.

  userRequest          Used to request an operation on the     [<a href="./rfc6503">RFC6503</a>]
                       &lt;user&gt; element in the conference object.

  userResponse         Indicates the result of the requested   [<a href="./rfc6503">RFC6503</a>]
                       operation on the &lt;user&gt; element in
                       the conference object.

  usersRequest         Used to manipulate the &lt;users&gt; element  [<a href="./rfc6503">RFC6503</a>]
                       in the conference object, including
                       parameters such as the &lt;allowed-users-list&gt;,
                       &lt;join-handling&gt;, etc.

  usersResponse        Indicates the result of the request     [<a href="./rfc6503">RFC6503</a>]
                       to manipulate the &lt;users&gt; element in
                       the conference object.

  sidebarsByValRequest Used to retrieve the &lt;sidebars-by-val&gt;  [<a href="./rfc6503">RFC6503</a>]
                       element of the target conference object.

  sidebarsByValResponse Returns the list of the sidebar-by-val [<a href="./rfc6503">RFC6503</a>]
                        conferences within the target
                        conference object.

  sidebarsByRefRequest  Used to retrieve the &lt;sidebars-by-ref&gt; [<a href="./rfc6503">RFC6503</a>]
                        element of the target conference
                        object.

  sidebarsByRefResponse Returns the list of the sidebar-by-ref [<a href="./rfc6503">RFC6503</a>]
                        conferences associated with the target
                        conference object.

  sidebarByValRequest  Used to request an operation on a       [<a href="./rfc6503">RFC6503</a>]
                       sidebar-by-val conference.

  sidebarByValResponse Indicates the result of the request to  [<a href="./rfc6503">RFC6503</a>]
                       manipulate a sidebar-by-val conference.




<span class="grey">Barnes, et al.               Standards Track                  [Page 110]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-111" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


  sidebarByRefRequest  Used to request an operation on a       [<a href="./rfc6503">RFC6503</a>]
                       sideber-by-ref conference.

  sidebarByRefResponse Indicates the result of the request to  [<a href="./rfc6503">RFC6503</a>]
                       manipulate a sidebar-by-ref conference.

<span class="h4"><a class="selflink" id="section-12.5.2" href="#section-12.5.2">12.5.2</a>.  CCMP Response Codes</span>

   The following summarizes the requested registry for CCMP response
   codes:

   Related Registry:   CCMP Response Code Registry

   Defining RFC:  <a href="./rfc6503">RFC 6503</a>.

   Registration/Assignment Procedures:  Following the policies outlined
      in [<a href="./rfc5226" title="">RFC5226</a>], 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 establishes the Response-code sub-registry under
   <a href="http://www.iana.org/assignments/ccmp-parameters">http://www.iana.org/assignments/ccmp-parameters</a>.  The initial
   Response-code table is populated using the Response codes defined in
   <a href="#section-5.4">Section 5.4</a> as follows:

         Default
         Response
  Number String              Description                       Reference
  ------ -------------       ------------                      ---------
   200   Success             The request was successfully      [<a href="./rfc6503">RFC6503</a>]
                             processed.

   400   Bad Request         The request was badly formed in   [<a href="./rfc6503">RFC6503</a>]
                             some fashion.

   401   Unauthorized        The user was not authorized for   [<a href="./rfc6503">RFC6503</a>]
                             the specific operation on the
                             conference object.

   403   Forbidden           The specific operation is not     [<a href="./rfc6503">RFC6503</a>]
                             valid for the target conference
                             object.

   404   Object Not Found    The specific conference object    [<a href="./rfc6503">RFC6503</a>]
                             was not found.




<span class="grey">Barnes, et al.               Standards Track                  [Page 111]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-112" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   409   Conflict            A requested operation cannot be   [<a href="./rfc6503">RFC6503</a>]
                             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 [<a href="./rfc6503">RFC6503</a>]
                             requested operation is unknown.

   421   Invalid confUserID  The &lt;confUserID&gt; parameter of the [<a href="./rfc6503">RFC6503</a>]
                             sender in the request is invalid.


   422   Invalid Conference  A request to access/manipulate    [<a href="./rfc6503">RFC6503</a>]
         Password            a password-protected conference
                             object contained an invalid
                             &lt;conference-password&gt; parameter.

   423   Conference Password A request to access/manipulate    [<a href="./rfc6503">RFC6503</a>]
         Required            a password-protected conference
                             object did not contain a
                             &lt;conference-password&gt; parameter.

   424   Authentication      The server wants to authenticate  [<a href="./rfc6503">RFC6503</a>]
         Required            the request through the &lt;subject&gt;
                             parameter but the parameter is
                             not provided in the request.

   425   Forbidden Delete    The conferencing system cannot    [<a href="./rfc6503">RFC6503</a>]
         Parent              delete the specific conference
                             object because it is a
                             parent for another conference object.

   426   Forbidden Change    The target conference object      [<a href="./rfc6503">RFC6503</a>]
         Protected           cannot be changed (e.g., due to
                             policies, roles or privileges).

   427   Invalid Domain Name The domain name in an             [<a href="./rfc6503">RFC6503</a>]
                             AUTO_GENERATE_X
                             instance in the conference object
                             is not within the conference
                             server's domain of responsibility.




<span class="grey">Barnes, et al.               Standards Track                  [Page 112]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-113" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   500   Server Internal     The conference server experienced [<a href="./rfc6503">RFC6503</a>]
         Error               some sort of internal error.

   501   Not Implemented     The specific operation is not     [<a href="./rfc6503">RFC6503</a>]
                             implemented on the conferencing
                             system.

   510   Request Timeout     The request could not be          [<a href="./rfc6503">RFC6503</a>]
                             processed within a reasonable
                             time (as specified by the
                             conferencing system).

   511   Resources Not       The conference server cannot      [<a href="./rfc6503">RFC6503</a>]
         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.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Acknowledgments</span>

   The authors appreciate the feedback provided by 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 thanks go to Roberta Presta for her
   invaluable contribution to this document.  Roberta has worked on the
   specification of CCMP at the University of Napoli for the preparation
   of her Master thesis.  She has also implemented the CCMP prototype
   used for the trials and from which the dumps provided in <a href="#section-6">Section 6</a>
   have been extracted.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  References</span>

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2616">RFC2616</a>]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.

   [<a id="ref-RFC2617">RFC2617</a>]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              <a href="./rfc2617">RFC 2617</a>, June 1999.



<span class="grey">Barnes, et al.               Standards Track                  [Page 113]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-114" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   [<a id="ref-RFC2818">RFC2818</a>]  Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000.

   [<a id="ref-RFC3688">RFC3688</a>]  Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
              January 2004.

   [<a id="ref-RFC5239">RFC5239</a>]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", <a href="./rfc5239">RFC 5239</a>, June 2008.

   [<a id="ref-RFC5246">RFC5246</a>]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.

   [<a id="ref-RFC6265">RFC6265</a>]  Barth, A., "HTTP State Management Mechanism", <a href="./rfc6265">RFC 6265</a>,
              April 2011.

   [<a id="ref-RFC6501">RFC6501</a>]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", <a href="./rfc6501">RFC 6501</a>, March 2012.

   [<a id="ref-W3C.REC-xmlschema-1-20041028">W3C.REC-xmlschema-1-20041028</a>]
              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,
              &lt;<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028</a>&gt;.

   [<a id="ref-W3C.REC-xmlschema-2-20041028">W3C.REC-xmlschema-2-20041028</a>]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium
              Recommendation REC-xmlschema-2-20041028, October 2004,
              &lt;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028</a>&gt;.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  Informative References</span>

   [<a id="ref-REST">REST</a>]     Fielding, "Architectural Styles and the Design of Network-
              based Software Architectures", 2000.

   [<a id="ref-RFC3023">RFC3023</a>]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", <a href="./rfc3023">RFC 3023</a>, January 2001.

   [<a id="ref-RFC3261">RFC3261</a>]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
              June 2002.

   [<a id="ref-RFC3958">RFC3958</a>]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", <a href="./rfc3958">RFC 3958</a>, January 2005.




<span class="grey">Barnes, et al.               Standards Track                  [Page 114]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-115" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   [<a id="ref-RFC4582">RFC4582</a>]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", <a href="./rfc4582">RFC 4582</a>, November 2006.

   [<a id="ref-RFC4732">RFC4732</a>]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", <a href="./rfc4732">RFC 4732</a>, December 2006.

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              May 2008.

   [<a id="ref-RFC6502">RFC6502</a>]  Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing (XCON)", <a href="./rfc6502">RFC 6502</a>,
              March 2012.

   [<a id="ref-W3C.REC-soap12-part1-20070427">W3C.REC-soap12-part1-20070427</a>]
              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,
              &lt;<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427">http://www.w3.org/TR/2007/REC-soap12-part1-20070427</a>&gt;.

   [<a id="ref-W3C.REC-soap12-part2-20070427">W3C.REC-soap12-part2-20070427</a>]
              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,
              &lt;<a href="http://www.w3.org/TR/2007/REC-soap12-part2-20070427">http://www.w3.org/TR/2007/REC-soap12-part2-20070427</a>&gt;.





















<span class="grey">Barnes, et al.               Standards Track                  [Page 115]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-116" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Evaluation of Other Protocol Models and  Transports</span>
             Considered for CCMP

   This section provides some background as to the selection of HTTP as
   the transport for the CCMP requests/responses.  In addition to HTTP,
   the operations on the objects can be implemented in at least two
   different ways, namely as remote procedure calls -- using SOAP as
   described in <a href="#appendix-A.1">Appendix A.1</a> and by defining resources following a
   RESTful architecture <a href="#appendix-A.2">Appendix A.2</a>.

   In both the SOAP and RESTFUL approaches, servers will have to
   recreate their internal state representation of the object with each
   update request, checking parameters and triggering function
   invocations.  In the SOAP approach, it would be possible to describe
   a separate operation for each atomic element, but that would greatly
   increase the complexity of the protocol.  A coarser-grained approach
   to CCMP does require that the server process XML elements in updates
   that have not changed and that there can be multiple changes in one
   update.  For CCMP, the resource (REST) model might appear more
   attractive, since the conference operations fit the CRUD approach.

   However, neither of these approaches were considered ideal.  SOAP was
   considered to bring additional overhead.  It is quite awkward to
   apply a RESTful approach since CCMP requires a more complex request/
   response protocol in order to maintain the data both in the server
   and at the client.  This doesn't map very elegantly to the basic
   request/response model, whereby a response typically indicates
   whether the request was successful or not, rather than providing
   additional data to maintain the synchronization between the client
   and server data.  In addition, the CCMP clients may also receive the
   data in notifications.  While the notification method or protocol
   used by some conferencing clients can be independent of CCMP, the
   same data in the server is used for both CCMP and notifications -
   this requires a server application above the transport layer (e.g.,
   HTTP) for maintaining the data, which in the CCMP model is
   transparent to the transport protocol.

   Thus, the solution for CCMP defined in this document is viewed as a
   good compromise amongst the most notable past candidates and is
   referred to as "HTTP single-verb transport plus CCMP body".  With
   this approach, CCMP is able to take advantage of existing HTTP
   functionality.  As with SOAP, CCMP uses a "single HTTP verb" for
   transport (i.e., a single transaction type for each request/response
   pair); this allows decoupling CCMP messages from HTTP messages.
   Similarly, as with any RESTful approach, CCMP messages are inserted
   directly in the body of HTTP messages, thus avoiding any unnecessary
   processing and communication burden associated with further
   intermediaries.  With this approach, no modification to the CCMP



<span class="grey">Barnes, et al.               Standards Track                  [Page 116]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-117" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   messages/operations is required to use a different transport
   protocol.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Using SOAP for CCMP</span>

   A remote procedure call (RPC) mechanism for CCMP could use SOAP
   (Simple Object Access Protocol [<a href="#ref-W3C.REC-soap12-part1-20070427">W3C.REC-soap12-part1-20070427</a>]
   [<a href="#ref-W3C.REC-soap12-part2-20070427">W3C.REC-soap12-part2-20070427</a>]), 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.  This approach has
   the advantage that it can easily define atomic operations that have
   well-defined error conditions.

   All SOAP operations would use a single HTTP verb.  While the RESTful
   approach requires the use of a URI for each object, SOAP can use any
   token.

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  A RESTful Approach for CCMP</span>

   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,
   such as 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 characterizing a specified conference instance, be it an
   active conference or a conference blueprint used by the conference
   server to create new conference instances through a simple clone
   operation.

   Following the CRUD approach, CCMP could use a general-purpose
   protocol such as HTTP [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>] to transfer domain-specific XML-
   encoded data objects defined in the "Conference Information Data
   Model for Centralized Conferencing" [<a href="./rfc6501" title="&quot;Conference Information Data Model for Centralized Conferencing (XCON)&quot;">RFC6501</a>].

   Following on the CRUD approach, CCMP could follow the well-known REST
   (REpresentational State Transfer) architectural style [<a href="#ref-REST" title="&quot;Architectural Styles and the Design of Network- based Software Architectures&quot;">REST</a>].  CCMP
   could map onto the REST philosophy, by specifying resource URIs,
   resource formats, methods supported at each URI and status codes that
   have to be returned when a certain method is invoked on a specific
   URI.  A REST-style approach must ensure sure that all operations can
   be mapped to HTTP operations.





<span class="grey">Barnes, et al.               Standards Track                  [Page 117]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-118" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


   The following summarizes the specific HTTP method that could be used
   for each of the CCMP Requests:

   Retrieve: HTTP 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: HTTP PUT could be used to create a new object as identified
   by the XCON-URI or XCON-USERID.

   Change: Either HTTP PATCH or HTTP POST could be used to change the
   conference object identified by the XCON-URI.

   Delete: HTTP DELETE could be used to delete conference objects and
   parameters within conference objects identified by the XCON-URI.




































<span class="grey">Barnes, et al.               Standards Track                  [Page 118]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-119" ></span>
<span class="grey"><a href="./rfc6503">RFC 6503</a>                          CCMP                        March 2012</span>


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



















Barnes, et al.               Standards Track                  [Page 119]
</pre>