doc: Add RFC documents

1 files changed, 6667 insertions, 0 deletions

diff --git a/doc/rfc/rfc6503.txt b/doc/rfc/rfc6503.txt
new file mode 100644
index 0000000..6f3f29b
--- /dev/null
+++ b/doc/rfc/rfc6503.txt
@@ -0,0 +1,6667 @@
+
+
+
+
+
+
+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
+
+
+             Centralized Conferencing Manipulation Protocol
+
+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 Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6503.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 1]
+
+RFC 6503                          CCMP                        March 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions and Terminology .....................................5
+   3. XCON Conference Control System Architecture .....................5
+      3.1. Conference Objects .........................................7
+      3.2. Conference Users ...........................................7
+   4. Protocol Overview ...............................................8
+      4.1. Protocol Operations ........................................9
+      4.2. Data Management ...........................................10
+      4.3. Data Model Compliance .....................................11
+      4.4. Implementation Approach ...................................12
+   5. CCMP Messages ..................................................13
+      5.1. CCMP Request Message Type .................................13
+      5.2. CCMP Response Message Type ................................15
+      5.3. Detailed Messages .........................................17
+           5.3.1. blueprintsRequest and blueprintsResponse ...........20
+           5.3.2. confsRequest and confsResponse .....................22
+           5.3.3. blueprintRequest and blueprintResponse .............24
+           5.3.4. confRequest and confResponse .......................26
+           5.3.5. usersRequest and usersResponse .....................30
+           5.3.6. userRequest and userResponse .......................32
+           5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37
+           5.3.8. sidebarByValRequest and sidebarByValResponse .......39
+           5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42
+           5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44
+           5.3.11. extendedRequest and extendedResponse ..............47
+           5.3.12. optionsRequest and optionsResponse ................49
+      5.4. CCMP Response Codes .......................................53
+   6. A Complete Example of CCMP in Action ...........................57
+      6.1. Alice Retrieves the Available Blueprints ..................58
+      6.2. Alice Gets Detailed Information about a Specific
+           Blueprint .................................................60
+
+
+
+Barnes, et al.               Standards Track                    [Page 2]
+
+RFC 6503                          CCMP                        March 2012
+
+
+      6.3. Alice Creates a New Conference through a Cloning
+           Operation .................................................62
+      6.4. Alice Updates Conference Information ......................65
+      6.5. Alice Inserts a List of Users into the Conference Object ..66
+      6.6. Alice Joins the Conference ................................68
+      6.7. Alice Adds a New User to the Conference ...................70
+      6.8. Alice Asks for the CCMP Server Capabilities ...............72
+      6.9. Alice Makes Use of a CCMP Server Extension ................75
+   7. Locating a Conference Server ...................................78
+   8. Managing Notifications .........................................79
+   9. HTTP Transport .................................................80
+   10. Security Considerations .......................................82
+      10.1. Assuring That the Proper Conference Server Has
+            Been Contacted ...........................................83
+      10.2. User Authentication and Authorization ....................84
+      10.3. Security and Privacy of Identity .........................85
+      10.4. Mitigating DoS Attacks ...................................86
+   11. XML Schema ....................................................87
+   12. IANA Considerations ..........................................105
+      12.1. URN Sub-Namespace Registration ..........................105
+      12.2. XML Schema Registration .................................106
+      12.3. MIME Media Type Registration for
+            'application/ccmp+xml' ..................................106
+      12.4. DNS Registrations .......................................107
+           12.4.1. Registration of a Conference Server
+                   Application Service Tag ..........................108
+           12.4.2. Registration of a Conference Server
+                   Application Protocol Tag for CCMP ................108
+      12.5. CCMP Protocol Registry ..................................108
+           12.5.1. CCMP Message Types ...............................109
+           12.5.2. CCMP Response Codes ..............................111
+   13. Acknowledgments ..............................................113
+   14. References ...................................................113
+      14.1. Normative References ....................................113
+      14.2. Informative References ..................................114
+   Appendix A.  Evaluation of Other Protocol Models and
+                Transports Considered for CCMP ......................116
+     A.1.  Using SOAP for CCMP ......................................117
+     A.2.  A RESTful Approach for CCMP ..............................117
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 3]
+
+RFC 6503                          CCMP                        March 2012
+
+
+1.  Introduction
+
+   "A Framework for Centralized Conferencing" [RFC5239] (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 [RFC2616] as the protocol
+   to transfer requests and responses, which contain the domain-specific
+   XML-encoded data objects defined in [RFC6501] "Conference Information
+   Data Model for Centralized Conferencing (XCON)".
+
+   Section 2 clarifies the conventions and terminology used in the
+   document.  Section 3 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 Section 4 together with
+   implementation details.  Section 5 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 Section 6.  A
+   survey of the methods that can be used to locate a conference server
+   is provided in Section 7, and Section 8 discusses potential
+   approaches to notifications management.  CCMP transport over HTTP is
+   highlighted in Section 9.  Security considerations are presented in
+   Section 10.  Finally, Section 11 provides the XML schema.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 4]
+
+RFC 6503                          CCMP                        March 2012
+
+
+2.  Conventions and Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   In addition to the terms defined in "A Framework for Centralized
+   Conferencing" [RFC5239], this document uses the following terms and
+   acronyms:
+
+   XCON-aware client:   An XCON conferencing system client that is able
+      to issue CCMP requests.
+
+   First-Party Request:   A request issued by the client to manipulate
+      its own conferencing data.
+
+   Third-Party Request:   A request issued by a client to manipulate the
+      conference data of another client.
+
+3.  XCON Conference Control System Architecture
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 5]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   ........................................................
+   .  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.
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 6]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   This section provides details of the identifiers REQUIRED to address
+   and manage the clients associated with a conferencing system using
+   CCMP.
+
+3.1.  Conference Objects
+
+   Conference objects feature a simple dynamic inheritance-and-override
+   mechanism.  Conference objects are linked into a tree known as a
+   "cloning tree" (see Section 7.1 of [RFC5239]).  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 [RFC6501].  The root element of such documents, called
+   <conference-info>, 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.
+
+3.2.  Conference Users
+
+   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
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 7]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   common data model.  Each CCMP request, with an exception pointed out
+   in Section 5.3.6 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 <confUserID> 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 <conference-info> element as specified
+   in the XCON data model are used to describe the users related to a
+   conference including the <users> element, as well as each <user>
+   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 <allowed-users-list> in <users>: each <target> 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.
+
+4.  Protocol Overview
+
+   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 [RFC6501].
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 8]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Section 4.1 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 Section 4.1,
+   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 Section 4.2.
+
+   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 Section 4.3.
+
+   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
+   Section 4.4.
+
+4.1.  Protocol Operations
+
+   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.
+
+
+
+
+
+Barnes, et al.               Standards Track                    [Page 9]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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., <entry> elements in <sidebars-by-value>)
+      and external to it (i.e., whose XCON-URIs are included in the
+      <entry> elements of <sidebars-by-ref>),
+
+   o  <user> 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.
+
+4.2.  Data Management
+
+   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 <version> 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
+   <response-code> 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 <response-
+   code> 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
+
+
+
+Barnes, et al.               Standards Track                   [Page 10]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   [RFC6502] 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 <subject> of the
+   conference, but then detect an invalid URI in one of the <service-
+   uris> and abort the remaining updates.
+
+4.3.  Data Model Compliance
+
+   The XCON data model [RFC6501] 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., <userinfo
+   entity="xcon-userid:AUTO_GENERATE_1@example.com">).
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 11]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 <response-code> 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 <response-code> 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.
+
+4.4.  Implementation Approach
+
+   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 Appendix 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
+
+
+
+Barnes, et al.               Standards Track                   [Page 12]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   specific time period.  In this case, a server SHOULD return a
+   <response-code> 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 Section 4.2, 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 [RFC3023], 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.  Section 9 provides the complete requirements for an HTTP
+   implementation to support CCMP.
+
+5.  CCMP Messages
+
+   CCMP messages are either requests or responses.  The general CCMP
+   request message is defined in Section 5.1.  The general CCMP response
+   message is defined in Section 5.2.  The details of the specific
+   message type that is carried in the CCMP request and response
+   messages are described in Section 5.3.  CCMP response codes are
+   listed in Section 5.4.
+
+5.1.  CCMP Request Message Type
+
+   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.
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 13]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 <confUserID> 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 Section 5.3.6.
+
+   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 <operation> 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 <conference-password>
+      element in [RFC6501]).  A CCMP <response-code> 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 Section 5.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 14]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- Definition of CCMP Request -->
+
+   <xs:element name="ccmpRequest" type="ccmp-request-type" />
+
+   <!-- Definition of ccmp-request-type-->
+
+   <xs:complexType name="ccmp-request-type">
+       <xs:sequence>
+           <xs:element name="ccmpRequest"
+                       type="ccmp-request-message-type" />
+       </xs:sequence>
+   </xs:complexType>
+
+    <!--  Definition of ccmp-request-message-type -->
+
+    <xs:complexType abstract="true"
+                    name="ccmp-request-message-type">
+        <xs:sequence>
+            <xs:element name="subject" type="subject-type"
+                        minOccurs="0" maxOccurs="1" />
+            <xs:element name="confUserID" type="xs:string"
+                        minOccurs="0" maxOccurs="1" />
+            <xs:element name="confObjID" type="xs:string"
+                        minOccurs="0" maxOccurs="1" />
+            <xs:element name="operation" type="operationType"
+                        minOccurs="0" maxOccurs="1" />
+            <xs:element name="conference-password" type="xs:string"
+                        minOccurs="0" maxOccurs="1" />
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+               Figure 2: Structure of CCMP Request Messages
+
+5.2.  CCMP Response Message Type
+
+   A CCMP response message is 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 15]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 Section 5.4.
+
+   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 <conference-info>
+      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 <response-code> of
+      "400".  The details for the specialized messages and associated
+      parameters are provided in Section 5.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 16]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- Definition of CCMP Response -->
+
+   <xs:element name="ccmpResponse" type="ccmp-response-type" />
+
+   <!-- Definition of ccmp-response-type -->
+
+   <xs:complexType name="ccmp-response-type">
+       <xs:sequence>
+           <xs:element name="ccmpResponse"
+                       type="ccmp-response-message-type" />
+       </xs:sequence>
+   </xs:complexType>
+
+   <!--  Definition of ccmp-response-message-type -->
+
+   <xs:complexType abstract="true"
+                   name="ccmp-response-message-type">
+       <xs:sequence>
+           <xs:element name="confUserID" type="xs:string"
+                       minOccurs="1" maxOccurs="1" />
+           <xs:element name="confObjID" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="operation" minOccurs="0"
+                       maxOccurs="1" />
+           <xs:element name="response-code"
+                       type="response-codeType"
+                       minOccurs="1" maxOccurs="1" />
+           <xs:element name="response-string" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="version" type="xs:positiveInteger"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+               Figure 3: Structure of CCMP Response Message
+
+5.3.  Detailed Messages
+
+   Based on the request and response message structures described in
+   Sections 5.1 and 5.2, the following summarizes the specialized CCMP
+   request and response types described in this document:
+
+   1.   blueprintsRequest/blueprintsResponse
+
+   2.   confsRequest/confsResponse
+
+
+
+Barnes, et al.               Standards Track                   [Page 17]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 Section 4.1 to manipulate the conference data.  These
+   request/response pairs are included in an IANA registry as defined in
+   Section 12.5.  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 <operation> 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 <operation> 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 18]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   +---------------+------------+------------+------------+------------+
+   | Operation     |  Retrieve  |   Create   |   Update   |   Delete   |
+   | ------------- |            |            |            |            |
+   | Request Type  |            |            |            |            |
+   +---------------+------------+------------+------------+------------+
+   | blueprints    |  Get list  |     N/A    |     N/A    |     N/A    |
+   | Request       |     of     |            |            |            |
+   |               | blueprints |            |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | blueprint     |     Get    |    N/A*    |    N/A*    |    N/A*    |
+   | Request       |  blueprint |            |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | confsRequest  |  Get list  |     N/A    |     N/A    |     N/A    |
+   |               |  of confs  |            |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | confRequest   |     Get    |   Create   |   Change   |   Delete   |
+   |               | conference | conference | conference | conference |
+   |               |   object   |   object   |   object   |   object   |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | usersRequest  |     Get    |   N/A(**)  |   Change   |   N/A(**)  |
+   |               |   <users>  |            |   <users>  |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | userRequest   |     Get    |    Add a   |   Change   |   Delete   |
+   |               |  specified |  <user> to |  specified |  specified |
+   |               |   <user>   |   a conf   |   <user>   |   <user>   |
+   |               |            |    (***)   |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | sidebarsByVal |     Get    |     N/A    |     N/A    |     N/A    |
+   | Request       | <sidebars- |            |            |            |
+   |               |   by-val>  |            |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | sidebarsByRef |     Get    |     N/A    |     N/A    |     N/A    |
+   | Request       | <sidebars- |            |            |            |
+   |               |   by-ref>  |            |            |            |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | sidebarByValR |     Get    |   Create   |   Change   |   Delete   |
+   | equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
+   |               |   by-val   |   by-val   |   by-val   |   by-val   |
+   | ------------- | ---------- | ---------- | ---------- | ---------- |
+   | sidebarByRefR |     Get    |   Create   |   Change   |   Delete   |
+   | equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
+   |               |   by-ref   |   by-ref   |   by-ref   |   by-ref   |
+   +---------------+------------+------------+------------+------------+
+
+            Table 1: Request Type Operation-Specific Processing
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 19]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   (**): These operations are not allowed for a usersRequest message,
+   since the <users> 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 <confUserID> parameter and/or if
+   the entity field of the <userInfo> 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 <response-code> of "400" per Section 5.4.
+
+5.3.1.  blueprintsRequest and blueprintsResponse
+
+   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 Section 5.3.3.
+
+   The <confUserID> 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 <confObjID> and <operation> 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 20]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- blueprintsRequest -->
+ <xs:complexType name="ccmp-blueprints-request-message-type">
+     <xs:complexContent>
+         <xs:extension base="tns:ccmp-request-message-type">
+             <xs:sequence>
+                 <xs:element ref="blueprintsRequest" />
+             </xs:sequence>
+         </xs:extension>
+     </xs:complexContent>
+ </xs:complexType>
+
+ <!-- blueprintsRequestType -->
+
+ <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
+
+ <xs:complexType name="blueprintsRequestType">
+     <xs:sequence>
+         <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+ <!-- blueprintsResponse -->
+
+ <xs:complexType name="ccmp-blueprints-response-message-type">
+     <xs:complexContent>
+         <xs:extension base="tns:ccmp-response-message-type">
+             <xs:sequence>
+                 <xs:element ref="blueprintsResponse" />
+             </xs:sequence>
+         </xs:extension>
+     </xs:complexContent>
+ </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 21]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- blueprintsResponseType -->
+
+ <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
+
+ <xs:complexType name="blueprintsResponseType">
+     <xs:sequence>
+         <xs:element name="blueprintsInfo"
+                     type="info:uris-type" minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+             Figure 4: Structure of the blueprintsRequest and
+                        blueprintsResponse Messages
+
+5.3.2.  confsRequest and confsResponse
+
+   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 <confUserID>
+   parameter MUST be included in every confsRequest/Response message and
+   reflect the XCON-USERID of the conferencing client issuing the
+   request.  The <confObjID> 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 <operation> 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 22]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- confsRequest -->
+
+ <xs:complexType name="ccmp-confs-request-message-type">
+     <xs:complexContent>
+         <xs:extension base="tns:ccmp-request-message-type">
+             <xs:sequence>
+                 <xs:element ref="confsRequest" />
+             </xs:sequence>
+         </xs:extension>
+     </xs:complexContent>
+ </xs:complexType>
+
+ <!-- confsRequestType -->
+
+ <xs:element name="confsRequest" type="confsRequestType" />
+
+ <xs:complexType name="confsRequestType">
+     <xs:sequence>
+         <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+ <!-- confsResponse -->
+
+ <xs:complexType name="ccmp-confs-response-message-type">
+     <xs:complexContent>
+         <xs:extension base="tns:ccmp-response-message-type">
+             <xs:sequence>
+                 <xs:element ref="confsResponse" />
+             </xs:sequence>
+         </xs:extension>
+     </xs:complexContent>
+ </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 23]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- confsResponseType -->
+
+ <xs:element name="confsResponse" type="confsResponseType"/>
+
+ <xs:complexType name="confsResponseType">
+     <xs:sequence>
+         <xs:element name="confsInfo" type="info:uris-type"
+                     minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+    Figure 5: Structure of the confsRequest and confsResponse Messages
+
+5.3.3.  blueprintRequest and blueprintResponse
+
+   Through a blueprintRequest, a client can manipulate the conference
+   object associated with a specified blueprint.  Along with the
+   <confUserID> parameter, the request MUST include the <confObjID> and
+   the <operation> parameters.  Again, the <confUserID> parameter MUST
+   be included in every blueprintRequest/Response message and reflect
+   the XCON-USERID of the conferencing client issuing the request.  The
+   <confObjID> 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 <operation>
+   parameter with a value other than "retrieve".  An <operation>
+   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 <confObjID> 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 <response-code> of "404".  This also holds for
+   the case in which the mentioned <confObjID> 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.
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 24]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   For a <response-code> of "200" in a "retrieve" operation, the
+   <blueprintInfo> parameter MUST be included in the blueprintResponse
+   message.  The <blueprintInfo> parameter contains the conference
+   document associated with the blueprint as identified by the
+   <confObjID> parameter specified in the blueprintRequest.
+
+   <!--  blueprintRequest -->
+
+   <xs:complexType name="ccmp-blueprint-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- blueprintRequestType -->
+
+   <xs:element name="blueprintRequest" type="blueprintRequestType" />
+
+   <xs:complexType name="blueprintRequestType">
+       <xs:sequence>
+           <xs:element name="blueprintInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- blueprintResponse -->
+
+   <xs:complexType name="ccmp-blueprint-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 25]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- blueprintResponseType -->
+
+   <xs:element name="blueprintResponse" type="blueprintResponseType"/>
+
+   <xs:complexType name="blueprintResponseType">
+       <xs:sequence>
+           <xs:element name="blueprintInfo" type="info:conference-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded">
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+              Figure 6: Structure of the blueprintRequest and
+                        blueprintResponse Messages
+
+5.3.4.  confRequest and confResponse
+
+   With a confRequest message, CCMP clients can manipulate conference
+   objects associated with either active or registered conferences.  The
+   <confUserID> 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 <operation> parameter.  ConfResponse messages MUST return
+   to the requestor a <response-code> and MAY contain a <response-
+   string> explaining it.  Depending upon the type of operation, a
+   <confObjID> and <confInfo> parameter MAY be included in the
+   confRequest and response.  For each type of operation, the text below
+   describes whether the <confObjID> and <confInfo> 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 <confObjID> parameter MUST
+       contain the XCON-URI of the blueprint or of the conference to be
+       cloned, while the <confInfo> parameter MUST NOT be included in
+       the confRequest.  Note that cloning of an active conference is
+       only done in the case of a sidebar operation per the XCON
+       framework and as described in Section 5.3.8.
+
+   2.  Creation through implicit cloning (also known as "direct
+       creation"): the <confObjID> parameter MUST NOT be included in the
+       request and the CCMP client can describe the desired conference
+       to be created using the <confInfo> parameter.  If no <confInfo>
+       parameter is provided in the request, the new conference will be
+       created as a clone of the system default blueprint.
+
+
+
+Barnes, et al.               Standards Track                   [Page 26]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   In both creation cases, the confResponse, for a successful completion
+   of a "create" operation, contains a <response-code> of "200" and MUST
+   contain the XCON-URI of the newly created conference in the
+   <confObjID> parameter, in order to allow the conferencing client to
+   manipulate that conference through following CCMP requests.  In
+   addition, the <confInfo> parameter containing the conference document
+   created MAY be included, at the discretion of the conferencing system
+   implementation, along with the REQUIRED <version> parameter
+   initialized at "1", since, at creation time, the conference object is
+   at its first version.
+
+   In the case of a confRequest with an <operation> parameter of
+   "retrieve", the <confObjID> parameter representing the XCON-URI of
+   the target conference MUST be included and the <confInfo> parameter
+   MUST NOT be included in the request.  The conference server MUST
+   ignore any <confInfo> parameter that is received in a confRequest
+   "retrieve" operation.  If the confResponse for the retrieve operation
+   contains a <response-code> of "200", the <confInfo> parameter MUST be
+   included in the response.  The <confInfo> parameter MUST contain the
+   entire conference document describing the target conference object in
+   its current state.  The current state of the retrieved conference
+   object MUST also be reported in the proper "version" response
+   parameter.
+
+   In case of a confRequest with an <operation> parameter of "update",
+   the <confInfo> and <confObjID> parameters MUST be included in the
+   request.  The <confInfo> represents an object of type
+   "conference-type" containing all the changes to be applied to the
+   conference whose identifier has the same value as the <confObjID>
+   parameter.  Note that, in such a case, though the <confInfo>
+   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 <confInfo> parameter will be of the form:
+
+   <confInfo entity="xcon:8977777@example.com">
+     <conference-description>
+       <display-text> *** NEW CONFERENCE TITLE *** </display-text>
+     </conference-description>
+   </confInfo>
+
+           Figure 7: Updating a Conference Object: Modifying the
+                           Title of a Conference
+
+   Similarly, to remove the title of an existing conference, a
+   confRequest/update carrying the following <confInfo> parameter would
+   do the job.
+
+
+
+Barnes, et al.               Standards Track                   [Page 27]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <confInfo entity="xcon:8977777@example.com">
+     <conference-description>
+       <display-text/>
+     </conference-description>
+   </confInfo>
+
+                  Figure 8: Updating a Conference Object:
+                    Removing the Title of a Conference
+
+   In the case of a confResponse/update with a <response-code> of "200",
+   no additional information is REQUIRED in the response message, which
+   means the return of a <confInfo> 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 <response-
+   code> of "200" indicates that the conference object has been changed
+   according to the request by the conference server.  The <version>
+   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 <response-code> of
+   "409" indicates that the changes reflected in the <confInfo>
+   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 <response-code> of "409", the
+   <version> 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 <operation> parameter of
+   "delete", the <confObjID> parameter representing the XCON-URI of the
+   target conference MUST be included while the <confInfo> parameter
+   MUST NOT be included in the request.  The conference server MUST
+   ignore any <confInfo> parameter that is received within such a
+   request.  The confResponse MUST contain the same value for the
+   <confObjID> parameter that was included in the confRequest.  If the
+   confResponse/delete operation contains a <response-code> of "200",
+   the conference indicated in the <confObjID> parameter has been
+   successfully deleted.  A confResponse/delete with a <response-code>
+   of "200" MUST NOT contain the <confInfo> parameter.  The <version>
+   parameter SHOULD NOT be returned in any confResponse/delete.  If the
+   conference server cannot delete the conference referenced by the
+   <confObjID> parameter received in the confRequest because it is the
+   parent of another conference object that is in use, the conference
+   server MUST return a <response-code> of "425".
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 28]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   A confRequest with an <operation> parameter of "retrieve", "update",
+   or "delete" carrying a <confObjID> 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 <response-code> of "404".  This also holds for the case
+   in which the mentioned <confObjID> 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.
+
+   <!-- confRequest -->
+
+   <xs:complexType name="ccmp-conf-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="confRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- confRequestType -->
+
+   <xs:element name="confRequest" type="confRequestType" />
+
+   <xs:complexType name="confRequestType">
+       <xs:sequence>
+           <xs:element name="confInfo" type="info:conference-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 29]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- confResponse -->
+
+   <xs:complexType name="ccmp-conf-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="confResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- confResponseType -->
+
+   <xs:element name="confResponse" type="confResponseType" />
+
+   <xs:complexType name="confResponseType">
+       <xs:sequence>
+           <xs:element name="confInfo" type="info:conference-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+     Figure 9: Structure of the confRequest and confResponse Messages
+
+5.3.5.  usersRequest and usersResponse
+
+   The usersRequest message allows a client to manipulate the <users>
+   element of the conference object represented by the <confObjID>
+   parameter.  The <users> element contains the list of <user> elements
+   associated with conference participants, the list of the users to
+   which access to the conference is allowed/denied, conference
+   participation policies, etc.  The <confObjID> parameter MUST be
+   included in a usersRequest message.
+
+   A <usersInfo> parameter MAY be included in a usersRequest message
+   depending upon the operation.  If the <usersInfo> parameter is
+   included in the usersRequest message, the parameter MUST be compliant
+   with the <users> 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
+       <usersInfo> parameter, while the successful response MUST contain
+       the desired <users> element in the <usersInfo> parameter.  The
+
+
+
+Barnes, et al.               Standards Track                   [Page 30]
+
+RFC 6503                          CCMP                        March 2012
+
+
+       conference server MUST ignore a <usersInfo> parameter if it is
+       received in a request with an <operation> parameter of
+       "retrieve".
+
+   2.  "update": In this case, the <usersInfo> parameter MUST contain
+       the modifications to be applied to the <users> element indicated.
+       If the <response-code> is "200", then the <usersInfo> parameter
+       SHOULD NOT be returned.  Any <usersInfo> parameter that is
+       returned SHOULD be ignored.  A <response-code> of "426" indicates
+       that the conferencing client is not allowed to make the changes
+       reflected in the <usersInfo> 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 <response-code> of "403" MUST be included in the
+   usersResponse message.
+
+   <!-- usersRequest -->
+
+   <xs:complexType name="ccmp-users-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="usersRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- usersRequestType -->
+
+   <xs:element name="usersRequest" type="usersRequestType" />
+
+   <xs:complexType name="usersRequestType">
+       <xs:sequence>
+           <xs:element name="usersInfo"
+                       type="info:users-type" minOccurs="0" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 31]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- usersResponse -->
+
+   <xs:complexType name="ccmp-users-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="usersResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- usersResponseType -->
+
+   <xs:element name="usersResponse" type="usersResponseType" />
+
+   <xs:complexType name="usersResponseType">
+       <xs:sequence>
+           <xs:element name="usersInfo" type="info:users-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+    Figure 10: Structure of the usersRequest and usersResponse Messages
+
+5.3.6.  userRequest and userResponse
+
+   A userRequest message is used to manipulate <user> elements inside a
+   conference document associated with a conference identified by the
+   <confObjID> 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 <confObjID> and the
+   <operation> parameters, and it MAY include a <userInfo> parameter
+   containing the detailed user's information depending upon the
+   operation and whether the <userInfo> 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.
+
+
+
+Barnes, et al.               Standards Track                   [Page 32]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Conference users can be created in a number of different ways.  In
+   each of these cases, the <operation> parameter MUST be set to
+   "create" in the userRequest message.  Each of the userResponse
+   messages for these cases MUST include the <confObjID>, <confUserID>,
+   <operation>, and <response-code> parameters.  In the case of a
+   <response-code> of "200", the userResponse message MAY include the
+   <userInfo> 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 <userInfo> parameter MAY be included
+      in the userRequest.  The <userInfo> parameter MUST contain a
+      <user> 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 <response-code> of "200".
+
+   o  A conferencing client acts on behalf of another user whose XCON-
+      USERID is known: In this case, the <userInfo> parameter MUST be
+      included in the userRequest.  The <userInfo> parameter MUST
+      contain a <user> 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 <response-
+      code> 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
+      <confUserID> parameter of the response.  This is the only case in
+      which a CCMP request can be valid though carrying a void
+      <confUserID> parameter.  A <userInfo> 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 <userInfo> 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
+      Section 4.3, 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:
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 33]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Request fields:
+
+   confUserID=null;
+   confObjID=confXYZ;
+   operation=create;
+   userInfo=
+
+   <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
+           <endpoint entity="sip:GHIL345@example.com">
+           ...
+
+
+   Response fields (in case of success):
+
+   confUserID=user345;
+   confObjID=confXYZ;
+   operation=create;
+   response-code=200;
+   userInfo=null; //or the entire userInfo object
+
+                Figure 11: userRequest and userResponse in the
+                          Absence of an xcon-userid
+
+   o  A conferencing client is unaware of the XCON-USERID of a third
+      user: In this case, the XCON-USERID in the request, <confUserID>,
+      is the sender's and the 'entity' attribute of the attached
+      <userInfo> 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 <userInfo> parameter, if
+      the <response-code> 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 <userInfo> 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 <operation> parameter of
+   "retrieve", the <confObjID> parameter representing the XCON-URI of
+   the target conference MUST be included.  The <confUserID>, containing
+   the CCMP client's XCON-USERID, MUST also be included in the
+
+
+
+Barnes, et al.               Standards Track                   [Page 34]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   userRequest message.  If the client wants to retrieve information
+   about her profile in the specified conference, no <userInfo>
+   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 <userInfo>
+   parameter whose 'entity' attribute conveys the desired user's XCON-
+   USERID.  If the userResponse for the retrieve operation contains a
+   <response-code> of "200", the <userInfo> parameter MUST be included
+   in the response.
+
+   In case of a userRequest with an <operation> parameter of "update",
+   the <confObjID>, <confUserID>, and <userInfo> parameters MUST be
+   included in the request.  The <userInfo> parameter is of type "user-
+   type" and contains all the changes to be applied to a specific <user>
+   element in the conference object identified by the <confObjID>
+   parameter in the userRequest message.  The user to be modified is
+   identified through the 'entity' attribute of the <userInfo> parameter
+   included in the request.  In the case of a userResponse with a
+   <response-code> of "200", no additional information is required in
+   the userResponse message.  A <response-code> of "200" indicates that
+   the referenced <user> element has been updated by the conference
+   server.  A <response-code> of "426" indicates that the conferencing
+   client is not allowed to make the changes reflected in the <userInfo>
+   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 <operation> parameter of
+   "delete", the <confObjID> representing the XCON-URI of the target
+   conference MUST be included.  The <confUserID> 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
+   <userInfo> 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
+   <userInfo> parameter whose 'entity' attribute conveys the XCON-USERID
+   of that participant.  The userResponse MUST contain the same value
+   for the <confObjID> parameter that was included in the <confObjID>
+   parameter in the userRequest.  The userResponse MUST contain a
+   <response-code> of "200" if the target <user> element has been
+   successfully deleted.  If the userResponse for the delete operation
+   contains a <response-code> of "200", the userResponse MUST NOT
+   contain the <userInfo> parameter.
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 35]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- userRequest -->
+
+   <xs:complexType name="ccmp-user-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="userRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- userRequestType -->
+
+   <xs:element name="userRequest" type="userRequestType" />
+
+   <xs:complexType name="userRequestType">
+       <xs:sequence>
+           <xs:element name="userInfo"
+                       type="info:user-type" minOccurs="0" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- userResponse -->
+
+   <xs:complexType name="ccmp-user-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="userResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 36]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- userResponseType -->
+
+   <xs:element name="userResponse" type="userResponseType" />
+
+   <xs:complexType name="userResponseType">
+       <xs:sequence>
+           <xs:element name="userInfo" type="info:user-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+     Figure 12: Structure of the userRequest and userResponse Messages
+
+5.3.7.  sidebarsByValRequest and sidebarsByValResponse
+
+   A sidebarsByValRequest message is used to execute a retrieve-only
+   operation on the <sidebars-by-val> field of the conference object
+   represented by the <confObjID>.  The sidebarsByValRequest message is
+   of a retrieve-only type, so an <operation> 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 <response-code> of "200" MUST contain a <sidebarsByValInfo>
+   parameter containing the desired <sidebars-by-val> element.  A
+   sidebarsByValResponse message MUST return to the client a <version>
+   element related to the current version of the main conference object
+   (i.e., the one whose identifier is contained in the <confObjID> field
+   of the request) with which the sidebars in question are associated.
+   The <sidebarsByValInfo> 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
+   Section 5.3.8.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 37]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- sidebarsByValRequest -->
+
+ <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
+     <xs:complexContent>
+         <xs:extension base="tns:ccmp-request-message-type">
+             <xs:sequence>
+                 <xs:element ref="sidebarsByValRequest"/>
+             </xs:sequence>
+         </xs:extension>
+    </xs:complexContent>
+ </xs:complexType>
+
+ <!-- sidebarsByValRequestType -->
+
+ <xs:element name="sidebarsByValRequest"
+             type="sidebarsByValRequestType" />
+
+ <xs:complexType name="sidebarsByValRequestType">
+     <xs:sequence>
+         <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+   </xs:sequence>
+   <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+
+ <!-- sidebarsByValResponse -->
+
+ <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
+         <xs:complexContent>
+          <xs:extension base="tns:ccmp-response-message-type">
+                 <xs:sequence>
+            <xs:element ref="sidebarsByValResponse"/>
+           </xs:sequence>
+          </xs:extension>
+         </xs:complexContent>
+ </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 38]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ <!-- sidebarsByValResponseType -->
+
+ <xs:element name="sidebarsByValResponse"
+             type="sidebarsByValResponseType" />
+
+ <xs:complexType name="sidebarsByValResponseType">
+     <xs:sequence>
+         <xs:element name="sidebarsByValInfo"
+                     type="info:sidebars-by-val-type" minOccurs="0"/>
+         <xs:any namespace="##other" processContents="lax"
+                 minOccurs="0" maxOccurs="unbounded"/>
+    </xs:sequence>
+    <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+           Figure 13: Structure of the sidebarsByValRequest and
+                      sidebarsByValResponse Messages
+
+5.3.8.  sidebarByValRequest and sidebarByValResponse
+
+   A sidebarByValRequest message MUST contain the <operation> 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 <confObjID> parameter MUST
+   be included in the sidebyValRequest message.  In this case, the
+   <confObjID> 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 [RFC5239] 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 <confObjID> parameter in the sidebarbyValRequest/create message
+   introducing the new sidebar object as a new <entry> in the proper
+   section <sidebars-by-val>.  The newly created sidebar conference
+   object MAY be included in the sidebarByValResponse in the
+   <sidebarByValInfo> parameter, if the <response-code> is "200".  The
+   XCON-URI of the newly created sidebar MUST appear in the <confObjID>
+   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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 39]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   In the case of a sidebarByValRequest message with an <operation>
+   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 <confObjID>
+   parameter in the request.  This retrieve operation is handled by the
+   conference server in the same manner as in the case of an <operation>
+   parameter of "retrieve" included in a confRequest message, as
+   described in Section 5.3.4.
+
+   In the case of a sidebarByValRequest message with an <operation>
+   parameter of "update", the <sidebarByValInfo> MUST also be included
+   in the request.  The <confObjID> 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
+   <sidebarByValInfo> parameter is handled by the conference server in
+   the same manner as an update operation on the conference instance as
+   reflected by the <confInfo> parameter included in a confRequest
+   message as detailed in Section 5.3.4.  A sidebarByValResponse message
+   MUST return to the client a <version> element related to the current
+   version of the sidebar whose identifier is contained in the
+   <confObjID> field of the request.
+
+   If an <operation> parameter of "delete" is included in the
+   sidebarByVal request, the <sidebarByValInfo> parameter MUST NOT be
+   included in the request.  Any <sidebarByValInfo> 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
+   <confObjID> parameter in the request.  If the specific conferencing
+   user, as reflected by the <confUserID> parameter, in the request is
+   authorized to delete the conference, the conference server deletes
+   the conference object reflected by the <confObjID> 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 <operation> parameter of "retrieve",
+   "update", or "delete" carries a <confObjID> parameter which is not
+   associated with any existing sidebar-by-val, a confResponse message
+   containing a <response-code> of "404" will be generated on the
+   server's side.  This also holds for the case in which the mentioned
+   <confObjID> 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 40]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarByValRequest -->
+
+   <xs:complexType name="ccmp-sidebarByVal-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarByValRequest"/>
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- sidebarByValRequestType -->
+
+   <xs:element name="sidebarByValRequest"
+               type="sidebarByValRequestType" />
+
+   <xs:complexType name="sidebarByValRequestType">
+       <xs:sequence>
+           <xs:element name="sidebarByValInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+
+   <!-- sidebarByValResponse -->
+
+   <xs:complexType name="ccmp-sidebarByVal-response-message-type">
+    <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+            <xs:sequence>
+                   <xs:element ref="sidebarByValResponse"/>
+            </xs:sequence>
+     </xs:extension>
+    </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 41]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarByValResponseType -->
+
+   <xs:element name="sidebarByValResponse"
+               type="sidebarByValResponseType" />
+
+   <xs:complexType name="sidebarByValResponseType">
+     <xs:sequence>
+        <xs:element name="sidebarByValInfo"
+                    type="info:conference-type" minOccurs="0"/>
+        <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+            Figure 14: Structure of the sidebarByValRequest and
+                       sidebarByValResponse Messages
+
+5.3.9.  sidebarsByRefRequest and sidebarsByRefResponse
+
+   Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
+   invoked to retrieve the <sidebars-by-ref> element of the conference
+   object identified by the <confObjID> parameter.  The
+   sidebarsByRefRequest message is of a retrieve-only type, so an
+   <operation> parameter MUST NOT be included in a sidebarsByRefRequest
+   message.  In the case of a <response-code> of "200", the
+   <sidebarsByRefInfo> parameter, containing the <sidebars-by-ref>
+   element of the conference object, MUST be included in the response.
+   The <sidebars-by-ref> 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 Section 5.3.10.  A sidebarsByRefResponse
+   message MUST carry back to the client a <version> element related to
+   the current version of the main conference object (i.e., the one
+   whose identifier is contained in the <confObjId> field of the
+   request) with which the sidebars in question are associated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 42]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarsByRefRequest -->
+
+   <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarsByRefRequest"/>
+               </xs:sequence>
+           </xs:extension>
+      </xs:complexContent>
+   </xs:complexType>
+
+   <!-- sidebarsByRefRequestType -->
+
+   <xs:element name="sidebarsByRefRequest"
+               type="sidebarsByRefRequestType" />
+
+   <xs:complexType name="sidebarsByRefRequestType">
+       <xs:sequence>
+           <xs:element name="xpathFilter"
+                       type="xs:string" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- sidebarsByRefResponse -->
+
+   <xs:complexType name="ccmp-sidebarsByref-response-message-type">
+           <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                    <xs:sequence>
+                           <xs:element ref="sidebarsByRefResponse"/>
+                    </xs:sequence>
+            </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 43]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarsByRefResponseType -->
+
+   <xs:element name="sidebarsByRefResponse"
+               type="sidebarsByRefResponseType" />
+
+   <xs:complexType name="sidebarsByRefResponseType">
+       <xs:sequence>
+          <xs:element name="sidebarsByRefInfo"
+                      type="info:uris-type" minOccurs="0"/>
+          <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+             Figure 15: Structure of the sidebarsByRefRequest
+                    and sidebarsByRefResponse Messages
+
+5.3.10.  sidebarByRefRequest and sidebarByRefResponse
+
+   A sidebarByValResponse message MUST return to the client a <version>
+   element related to the current version of the sidebar whose
+   identifier is contained in the <confObjID> field of the request.
+
+   In the case of a create operation, the <confObjID> parameter MUST be
+   included in the sidebyRefRequest message.  In this case, the
+   <confObjID> parameter contains the XCON-URI of the main conference in
+   which the sidebar has to be created.  If no <sidebarByRefInfo>
+   parameter is included, following the XCON framework [RFC5239], 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 <sidebarByRefInfo> parameter provided by the
+   requestor.  If the creation of the sidebar is successful, the
+   conference server MUST update the <sidebars-by-ref> element in the
+   conference object from which the sidebar was created (i.e., as
+   identified by the <confObjID> 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
+   <sidebarByRefInfo> parameter with a <response-code> of "200".  The
+   URI for the conference object associated with the newly created
+   sidebar object MUST appear in the <confObjID> 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 44]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   In the case of a sidebarByRefRequest message with an <operation>
+   parameter of "retrieve", the URI for the conference object created
+   for the sidebar MUST be included in the <confObjID> parameter in the
+   request.  A retrieve operation on the <sidebarByRefInfo> 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
+   Section 5.3.4.
+
+   In the case of a sidebarByRefRequest message with an <operation>
+   parameter of "update", the URI for the conference object created for
+   the sidebar MUST be included in the <confObjID> parameter in the
+   request.  The <sidebarByRefInfo> MUST also be included in the request
+   in the case of an "update" operation.  An update operation on the
+   <sidebarByRefInfo> is handled by the conference server in the same
+   manner as an update operation on the <confInfo> included in a
+   confRequest message as detailed in Section 5.3.4.  A
+   sidebarByRefResponse message MUST carry back to the client a
+   <version> element related to the current version of the sidebar whose
+   identifier is contained in the <confObjID> field of the request.
+
+   If an <operation> parameter of "delete" is included in the
+   sidebarByRefRequest, the <sidebarByRefInfo> parameter MUST NOT be
+   included in the request.  Any <sidebarByRefInfo> 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 <confObjID>
+   parameter in the request.  If the specific conferencing user as
+   reflected by the <confUserID> parameter in the request is authorized
+   to delete the conference, the conference server SHOULD delete the
+   conference object reflected by the <confObjID> parameter and SHOULD
+   update the <sidebars-by-ref> 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 <operation> parameter of "retrieve",
+   "update", or "delete" carries a <confObjID> parameter that is not
+   associated with any existing sidebar-by-ref, a confResponse message
+   containing a <response-code> of "404" will be generated on the
+   server's side.  This also holds for the case in which the value of
+   the mentioned <confObjID> 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.
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 45]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarByRefRequest -->
+
+   <xs:complexType name="ccmp-sidebarByRef-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarByRefRequest"/>
+                </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- sidebarByRefRequestType -->
+
+   <xs:element name="sidebarByRefRequest"
+               type="sidebarByRefRequestType" />
+
+   <xs:complexType name="sidebarByRefRequestType">
+       <xs:sequence>
+           <xs:element name="sidebarByRefInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- sidebarByRefResponse -->
+
+   <xs:complexType name="ccmp-sidebarByRef-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarByRefResponse"/>
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 46]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- sidebarByRefResponseType -->
+
+   <xs:element name="sidebarByRefResponse"
+               type="sidebarByRefResponseType" />
+
+   <xs:complexType name="sidebarByRefResponseType">
+       <xs:sequence>
+           <xs:element name="sidebarByRefInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+              Figure 16: Structure of the sidebarByRefRequest
+                     and sidebarByRefResponse Messages
+
+5.3.11.  extendedRequest and extendedResponse
+
+   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 <extensionName> field.
+   Extension-specific information can be transported in the form of
+   schema-defined XML elements inside the <any> 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 Section 5.3.12).
+
+   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.
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 47]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- extendedRequest -->
+
+   <xs:complexType name="ccmp-extended-request-message-type">
+      <xs:complexContent>
+          <xs:extension base="tns:ccmp-request-message-type">
+             <xs:sequence>
+                            <xs:element ref="extendedRequest"/>
+             </xs:sequence>
+          </xs:extension>
+      </xs:complexContent>
+   </xs:complexType>
+
+   <!-- extendedRequestType -->
+
+   <xs:element name="extendedRequest" type="extendedRequestType"/>
+
+   <xs:complexType name="extendedRequestType">
+     <xs:sequence>
+           <xs:element name="extensionName"
+                       type="xs:string" minOccurs="1"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0"
+               maxOccurs="unbounded" />
+    </xs:sequence>
+   </xs:complexType>
+
+   <!-- extendedResponse -->
+
+   <xs:complexType name="ccmp-extended-response-message-type">
+      <xs:complexContent>
+          <xs:extension base="tns:ccmp-response-message-type">
+              <xs:sequence>
+                            <xs:element ref="extendedResponse"/>
+              </xs:sequence>
+          </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 48]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- extendedResponseType -->
+
+   <xs:element name="extendedResponse" type="extendedResponseType"/>
+
+   <xs:complexType name="extendedResponseType">
+           <xs:sequence>
+                   <xs:element name="extensionName"
+                               type="xs:string"
+                               minOccurs="1"/>
+                   <xs:any namespace="##other"
+                           processContents="lax"
+                           minOccurs="0" maxOccurs="unbounded" />
+           </xs:sequence>
+   </xs:complexType>
+
+              Figure 17: Structure of the extendedRequest and
+                         extendedResponse Messages
+
+5.3.12.  optionsRequest and optionsResponse
+
+   The optionsRequest message (Figure 18) 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 <options> field, a
+   list of the supported CCMP message pairs as defined in this
+   specification.  These messages are in the form of a list: <standard-
+   message-list> including each of the supported messages as reflected
+   by <standard-message> elements.  The optionsResponse message also
+   allows for an <extended-message-list>, which is a list of additional
+   message types in the form of <extended-message-list> elements that
+   are currently undefined, to allow for future extensibility.  The
+   following information is provided for both types of messages:
+
+   o  <name> (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
+      <extension-name> inserted in the corresponding extendedRequest/
+      extendedResponse message pair.
+
+   o  <operations> (OPTIONAL): this field is a list of <operation>
+      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
+
+
+
+Barnes, et al.               Standards Track                   [Page 49]
+
+RFC 6503                          CCMP                        March 2012
+
+
+      handle the entire set of CRUD operations or, in case of standard
+      messages, all the operations envisioned for that message in this
+      document.
+
+   o  <schema-ref> (OPTIONAL): since all CCMP messages can potentially
+      contain XML elements not envisioned in the CCMP schema (due to the
+      presence of <any> 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  <description> (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 <standard-message-list> containing
+   at least one <operation> 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.
+
+   <!-- optionsRequest -->
+
+   <xs:complexType name="ccmp-options-request-message-type">
+           <xs:complexContent>
+                   <xs:extension base="tns:ccmp-request-message-type"/>
+           </xs:complexContent>
+   </xs:complexType>
+
+   <!-- optionsResponse -->
+
+   <xs:complexType name="ccmp-options-response-message-type">
+      <xs:complexContent>
+         <xs:extension base="tns:ccmp-response-message-type">
+           <xs:sequence>
+             <xs:element ref="optionsResponse"/>
+           </xs:sequence>
+         </xs:extension>
+     </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 50]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- optionsResponseType -->
+
+   <xs:element name="optionsResponse"
+                  type="optionsResponseType" />
+
+   <xs:complexType name="optionsResponseType">
+     <xs:sequence>
+      <xs:element name="options"
+               type="options-type" minOccurs="0"/>
+      <xs:any namespace="##other" processContents="lax"
+                minOccurs="0" maxOccurs="unbounded"/>
+    </xs:sequence>
+    <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- options-type -->
+
+   <xs:complexType name="options-type">
+      <xs:sequence>
+           <xs:element name="standard-message-list"
+                   type="standard-message-list-type"
+                   minOccurs="1"/>
+       <xs:element name="extended-message-list"
+                   type="extended-message-list-type"
+                   minOccurs="0"/>
+       <xs:any namespace="##other" processContents="lax"
+               minOccurs="0" maxOccurs="unbounded"/>
+      </xs:sequence>
+      <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- standard-message-list-type -->
+
+   <xs:complexType name="standard-message-list-type">
+     <xs:sequence>
+           <xs:element name="standard-message"
+                       type="standard-message-type"
+                       minOccurs="1" maxOccurs="10"/>
+       <xs:any namespace="##other" processContents="lax"
+               minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 51]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- standard-message-type -->
+
+   <xs:complexType name="standard-message-type">
+      <xs:sequence>
+           <xs:element name="name"
+                       type="standard-message-name-type"
+                       minOccurs="1"/>
+           <xs:element name="operations"
+                       type="operations-type"
+                       minOccurs="0"/>
+           <xs:element name="schema-def"
+                       type="xs:string" minOccurs="0"/>
+           <xs:element name="description"
+                       type="xs:string" minOccurs="0"/>
+       <xs:any namespace="##other" processContents="lax"
+               minOccurs="0" maxOccurs="unbounded"/>
+      </xs:sequence>
+      <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- standard-message-name-type -->
+
+   <xs:simpleType name="standard-message-name-type">
+      <xs:restriction base="xs:token">
+       <xs:enumeration value="confsRequest"/>
+       <xs:enumeration value="confRequest"/>
+       <xs:enumeration value="blueprintsRequest"/>
+       <xs:enumeration value="blueprintRequest"/>
+       <xs:enumeration value="usersRequest"/>
+       <xs:enumeration value="userRequest"/>
+       <xs:enumeration value="sidebarsByValRequest"/>
+       <xs:enumeration value="sidebarByValRequest"/>
+       <xs:enumeration value="sidebarsByRefRequest"/>
+       <xs:enumeration value="sidebarByRefRequest"/>
+      </xs:restriction>
+   </xs:simpleType>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 52]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- operations-type -->
+
+   <xs:complexType name="operations-type">
+     <xs:sequence>
+        <xs:element name="operation" type="operationType"
+                    minOccurs="1" maxOccurs="4"/>
+     </xs:sequence>
+     <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+              Figure 18: Structure of the optionsRequest and
+                         optionsResponse Messages
+
+5.4.  CCMP Response Codes
+
+   All CCMP response messages MUST include a <response-code>.  This
+   document defines an IANA registry for the CCMP response codes, as
+   described in Section 12.5.2.  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 <confObjID> 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
+
+
+
+Barnes, et al.               Standards Track                   [Page 53]
+
+RFC 6503                          CCMP                        March 2012
+
+
+      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 <userInfo> 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 <confUserID> 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.
+
+
+
+Barnes, et al.               Standards Track                   [Page 54]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 <response-code> 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
+   Section 5.3.  The following table summarizes these response codes and
+   the specialized message and operation to which they are applicable:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 55]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   +----------+-------------+--------------+-------------+-------------+
+   | 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
+   <confUserID> (contained in the 'entity' attribute of the <userInfo>
+   parameter) of the user to be added is unknown.  In the case above, if
+   instead it is the <confUserID> parameter of the sender of the request
+   that is invalid, a <response-code> of "421" is returned to the
+   client.
+
+
+
+Barnes, et al.               Standards Track                   [Page 56]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   (**) "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 <response-code> 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 <response-code> 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 <response-code> 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 <response-code> SHOULD be treated by the
+   client in the same manner as a <response-code> of "500", the handling
+   of which is specific to the conferencing client implementation.
+
+6.  A Complete Example of CCMP in Action
+
+   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
+   <confUserID> parameter in all requests.  The sequence of operations
+   is as follows:
+
+   1.  Alice retrieves the list of available blueprints from the server
+       (Section 6.1);
+
+   2.  Alice asks for detailed information about a specific blueprint
+       (Section 6.2);
+
+   3.  Alice decides to create a new conference by cloning the retrieved
+       blueprint (Section 6.3);
+
+   4.  Alice modifies information (e.g., XCON-URI, name, and
+       description) associated with the newly created blueprint
+       (Section 6.4);
+
+
+
+Barnes, et al.               Standards Track                   [Page 57]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   5.  Alice specifies a list of users to be contacted when the
+       conference is activated (Section 6.5);
+
+   6.  Alice joins the conference (Section 6.6);
+
+   7.  Alice lets a new user, Ciccio, (whose XCON-USERID is
+       "xcon-userid:Ciccio@example.com") join the conference
+       (Section 6.7).
+
+   8.  Alice asks for the CCMP server capabilities (Section 6.8);
+
+   9.  Alice exploits an extension of the CCMP server (Section 6.9).
+
+   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.
+
+6.1.  Alice Retrieves the Available Blueprints
+
+   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 <blueprintsInfo>
+   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)                                 |
+         |------------------------------------------------------>|
+         |                                                       |
+         |                     CCMP blueprintsResponse message   |
+         |                      - confUserID: Alice              |
+         |                      - confObjID: (null)              |
+         |                      - response-code: 200             |
+         |                      - blueprintsInfo: bp123,bp124,.. |
+         |<------------------------------------------------------|
+         |                                                       |
+         .                                                       .
+         .                                                       .
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 58]
+
+RFC 6503                          CCMP                        March 2012
+
+
+  1. blueprintsRequest message:
+
+  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+  <ccmp:ccmpRequest
+        xmlns:info="urn:ietf:params:xml:ns:conference-info"
+        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+      <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xsi:type="ccmp:ccmp-blueprints-request-message-type">
+          <confUserID>xcon-userid:alice@example.com</confUserID>
+          <ccmp:blueprintsRequest/>
+      </ccmpRequest>
+  </ccmp:ccmpRequest>
+
+  2. blueprintsResponse message from the server:
+
+  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+  <ccmp:ccmpResponse
+   xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+   xmlns:info="urn:ietf:params:xml:ns:conference-info"
+   xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+  <ccmpResponse
+      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:type="ccmp:ccmp-blueprints-response-message-type">
+     <confUserID>xcon-userid:alice@example.com</confUserID>
+     <response-code>200</response-code>
+       <ccmp:blueprintsResponse>
+        <blueprintsInfo>
+         <info:entry>
+          <info:uri>xcon:AudioRoom@example.com</info:uri>
+          <info:display-text>AudioRoom</info:display-text>
+          <info:purpose>Simple Room:
+             conference room with public access,
+             where only audio is available, more users
+             can talk at the same time
+             and the requests for the AudioFloor
+             are automatically accepted.
+          </info:purpose>
+         </info:entry>
+         <info:entry>
+          <info:uri>xcon:VideoRoom@example.com</info:uri>
+          <info:display-text>VideoRoom</info:display-text>
+          <info:purpose>Video Room:
+              conference room with public access,
+              where both audio and video are available,
+              8 users can talk and be seen at the same time,
+              and the floor requests are automatically accepted.
+          </info:purpose>
+
+
+
+Barnes, et al.               Standards Track                   [Page 59]
+
+RFC 6503                          CCMP                        March 2012
+
+
+         </info:entry>
+         <info:entry>
+          <info:uri>xcon:AudioConference1@example.com</info:uri>
+          <info:display-text>AudioConference1</info:display-text>
+          <info:purpose>Public Audio Conference:
+               conference with public access,
+               where only audio is available,
+               only one user can talk at the same time,
+               and the requests for the AudioFloor MUST
+               be accepted by a Chair.
+          </info:purpose>
+         </info:entry>
+         <info:entry>
+          <info:uri>xcon:VideoConference1@example.com</info:uri>
+          <info:display-text>VideoConference1</info:display-text>
+            <info:purpose>Public Video Conference: conference
+                where both audio and video are available,
+                only one user can talk.
+            </info:purpose>
+          </info:entry>
+          <info:entry>
+           <info:uri>xcon:AudioConference2@example.com</info:uri>
+           <info:display-text>AudioConference2</info:display-text>
+           <info:purpose>Basic Audio Conference:
+                conference with private access,
+                where only audio is available,
+                only one user can talk at the same time,
+                and the requests for the AudioFloor MUST
+                be accepted by a Chair.
+           </info:purpose>
+          </info:entry>
+       </blueprintsInfo>
+     </ccmp:blueprintsResponse>
+    </ccmpResponse>
+  </ccmp:ccmpResponse>
+
+               Figure 19: Getting Blueprints from the Server
+
+6.2.  Alice Gets Detailed Information about a Specific Blueprint
+
+   This 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 <blueprintInfo> parameter, a document compliant with
+   the standard XCON data model.
+
+
+
+Barnes, et al.               Standards Track                   [Page 60]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Alice retrieves detailed information about a specified blueprint:
+
+   CCMP Client                                             CCMP Server
+        |                                                       |
+        | CCMP blueprintRequest message                         |
+        |   - confUserID: Alice                                 |
+        |   - confObjID: bp123                                  |
+        |   - operation: retrieve                               |
+        |   - blueprintInfo: (null)                             |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                        CCMP blueprintResponse message |
+        |                          - confUserID: Alice          |
+        |                          - confObjID: bp123           |
+        |                          - operation: retrieve        |
+        |                          - response-code: 200         |
+        |                          - blueprintInfo: bp123Info   |
+        |<------------------------------------------------------|
+        |                                                       |
+        .                                                       .
+        .                                                       .
+
+ 1. blueprintRequest message:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+       xmlns:info="urn:ietf:params:xml:ns:conference-info"
+       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+   <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+                  xsi:type="ccmp:ccmp-blueprint-request-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:AudioRoom@example.com</confObjID>
+         <operation>retrieve</operation>
+         <ccmp:blueprintRequest/>
+   </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. blueprintResponse message from the server:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+       xmlns:info="urn:ietf:params:xml:ns:conference-info"
+       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+  <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:type="ccmp:ccmp-blueprint-response-message-type">
+  <confUserID>xcon-userid:alice@example.com</confUserID>
+
+
+
+Barnes, et al.               Standards Track                   [Page 61]
+
+RFC 6503                          CCMP                        March 2012
+
+
+  <confObjID>xcon:AudioRoom@example.com</confObjID>
+  <operation>retrieve</operation>
+  <response-code>200</response-code>
+  <response-string>Success</response-string>
+  <ccmp:blueprintResponse>
+    <blueprintInfo entity="xcon:AudioRoom@example.com">
+     <info:conference-description>
+        <info:display-text>AudioRoom</info:display-text>
+        <info:available-media>
+           <info:entry label="audioLabel">
+              <info:display-text>audio stream</info:display-text>
+              <info:type>audio</info:type>
+           </info:entry>
+        </info:available-media>
+     </info:conference-description>
+     <info:users>
+       <xcon:join-handling>allow</xcon:join-handling>
+      </info:users>
+     <xcon:floor-information>
+      <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
+       <xcon:conference-floor-policy>
+           <xcon:floor id="audioFloor">
+               <xcon:media-label>audioLabel</xcon:media-label>
+           </xcon:floor>
+       </xcon:conference-floor-policy>
+     </xcon:floor-information>
+    </blueprintInfo>
+   </ccmp:blueprintResponse>
+  </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+         Figure 20: Getting Information about a Specific Blueprint
+
+6.3.  Alice Creates a New Conference through a Cloning Operation
+
+   This 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 <confObjID> parameter.  The picture shows such
+   a transaction.  Notice that the response contains, in the <confInfo>
+   parameter, the document associated with the newly created conference,
+   which is compliant with the standard XCON data model.  The
+   <confObjID> parameter in the response is set to the XCON-URI of the
+   new conference (in this case, "xcon:8977794@example.com").  We also
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 62]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   notice that this value is equal to the value of the 'entity'
+   attribute of the <conference-info> 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)                                  |
+       |------------------------------------------------------>|
+       |                                                       |
+       |                            CCMP confResponse message  |
+       |                              - confUserID: Alice      |
+       |                              - confObjID: newConfId   |
+       |                              - operation: create      |
+       |                              - response-code: 200     |
+       |                              - version: 1             |
+       |                              - confInfo: newConfInfo  |
+       |<------------------------------------------------------|
+       |                                                       |
+       .                                                       .
+       .                                                       .
+
+1. confRequest message:
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<ccmp:ccmpRequest
+      xmlns:info="urn:ietf:params:xml:ns:conference-info"
+      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+   <ccmpRequest
+         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:type="ccmp:ccmp-conf-request-message-type">
+      <confUserID>xcon-userid:alice@example.com</confUserID>
+      <confObjID>xcon:AudioRoom@example.com</confObjID>
+      <operation>create</operation>
+      <ccmp:confRequest/>
+   </ccmpRequest>
+</ccmp:ccmpRequest>
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 63]
+
+RFC 6503                          CCMP                        March 2012
+
+
+2. confResponse message from the server:
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<ccmp:ccmpResponse
+      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+      xmlns:info="urn:ietf:params:xml:ns:conference-info"
+      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+     xsi:type="ccmp:ccmp-conf-response-message-type">
+ <confUserID>xcon-userid:alice@example.com</confUserID>
+ <confObjID>xcon:8977794@example.com</confObjID>
+ <operation>create</operation>
+ <response-code>200</response-code>
+ <response-string>Success</response-string>
+ <version>1</version>
+ <ccmp:confResponse>
+   <confInfo entity="xcon:8977794@example.com">
+     <info:conference-description>
+       <info:display-text>
+              New conference by Alice cloned from AudioRoom
+       </info:display-text>
+       <info:available-media>
+               <info:entry label="333">
+                 <info:display-text>audio stream</info:display-text>
+                 <info:type>audio</info:type>
+               </info:entry>
+        </info:available-media>
+      </info:conference-description>
+      <info:users>
+           <xcon:join-handling>allow</xcon:join-handling>
+      </info:users>
+      <xcon:floor-information>
+      <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
+       <xcon:conference-floor-policy>
+          <xcon:floor id="11">
+             <xcon:media-label>333</xcon:media-label>
+          </xcon:floor>
+       </xcon:conference-floor-policy>
+      </xcon:floor-information>
+     </confInfo>
+    </ccmp:confResponse>
+  </ccmpResponse>
+</ccmp:ccmpResponse>
+
+        Figure 21: Creating a New Conference by Cloning a Blueprint
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 64]
+
+RFC 6503                          CCMP                        March 2012
+
+
+6.4.  Alice Updates Conference Information
+
+   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
+   <display-text> element under the <conference-description> 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                             |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                            CCMP confResponse message  |
+        |                              - confUserID: Alice      |
+        |                              - confObjID: 8977794     |
+        |                              - operation: update      |
+        |                              - response-code: 200     |
+        |                              - version: 2             |
+        |                              - confInfo: (null)       |
+        |<------------------------------------------------------|
+        |                                                       |
+        .                                                       .
+        .                                                       .
+
+ 1. confRequest message:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+      xmlns:info="urn:ietf:params:xml:ns:conference-info"
+            xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+   <ccmpRequest
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:type="ccmp:ccmp-conf-request-message-type">
+     <confUserID>xcon-userid:alice@example.com</confUserID>
+
+
+
+Barnes, et al.               Standards Track                   [Page 65]
+
+RFC 6503                          CCMP                        March 2012
+
+
+     <confObjID>xcon:8977794@example.com</confObjID>
+     <operation>update</operation>
+     <ccmp:confRequest>
+          <confInfo entity="xcon:8977794@example.com">
+             <info:conference-description>
+               <info:display-text>
+                  Alice's conference
+               </info:display-text>
+             </info:conference-description>
+          </confInfo>
+       </ccmp:confRequest>
+   </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+ 2. confResponse message from the server:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+      xmlns:info="urn:ietf:params:xml:ns:conference-info"
+      xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:type="ccmp:ccmp-conf-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>update</operation>
+         <response-code>200</response-code>
+         <response-string>Success</response-string>
+         <version>2</version>
+         <ccmp:confResponse/>
+     </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+                Figure 22: Updating Conference Information
+
+6.5.  Alice Inserts a List of Users into the Conference Object
+
+   This section illustrates the fifth transaction in the overall flow.
+   Alice modifies the <allowed-users-list> under the <users> 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:
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 66]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   CCMP Client                                             CCMP Server
+        |                                                       |
+        | CCMP usersRequest message                             |
+        |   - confUserID: Alice                                 |
+        |   - confObjID: 8977794                                |
+        |   - operation: update                                 |
+        |   - usersInfo: usersUpdates                           |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                           CCMP usersResponse message  |
+        |                             - confUserID: Alice       |
+        |                             - confObjID: 8977794      |
+        |                             - operation: update       |
+        |                             - response-code: 200      |
+        |                             - version: 3              |
+        |                             - usersInfo: (null)       |
+        |<------------------------------------------------------|
+        |                                                       |
+        .                                                       .
+        .                                                       .
+
+ 1. usersRequest message:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+      xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+          xmlns:info="urn:ietf:params:xml:ns:conference-info"
+          xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+                  xsi:type="ccmp:ccmp-users-request-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>update</operation>
+         <ccmp:usersRequest>
+             <usersInfo>
+                 <xcon:allowed-users-list>
+                     <xcon:target method="dial out"
+                                  uri="xmpp:cicciolo@pippozzo.com"/>
+                     <xcon:target method="refer"
+                                  uri="tel:+1-972-555-1234"/>
+                     <xcon:target method="refer"
+                                  uri="sip:Carol@example.com"/>
+                 </xcon:allowed-users-list>
+             </usersInfo>
+         </ccmp:usersRequest>
+     </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 67]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ 2. usersResponse message from the server:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+       xmlns:info="urn:ietf:params:xml:ns:conference-info"
+       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:type="ccmp:ccmp-users-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>retrieve</operation>
+         <response-code>200</response-code>
+         <response-string>Success</response-string>
+         <version>3</version>
+         <ccmp:usersResponse/>
+     </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+           Figure 23: Updating the List of Allowed Users for the
+                   Conference 'xcon:8977794@example.com'
+
+6.6.  Alice Joins the Conference
+
+   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
+   <userInfo> parameter, a <user> 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 <confUserID> parameter is equal to the 'entity' attribute of
+   the <userInfo> 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 68]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   CCMP Client                                             CCMP Server
+        |                                                       |
+        | CCMP userRequest message                              |
+        |   - confUserID: Alice                                 |
+        |   - confObjID: 8977794                                |
+        |   - operation: create                                 |
+        |   - userInfo: AliceUserInfo                           |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                            CCMP userResponse message  |
+        |                              - confUserID: Alice      |
+        |                              - confObjID: 8977794     |
+        |                              - operation: create      |
+        |                              - response-code: 200     |
+        |                              - version: 4             |
+        |                              - userInfo: (null)       |
+        |<------------------------------------------------------|
+        |                                                       |
+        .                                                       .
+        .                                                       .
+
+ 1. userRequest message:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpRequest
+        xmlns:info="urn:ietf:params:xml:ns:conference-info"
+            xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+            xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+             xsi:type="ccmp:ccmp-user-request-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+                 <operation>create</operation>
+         <ccmp:userRequest>
+             <userInfo entity="xcon-userid:alice@example.com">
+                 <info:associated-aors>
+                     <info:entry>
+                         <info:uri>
+                            mailto:Alice83@example.com
+                         </info:uri>
+                         <info:display-text>email</info:display-text>
+                     </info:entry>
+                 </info:associated-aors>
+                 <info:endpoint entity="sip:alice_789@example.com"/>
+             </userInfo>
+         </ccmp:userRequest>
+     </ccmpRequest>
+ </ccmp:ccmpRequest>
+
+
+
+Barnes, et al.               Standards Track                   [Page 69]
+
+RFC 6503                          CCMP                        March 2012
+
+
+ 2. userResponse message from the server:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+       xmlns:info="urn:ietf:params:xml:ns:conference-info"
+       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
+     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:type="ccmp:ccmp-user-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>create</operation>
+         <response-code>200</response-code>
+         <response-string>Success</response-string>
+         <version>4</version>
+         <ccmp:userResponse/>
+     </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+            Figure 24: Alice Joins the Conference through CCMP
+
+6.7.  Alice Adds a New User to the Conference
+
+   This 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 <userInfo>
+   parameter, a <user> 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 Section 4.3, 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 <userInfo> 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:
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 70]
+
+RFC 6503                          CCMP                        March 2012
+
+
+  CCMP Client                                             CCMP Server
+       |                                                       |
+       | CCMP userRequest message                              |
+       |   - confUserID: Alice                                 |
+       |   - confObjID: 8977794                                |
+       |   - operation: create                                 |
+       |   - userInfo: dummyUserID, CiccioUserInfo             |
+       |------------------------------------------------------>|
+       |                                                       |
+       |                       CCMP optionsResponse message    |
+       |                            - confUserID: Alice        |
+       |                            - confObjID: 8977794       |
+       |                            - operation: create        |
+       |                            - response-code: 200       |
+       |                            - version: 5               |
+       |                            - userInfo: userIDCiccio,  |
+       |                                        CiccioUserInfo |
+       |                                                       |
+       |<------------------------------------------------------|
+       |                                                       |
+       .                                                       .
+       .                                                       .
+
+
+1. "third-party" userRequest message from Alice:
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<ccmp:ccmpRequest
+       xmlns:info="urn:ietf:params:xml:ns:conference-info"
+       xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+       xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+                 xsi:type="ccmp:ccmp-user-request-message-type">
+        <confUserID>xcon-userid:alice@example.com</confUserID>
+        <confObjID>xcon:8977794@example.com</confObjID>
+        <operation>create</operation>
+        <ccmp:userRequest>
+            <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
+                <info:associated-aors>
+                    <info:entry>
+                        <info:uri>
+                            mailto:Ciccio@example.com
+                        </info:uri>
+                        <info:display-text>email</info:display-text>
+                    </info:entry>
+                </info:associated-aors>
+                <info:endpoint entity="sip:Ciccio@example.com"/>
+            </userInfo>
+
+
+
+Barnes, et al.               Standards Track                   [Page 71]
+
+RFC 6503                          CCMP                        March 2012
+
+
+        </ccmp:userRequest>
+    </ccmpRequest>
+</ccmp:ccmpRequest>
+
+2. "third-party" userResponse message from the server:
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <ccmp:ccmpResponse
+        xmlns:info="urn:ietf:params:xml:ns:conference-info"
+        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+                   xsi:type="ccmp:ccmp-user-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>create</operation>
+         <response-code>200</response-code>
+         <version>5</version>
+         <ccmp:userResponse>
+                 <userInfo entity="xcon-userid:Ciccio@example.com">
+                 <info:associated-aors>
+                     <info:entry>
+                         <info:uri>
+                             mailto:Ciccio@example.com
+                         </info:uri>
+                         <info:display-text>email</info:display-text>
+                     </info:entry>
+                 </info:associated-aors>
+                 <info:endpoint entity="sip:Ciccio@example.com"/>
+             </userInfo>
+         </ccmp:userResponse>
+     </ccmpResponse>
+ </ccmp:ccmpResponse>
+
+      Figure 25: Alice Adds a New User to the Conference through CCMP
+
+6.8.  Alice Asks for the CCMP Server Capabilities
+
+   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
+   <confUserID> parameter.  Looking at the <options> element in the
+   received optionsResponse, Alice infers the following server
+   capabilities as regards standard CCMP messages:
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 72]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   o  the server doesn't support sidebarsByValRequest nor the
+      sidebarByValRequest messages, since they do not appear in the
+      <standard-message-list>;
+
+   o  the only implemented operation for the blueprintRequest message is
+      "retrieve", since no other <operation> entries are included in the
+      related <operations> field.
+
+   By analyzing the <extended-message-list>, 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 <schema-ref> element, and the only operation
+   provided by this extension is "retrieve".  To better understand how
+   Alice can exploit the "confSummaryRequest" extension via CCMP, see
+   Section 6.9.
+
+   The figure below shows the optionsRequest/optionsResponse message
+   exchange between Alice and the CCMP server.
+
+   CCMP Client                                             CCMP Server
+        |                                                       |
+        | CCMP optionsRequest message                           |
+        |   - confUserID: Alice                                 |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                          CCMP userResponse message    |
+        |                            - confUserID: Alice        |
+        |                            - response-code: 200       |
+        |                            - options (list of both    |
+        |                              standard and extended    |
+        |                              supported messages)      |
+        |<------------------------------------------------------|
+        |                                                       |
+        .                                                       .
+        .                                                       .
+
+ 1. optionsRequest (Alice asks for CCMP server capabilities)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <ccmp:ccmpRequest
+         xmlns:info="urn:ietf:params:xml:ns:conference-info"
+         xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+         xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+     <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+        xsi:type="ccmp:ccmp-options-request-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+
+
+
+Barnes, et al.               Standards Track                   [Page 73]
+
+RFC 6503                          CCMP                        March 2012
+
+
+     </ccmpRequest>
+   </ccmp:ccmpRequest>
+
+ 2. optionsResponse (the server returns the list of its conference
+    control capabilities)
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+   <ccmp:ccmpResponse
+          xmlns:info="urn:ietf:params:xml:ns:conference-info"
+          xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+          xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
+     <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:type="ccmp:ccmp-options-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <response-code>200</response-code>
+         <response-string>success</response-string>
+         <ccmp:optionsResponse>
+            <options>
+               <standard-message-list>
+                  <standard-message>
+                     <name>blueprintsRequest</name>
+                  </standard-message>
+                  <standard-message>
+                    <name>blueprintRequest</name>
+                    <operations>
+                      <operation>retrieve</operation>
+                    </operations>
+                  </standard-message>
+                  <standard-message>
+                    <name>confsRequest</name>
+                  </standard-message>
+                  <standard-message>
+                    <name>confRequest</name>
+                  </standard-message>
+                  <standard-message>
+                     <name>usersRequest</name>
+                  </standard-message>
+                  <standard-message>
+                     <name>userRequest</name>
+                  </standard-message>
+                  <standard-message>
+                     <name>sidebarsByRefRequest</name>
+                  </standard-message>
+                  <standard-message>
+                     <name>sidebarByRefRequest</name>
+                  </standard-message>
+               </standard-message-list>
+               <extended-message-list>
+
+
+
+Barnes, et al.               Standards Track                   [Page 74]
+
+RFC 6503                          CCMP                        March 2012
+
+
+                  <extended-message>
+                     <name>confSummaryRequest</name>
+                     <operations>
+                       <operation>retrieve</operation>
+                     </operations>
+                     <schema-def>
+                          http://example.com/ccmp-extension-schema.xsd
+                     </schema-def>
+                     <description>
+                          confSummaryRequest is intended
+                          to allow the requestor to retrieve
+                          a brief description
+                          of the conference indicated in the
+                          confObjID request parameter
+                     </description>
+                  </extended-message>
+               </extended-message-list>
+            </options>
+         </ccmp:optionsResponse>
+     </ccmpResponse>
+   </ccmp:ccmpResponse>
+
+         Figure 26: Alice Asks for the Server Control Capabilities
+
+6.9.  Alice Makes Use of a CCMP Server Extension
+
+   In this section, 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 Section 6.8).
+
+   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:
+
+     <?xml version="1.0" encoding="UTF-8"?>
+       <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+                 targetNamespace="http://example.com/ccmp-extension"
+                 xmlns="http://example.com/ccmp-extension">
+
+       <xs:element name="confSummary" type="conf-summary-type"/>
+
+       <xs:complexType name="conf-summary-type">
+         <xs:sequence>
+           <xs:element name="title" type="xs:string"/>
+           <xs:element name="status" type="xs:string"/>
+           <xs:element name="public" type="xs:boolean"/>
+           <xs:element name="media" type="xs:string"/>
+
+
+
+Barnes, et al.               Standards Track                   [Page 75]
+
+RFC 6503                          CCMP                        March 2012
+
+
+         </xs:sequence>
+       </xs:complexType>
+
+     </xs:schema>
+
+          Figure 27: Example of XML Schema defining an extension
+                   parameter (ccmp-extension-schema.xsd)
+
+   As can be inferred from the schema file, the <confSummary> 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 <public> 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" <extensionName>,
+   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                 |
+       |------------------------------------------------------>|
+       |                                                       |
+       |                      CCMP extendedResponse message    |
+       |                            - confUserID: Alice        |
+       |                            - confObjID: 8977794       |
+       |                            - operation: retrieve      |
+       |                            - response-code: 200       |
+       |                            - extensionName:           |
+       |                              confSummaryRequest       |
+       |                            - confSummary              |
+       |<------------------------------------------------------|
+       |                                                       |
+       .                                                       .
+       .                                                       .
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 76]
+
+RFC 6503                          CCMP                        March 2012
+
+
+1. extendedRequest (Alice makes use of the "confSummaryRequest")
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+  <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
+        xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+        xmlns:example="http://example.com/ccmp-extension">
+    <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xsi:type="ccmp:ccmp-extended-request-message-type">
+        <confUserID>xcon-userid:alice@example.com</confUserID>
+        <confObjID>xcon:8977794@example.com</confObjID>
+        <operation>retrieve</operation>
+        <ccmp:extendedRequest>
+               <extensionName>confRequestSummary</extensionName>
+        </ccmp:extendedRequest>
+    </ccmpRequest>
+  </ccmp:ccmpRequest>
+
+2. extendedResponse (the server provides Alice with a brief description
+   of the desired conference)
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+  <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
+          xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
+          xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
+          xmlns:example="http://example.com/ccmp-extension">
+    <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:type="ccmp:ccmp-extended-response-message-type">
+         <confUserID>xcon-userid:alice@example.com</confUserID>
+         <confObjID>xcon:8977794@example.com</confObjID>
+         <operation>retrieve</operation>
+         <response-code>200</response-code>
+         <response-string>success</response-string>
+         <ccmp:extendedResponse>
+           <extensionName>confSummaryRequest</extensionName>
+           <example:confSummary>
+               <title> Alice's conference </title>
+               <status> active </status>
+               <public> true </public>
+               <media> audio </media>
+           </example:confSummary>
+         </ccmp:extendedResponse>
+     </ccmpResponse>
+  </ccmp:ccmpResponse>
+
+       Figure 28: Alice Exploits the 'confSummaryRequest' Extension
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 77]
+
+RFC 6503                          CCMP                        March 2012
+
+
+7.  Locating a Conference Server
+
+   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.
+
+   Section 12.4.1 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
+   Section 12.4.2, 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.".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 78]
+
+RFC 6503                          CCMP                        March 2012
+
+
+             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 Section 12.4.
+
+8.  Managing Notifications
+
+   As per [RFC5239], 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 [RFC4582].
+
+   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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 79]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Notification Protocol:
+
+      operates between the Notification Client and the XCON Notification
+      Service.  This specification does not define a new notification
+      protocol.  For clients that use SIP as the call signaling
+      protocol, the XCON event package [RFC6502] MUST be used by the
+      client for notifications of changes in the conference data as
+      described below.
+
+   The protocol 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 [RFC3261] 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
+   [RFC6502].  This is the default mechanism for conferencing clients as
+   is SIP for signaling per the XCON framework [RFC5239].
+
+   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.
+
+9.  HTTP Transport
+
+   This section describes the use of HTTP [RFC2616] and HTTP over TLS
+   [RFC2818] as transport mechanisms for CCMP, which a conforming
+   conference server and conferencing client MUST support.
+
+
+
+Barnes, et al.               Standards Track                   [Page 80]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 [RFC2617] and cookies [RFC6265] is
+   OPTIONAL for a conferencing client that conforms to this
+   specification.  These mechanisms are unnecessary because CCMP
+   requests carry their own authentication information (in the "subject"
+   field; see Section 5.1).  A conferencing client SHOULD include
+   support for HTTP proxy authentication.
+
+   A CCMP request is carried in the body of an HTTP POST request.  The
+   conferencing client MUST include a Host header in the request.
+
+   The MIME type of CCMP request and response bodies is "application/
+   ccmp+xml".  The conference server and conferencing client MUST
+   provide this value in the HTTP Content-Type and Accept header fields.
+   If the conference server 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).
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 81]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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 [RFC2818].  TLS provides message integrity and
+   confidentiality between the conferencing client and the conference
+   server.  The conferencing client MUST implement the server
+   authentication method described in HTTPS [RFC2818].  The device uses
+   the URI obtained during conference server discovery to authenticate
+   the server.  The details of this authentication method are provided
+   in Section 3.1 of HTTPS [RFC2818].  When TLS is used, the
+   conferencing client SHOULD fail a request if server authentication
+   fails.
+
+10.  Security Considerations
+
+   As identified in the XCON framework [RFC5239], 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 82]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   The following summarizes the security considerations for CCMP:
+
+   1.  The client MUST determine the proper conference server.  The
+       conference server discovery is described in Section 7.
+
+   2.  The client MUST connect to the proper conference server.  The
+       mechanisms for addressing this security consideration are
+       described in Section 10.1.
+
+   3.  The protocol MUST support a confidentiality and integrity
+       mechanism.  As described in Section 9, implementations of CCMP
+       MUST implement the HTTP transport over TLS [RFC2818].
+
+   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 Section 10.2.
+
+   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 Section 10.3.
+
+   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
+       Section 10.4.
+
+   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.
+
+10.1.  Assuring That the Proper Conference Server Has Been Contacted
+
+   Section 7 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 [RFC5246], 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
+
+
+
+Barnes, et al.               Standards Track                   [Page 83]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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
+   [RFC2818] 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.
+
+10.2.  User Authentication and Authorization
+
+   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 [RFC3261] 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 [RFC5239] 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/
+
+
+
+Barnes, et al.               Standards Track                   [Page 84]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   participant in the conference are contained in the 'entity' attribute
+   in the <user> 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 <users> element in the
+   conference object.  The <users> element is comprised of <user>
+   elements representing a specific user in the conferencing system.
+
+   Each <user> element contains an 'entity' attribute with the XCON-
+   USERID and a <role> element.  Thus, each authorized user (as
+   represented by an XCON-USERID) can be associated with a <role>
+   element.
+
+10.3.  Security and Privacy of Identity
+
+   An overview of the required privacy and anonymity for users of a
+   conferencing system are provided in the XCON framework [RFC5239].
+   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 <provide-anonymity>
+   element defined in the XCON data model [RFC6501].  The <provide-
+   anonymity> element controls the degree to which a user reveals their
+   identity.  The following summarizes the values for the <provide-
+   anonymity> element that the client includes in their requests:
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 85]
+
+RFC 6503                          CCMP                        March 2012
+
+
+      "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 <provide-anonymity> element in the <confInfo> parameter in a CCMP
+   confRequest message with an <operation> parameter of "update" or
+   "create" or in the <userInfo> parameter in a CCMP userRequest message
+   with an <operation> parameter of "update" or "create".  If the
+   <provide-anonymity> 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 Section 10.2.  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).
+
+10.4.  Mitigating DoS Attacks
+
+   [RFC4732] 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
+   Section 10.2, 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, Section 4.4 describes the use of a timer
+   mechanism to alleviate the situation whereby CCMP messages pend
+
+
+
+Barnes, et al.               Standards Track                   [Page 86]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   indefinitely, thus increasing the potential that pending requests
+   continue to increase when is a server is receiving more requests than
+   it can process.
+
+11.  XML Schema
+
+   This section gives the XML schema definition
+   [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] 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 Section 12.  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.
+
+<?xml version="1.0" encoding="utf-8"?>
+
+   <xs:schema
+      targetNamespace="urn:ietf:params:xml:ns:xcon-ccmp"
+      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xmlns="urn:ietf:params:xml:ns:xcon-ccmp"
+      xmlns:tns="urn:ietf:params:xml:ns:xcon-ccmp"
+      xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
+      xmlns:info="urn:ietf:params:xml:ns:conference-info"
+      xmlns:xs="http://www.w3.org/2001/XMLSchema">
+
+
+      <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
+                 schemaLocation="DataModel.xsd"/>
+      <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
+                 schemaLocation="rfc4575.xsd"/>
+
+      <xs:element name="ccmpRequest" type="ccmp-request-type" />
+      <xs:element name="ccmpResponse" type="ccmp-response-type" />
+
+<!-- CCMP request definition -->
+
+   <xs:complexType name="ccmp-request-type">
+       <xs:sequence>
+           <xs:element name="ccmpRequest"
+                       type="ccmp-request-message-type" />
+       </xs:sequence>
+   </xs:complexType>
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 87]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- ccmp-request-message-type -->
+
+   <xs:complexType abstract="true"
+                   name="ccmp-request-message-type">
+       <xs:sequence>
+           <xs:element name="subject" type="subject-type"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="confUserID" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="confObjID" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="operation" type="operationType"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="conference-password" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+          <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+      </xs:sequence>
+      <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+<!-- CCMP response definition -->
+
+   <xs:complexType name="ccmp-response-type">
+       <xs:sequence>
+           <xs:element name="ccmpResponse"
+                       type="ccmp-response-message-type" />
+       </xs:sequence>
+   </xs:complexType>
+
+   <!-- ccmp-response-message-type -->
+
+   <xs:complexType abstract="true" name="ccmp-response-message-type">
+       <xs:sequence>
+           <xs:element name="confUserID" type="xs:string"
+                       minOccurs="1" maxOccurs="1" />
+           <xs:element name="confObjID" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="operation" type="operationType"
+                       minOccurs="0"
+                       maxOccurs="1" />
+           <xs:element name="response-code"
+                       type="response-codeType"
+                       minOccurs="1" maxOccurs="1" />
+           <xs:element name="response-string" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="version" type="xs:positiveInteger"
+                       minOccurs="0" maxOccurs="1" />
+
+
+
+Barnes, et al.               Standards Track                   [Page 88]
+
+RFC 6503                          CCMP                        March 2012
+
+
+           <xs:any namespace="##other" processContents="lax"
+                       minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+<!-- CCMP REQUESTS -->
+
+   <!-- blueprintsRequest -->
+
+   <xs:complexType name="ccmp-blueprints-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintsRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- blueprintsRequestType -->
+
+   <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
+
+   <xs:complexType name="blueprintsRequestType">
+       <xs:sequence>
+           <xs:element name="xpathFilter" type="xs:string"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!--  blueprintRequest -->
+
+   <xs:complexType name="ccmp-blueprint-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 89]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- blueprintRequestType -->
+
+   <xs:element name="blueprintRequest" type="blueprintRequestType" />
+
+   <xs:complexType name="blueprintRequestType">
+       <xs:sequence>
+           <xs:element name="blueprintInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- confsRequest -->
+
+   <xs:complexType name="ccmp-confs-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="confsRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- confsRequestType -->
+
+   <xs:element name="confsRequest" type="confsRequestType" />
+   <xs:complexType name="confsRequestType">
+       <xs:sequence>
+           <xs:element name="xpathFilter" type="xs:string"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- confRequest -->
+
+   <xs:complexType name="ccmp-conf-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="confRequest" />
+               </xs:sequence>
+           </xs:extension>
+
+
+
+Barnes, et al.               Standards Track                   [Page 90]
+
+RFC 6503                          CCMP                        March 2012
+
+
+       </xs:complexContent>
+    </xs:complexType>
+
+   <!-- confRequestType -->
+
+   <xs:element name="confRequest" type="confRequestType" />
+
+   <xs:complexType name="confRequestType">
+       <xs:sequence>
+           <xs:element name="confInfo" type="info:conference-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- usersRequest -->
+
+   <xs:complexType name="ccmp-users-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="usersRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- usersRequestType -->
+
+   <xs:element name="usersRequest" type="usersRequestType" />
+
+   <xs:complexType name="usersRequestType">
+       <xs:sequence>
+           <xs:element name="usersInfo" type="info:users-type"
+                       minOccurs="0" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+   <!-- userRequest -->
+
+   <xs:complexType name="ccmp-user-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+
+
+
+Barnes, et al.               Standards Track                   [Page 91]
+
+RFC 6503                          CCMP                        March 2012
+
+
+               <xs:sequence>
+                   <xs:element ref="userRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- userRequestType -->
+
+   <xs:element name="userRequest" type="userRequestType" />
+
+   <xs:complexType name="userRequestType">
+       <xs:sequence>
+           <xs:element name="userInfo" type="info:user-type"
+                       minOccurs="0" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- sidebarsByValRequest -->
+
+   <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarsByValRequest" />
+                </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+    <!-- sidebarsByValRequestType -->
+
+    <xs:element name="sidebarsByValRequest"
+                type="sidebarsByValRequestType" />
+
+    <xs:complexType name="sidebarsByValRequestType">
+        <xs:sequence>
+            <xs:element name="xpathFilter"
+                        type="xs:string" minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+            <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 92]
+
+RFC 6503                          CCMP                        March 2012
+
+
+    <!-- sidebarsByRefRequest -->
+
+    <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-request-message-type">
+                <xs:sequence>
+                    <xs:element ref="sidebarsByRefRequest" />
+                </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+   <!-- sidebarsByRefRequestType -->
+
+   <xs:element name="sidebarsByRefRequest"
+               type="sidebarsByRefRequestType" />
+
+   <xs:complexType name="sidebarsByRefRequestType">
+       <xs:sequence>
+           <xs:element name="xpathFilter" type="xs:string"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- sidebarByValRequest -->
+
+   <xs:complexType name="ccmp-sidebarByVal-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarByValRequest" />
+               </xs:sequence>
+            </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- sidebarByValRequestType -->
+
+   <xs:element name="sidebarByValRequest"
+               type="sidebarByValRequestType"/>
+
+   <xs:complexType name="sidebarByValRequestType">
+       <xs:sequence>
+           <xs:element name="sidebarByValInfo"
+                       type="info:conference-type" minOccurs="0"/>
+
+
+
+Barnes, et al.               Standards Track                   [Page 93]
+
+RFC 6503                          CCMP                        March 2012
+
+
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+   <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- sidebarByRefRequest -->
+
+   <xs:complexType name="ccmp-sidebarByRef-request-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-request-message-type">
+               <xs:sequence>
+                   <xs:element ref="sidebarByRefRequest" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- sidebarByRefRequestType -->
+
+   <xs:element name="sidebarByRefRequest"
+               type="sidebarByRefRequestType" />
+
+   <xs:complexType name="sidebarByRefRequestType">
+       <xs:sequence>
+           <xs:element name="sidebarByRefInfo"
+                       type="info:conference-type" minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- extendedRequest -->
+
+   <xs:complexType name="ccmp-extended-request-message-type">
+      <xs:complexContent>
+          <xs:extension base="tns:ccmp-request-message-type">
+             <xs:sequence>
+                         <xs:element ref="extendedRequest"/>
+             </xs:sequence>
+          </xs:extension>
+      </xs:complexContent>
+   </xs:complexType>
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 94]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- extendedRequestType -->
+
+   <xs:element name="extendedRequest" type="extendedRequestType"/>
+
+   <xs:complexType name="extendedRequestType">
+     <xs:sequence>
+        <xs:element name="extensionName"
+                    type="xs:string" minOccurs="1"/>
+        <xs:any namespace="##other" processContents="lax" minOccurs="0"
+                           maxOccurs="unbounded" />
+    </xs:sequence>
+   </xs:complexType>
+
+   <!-- optionsRequest -->
+
+        <xs:complexType name="ccmp-options-request-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-request-message-type">
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+
+<!-- CCMP RESPONSES -->
+
+   <!-- blueprintsResponse -->
+
+   <xs:complexType name="ccmp-blueprints-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintsResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+   </xs:complexType>
+
+   <!-- blueprintsResponseType -->
+
+   <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
+
+   <xs:complexType name="blueprintsResponseType">
+       <xs:sequence>
+           <xs:element name="blueprintsInfo" type="info:uris-type"
+                       minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+
+
+
+Barnes, et al.               Standards Track                   [Page 95]
+
+RFC 6503                          CCMP                        March 2012
+
+
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+   <!-- blueprintResponse -->
+
+   <xs:complexType name="ccmp-blueprint-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                   <xs:element ref="blueprintResponse" />
+               </xs:sequence>
+           </xs:extension>
+       </xs:complexContent>
+    </xs:complexType>
+
+    <!-- blueprintResponseType -->
+
+    <xs:element name="blueprintResponse" type="blueprintResponseType"/>
+
+    <xs:complexType name="blueprintResponseType">
+        <xs:sequence>
+          <xs:element name="blueprintInfo" type="info:conference-type"
+                        minOccurs="0"/>
+          <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- confsResponse -->
+
+    <xs:complexType name="ccmp-confs-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="confsResponse" />
+                </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- confsResponseType -->
+
+    <xs:element name="confsResponse" type="confsResponseType" />
+
+    <xs:complexType name="confsResponseType">
+        <xs:sequence>
+            <xs:element name="confsInfo" type="info:uris-type"
+
+
+
+Barnes, et al.               Standards Track                   [Page 96]
+
+RFC 6503                          CCMP                        March 2012
+
+
+                        minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- confResponse -->
+
+    <xs:complexType name="ccmp-conf-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="confResponse"/>
+                </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- confResponseType -->
+
+    <xs:element name="confResponse" type="confResponseType" />
+
+    <xs:complexType name="confResponseType">
+        <xs:sequence>
+            <xs:element name="confInfo" type="info:conference-type"
+                        minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- usersResponse -->
+
+    <xs:complexType name="ccmp-users-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="usersResponse" />
+                </xs:sequence>
+            </xs:extension>
+         </xs:complexContent>
+    </xs:complexType>
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 97]
+
+RFC 6503                          CCMP                        March 2012
+
+
+    <!-- usersResponseType -->
+
+    <xs:element name="usersResponse" type="usersResponseType" />
+
+    <xs:complexType name="usersResponseType">
+        <xs:sequence>
+            <xs:element name="usersInfo" type="info:users-type"
+                        minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- userResponse -->
+
+    <xs:complexType name="ccmp-user-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="userResponse" />
+                </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- userResponseType -->
+
+    <xs:element name="userResponse" type="userResponseType" />
+
+    <xs:complexType name="userResponseType">
+        <xs:sequence>
+            <xs:element name="userInfo" type="info:user-type"
+                        minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                  minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- sidebarsByValResponse -->
+
+    <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="sidebarsByValResponse" />
+                </xs:sequence>
+
+
+
+Barnes, et al.               Standards Track                   [Page 98]
+
+RFC 6503                          CCMP                        March 2012
+
+
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- sidebarsByValResponseType -->
+
+    <xs:element name="sidebarsByValResponse"
+                type="sidebarsByValResponseType" />
+
+    <xs:complexType name="sidebarsByValResponseType">
+        <xs:sequence>
+            <xs:element name="sidebarsByValInfo"
+                        type="info:sidebars-by-val-type" minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- sidebarsByRefResponse -->
+
+    <xs:complexType name="ccmp-sidebarsByRef-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="sidebarsByRefResponse" />
+                </xs:sequence>
+            </xs:extension>
+       </xs:complexContent>
+    </xs:complexType>
+
+    <!-- sidebarsByRefResponseType -->
+
+    <xs:element name="sidebarsByRefResponse"
+                type="sidebarsByRefResponseType" />
+
+    <xs:complexType name="sidebarsByRefResponseType">
+        <xs:sequence>
+            <xs:element name="sidebarsByRefInfo" type="info:uris-type"
+                        minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+
+
+
+
+
+Barnes, et al.               Standards Track                   [Page 99]
+
+RFC 6503                          CCMP                        March 2012
+
+
+    <!-- sidebarByValResponse -->
+
+    <xs:complexType name="ccmp-sidebarByVal-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="sidebarByValResponse" />
+                </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- sidebarByValResponseType -->
+
+    <xs:element name="sidebarByValResponse"
+                type="sidebarByValResponseType" />
+
+    <xs:complexType name="sidebarByValResponseType">
+        <xs:sequence>
+            <xs:element name="sidebarByValInfo"
+                        type="info:conference-type" minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+         </xs:sequence>
+         <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- sidebarByRefResponse -->
+
+    <xs:complexType name="ccmp-sidebarByRef-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="sidebarByRefResponse" />
+                 </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- sidebarByRefResponseType -->
+
+    <xs:element name="sidebarByRefResponse"
+                type="sidebarByRefResponseType" />
+
+    <xs:complexType name="sidebarByRefResponseType">
+        <xs:sequence>
+            <xs:element name="sidebarByRefInfo"
+                        type="info:conference-type" minOccurs="0"/>
+
+
+
+Barnes, et al.               Standards Track                  [Page 100]
+
+RFC 6503                          CCMP                        March 2012
+
+
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- extendedResponse -->
+
+    <xs:complexType name="ccmp-extended-response-message-type">
+       <xs:complexContent>
+           <xs:extension base="tns:ccmp-response-message-type">
+               <xs:sequence>
+                                 <xs:element ref="extendedResponse"/>
+               </xs:sequence>
+           </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- extendedResponseType -->
+
+    <xs:element name="extendedResponse" type="extendedResponseType"/>
+
+    <xs:complexType name="extendedResponseType">
+        <xs:sequence>
+                <xs:element name="extensionName"
+                            type="xs:string" minOccurs="1"/>
+                <xs:any namespace="##other" processContents="lax"
+                        minOccurs="0"
+                    maxOccurs="unbounded" />
+        </xs:sequence>
+    </xs:complexType>
+
+    <!-- optionsResponse -->
+
+        <xs:complexType name="ccmp-options-response-message-type">
+        <xs:complexContent>
+            <xs:extension base="tns:ccmp-response-message-type">
+                <xs:sequence>
+                    <xs:element ref="optionsResponse"/>
+                 </xs:sequence>
+            </xs:extension>
+        </xs:complexContent>
+    </xs:complexType>
+
+    <!-- optionsResponseType -->
+
+    <xs:element name="optionsResponse"
+                type="optionsResponseType" />
+
+
+
+Barnes, et al.               Standards Track                  [Page 101]
+
+RFC 6503                          CCMP                        March 2012
+
+
+    <xs:complexType name="optionsResponseType">
+        <xs:sequence>
+            <xs:element name="options"
+                        type="options-type" minOccurs="0"/>
+            <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+<!-- CCMP ELEMENT TYPES -->
+
+    <!-- response-codeType-->
+
+    <xs:simpleType name="response-codeType">
+         <xs:restriction base="xs:positiveInteger">
+                 <xs:pattern value="[0-9][0-9][0-9]" />
+         </xs:restriction>
+    </xs:simpleType>
+
+    <!-- operationType -->
+
+    <xs:simpleType name="operationType">
+      <xs:restriction base="xs:token">
+        <xs:enumeration value="retrieve"/>
+        <xs:enumeration value="create"/>
+        <xs:enumeration value="update"/>
+        <xs:enumeration value="delete"/>
+      </xs:restriction>
+    </xs:simpleType>
+
+   <!-- subject-type -->
+
+   <xs:complexType name="subject-type">
+       <xs:sequence>
+           <xs:element name="username" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:element name="password" type="xs:string"
+                       minOccurs="0" maxOccurs="1" />
+           <xs:any namespace="##other" processContents="lax"
+                   minOccurs="0" maxOccurs="unbounded"/>
+       </xs:sequence>
+       <xs:anyAttribute namespace="##any" processContents="lax"/>
+   </xs:complexType>
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 102]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   <!-- options-type -->
+
+    <xs:complexType name="options-type">
+      <xs:sequence>
+        <xs:element name="standard-message-list"
+                    type="standard-message-list-type"
+                    minOccurs="1"/>
+        <xs:element name="extended-message-list"
+                    type="extended-message-list-type"
+                    minOccurs="0"/>
+        <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- standard-message-list-type -->
+
+    <xs:complexType name="standard-message-list-type">
+      <xs:sequence>
+        <xs:element name="standard-message"
+                    type="standard-message-type"
+                    minOccurs="1" maxOccurs="10"/>
+        <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- standard-message-type -->
+
+    <xs:complexType name="standard-message-type">
+      <xs:sequence>
+        <xs:element name="name"
+                    type="standard-message-name-type"
+                    minOccurs="1"/>
+        <xs:element name="operations"
+                    type="operations-type"
+                    minOccurs="0"/>
+        <xs:element name="schema-def" type="xs:string" minOccurs="0"/>
+        <xs:element name="description" type="xs:string" minOccurs="0"/>
+        <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 103]
+
+RFC 6503                          CCMP                        March 2012
+
+
+    <!-- standard-message-name-type -->
+
+    <xs:simpleType name="standard-message-name-type">
+      <xs:restriction base="xs:token">
+        <xs:enumeration value="confsRequest"/>
+        <xs:enumeration value="confRequest"/>
+        <xs:enumeration value="blueprintsRequest"/>
+        <xs:enumeration value="blueprintRequest"/>
+        <xs:enumeration value="usersRequest"/>
+        <xs:enumeration value="userRequest"/>
+        <xs:enumeration value="sidebarsByValRequest"/>
+        <xs:enumeration value="sidebarByValRequest"/>
+        <xs:enumeration value="sidebarsByRefRequest"/>
+        <xs:enumeration value="sidebarByRefRequest"/>
+      </xs:restriction>
+    </xs:simpleType>
+
+    <!-- operations-type -->
+
+    <xs:complexType name="operations-type">
+      <xs:sequence>
+        <xs:element name="operation" type="operationType"
+                    minOccurs="1" maxOccurs="4"/>
+      </xs:sequence>
+      <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- extended-message-list-type -->
+
+    <xs:complexType name="extended-message-list-type">
+      <xs:sequence>
+        <xs:element name="extended-message"
+                    type="extended-message-type"
+                    minOccurs="0"/>
+        <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+    <!-- extended-message-type -->
+
+    <xs:complexType name="extended-message-type">
+      <xs:sequence>
+        <xs:element name="name" type="xs:string" />
+        <xs:element name="operations"
+                    type="operations-type"
+                    minOccurs="0"/>
+
+
+
+Barnes, et al.               Standards Track                  [Page 104]
+
+RFC 6503                          CCMP                        March 2012
+
+
+        <xs:element name="schema-def" type="xs:string" />
+        <xs:element name="description"
+                    type="xs:string"
+                    minOccurs="0"/>
+        <xs:any namespace="##other" processContents="lax"
+                    minOccurs="0" maxOccurs="unbounded"/>
+        </xs:sequence>
+        <xs:anyAttribute namespace="##any" processContents="lax"/>
+    </xs:complexType>
+
+ </xs:schema>
+
+                        Figure 30: CCMP XML Schema
+
+12.  IANA Considerations
+
+   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.
+
+12.1.  URN Sub-Namespace Registration
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 105]
+
+RFC 6503                          CCMP                        March 2012
+
+
+      XML:
+
+   BEGIN
+     <?xml version="1.0"?>
+     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+       <head>
+         <title>CCMP Messages</title>
+       </head>
+       <body>
+         <h1>Namespace for CCMP Messages</h1>
+         <h2>urn:ietf:params:xml:ns:xcon-ccmp</h2>
+         <p>See <a href="http://www.rfc-editor.org/rfc/rfc6503.txt">
+            RFC 6503</a>.</p>
+       </body>
+     </html>
+   END
+
+
+12.2.  XML Schema Registration
+
+   This section registers an XML schema per the guidelines in [RFC3688].
+
+   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
+      Section 11 of this document.
+
+12.3.  MIME Media Type Registration for 'application/ccmp+xml'
+
+   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)
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 106]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   Optional parameters:  charset
+      Same as the charset parameter of "application/xml" as specified in
+      [RFC3023], Section 3.2.
+
+   Encoding considerations:  Same as the encoding considerations of
+      "application/xml" as specified in [RFC3023], Section 3.2.
+
+   Security considerations:  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
+      Section 10 are required to protect the data.  This media type does
+      not contain executable content.
+
+   Interoperability considerations:  None.
+
+   Published specification:  RFC 6503.
+
+   Applications that use this media type:  Centralized Conferencing
+      control clients and servers.
+
+   Additional Information:  Magic Number(s): (none)
+      File extension(s): .ccmp
+      Macintosh File Type Code(s): TEXT
+
+   Person & email address to contact for further information:  Mary
+      Barnes <mary.ietf.barnes@gmail.com>
+
+   Intended usage:  LIMITED USE
+
+   Author/Change controller:  The IETF
+
+   Other information:  This media type is a specialization of
+      application/xml [RFC3023], and many of the considerations
+      described there also apply to application/ccmp+xml.
+
+12.4.  DNS Registrations
+
+   Section 12.4.1 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
+   Section 12.4.2, is used to identify an XCON server that understands
+   CCMP.
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 107]
+
+RFC 6503                          CCMP                        March 2012
+
+
+12.4.1.  Registration of a Conference Server Application Service Tag
+
+   This section registers a new S-NAPTR/U-NAPTR Application Service tag
+   for XCON, as mandated by [RFC3958].
+
+   Application Service Tag: XCON
+
+   Intended usage: Identifies a server that supports centralized
+   conferencing.
+
+   Defining publication: RFC 6503
+
+   Contact information: The authors of this document
+
+   Author/Change controller: The IESG
+
+12.4.2.  Registration of a Conference Server Application Protocol Tag
+         for CCMP
+
+   This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
+   for CCMP, as mandated by [RFC3958].
+
+   Application Service Tag: CCMP
+
+   Intended Usage: Identifies the Centralized Conferencing (XCON)
+   Manipulation Protocol.
+
+   Applicable Service Tag(s): XCON
+
+   Terminal NAPTR Record Type(s): U
+
+   Defining Publication: RFC 6503
+
+   Contact Information: The authors of this document
+
+   Author/Change Controller: The IESG
+
+12.5.  CCMP Protocol Registry
+
+   The IANA has created a new registry for CCMP:
+   http://www.iana.org/assignments/ccmp-parameters.  The document
+   creates initial sub-registries for CCMP operation types and response
+   codes.
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 108]
+
+RFC 6503                          CCMP                        March 2012
+
+
+12.5.1.  CCMP Message Types
+
+   The following summarizes the registry for CCMP messages:
+
+   Related Registry:   CCMP Message Types Registry
+
+   Defining RFC:  RFC 6503.
+
+   Registration/Assignment Procedures:  Following the policies outlined
+      in [RFC5226], the IANA policy for assigning new values for the
+      CCMP message types for CCMP is Specification Required.
+
+   Registrant Contact:  IETF XCON working group (xcon@ietf.org), Mary
+      Barnes (mary.ietf.barnes@gmail.com).
+
+   This specification establishes the Message sub-registry under
+   http://www.iana.org/assignments/ccmp-messages.  The initial Message
+   table is populated using the CCMP messages described in Section 4.1
+   and defined in the XML schema in Section 11.
+
+  Message              Description                             Reference
+  -------              -----------                             ---------
+  optionsRequest       Used by a conferencing client           [RFC6503]
+                       to query a conference server for
+                       its capabilities, in terms of
+                       supported messages.
+
+  optionsResponse      Returns a list of CCMP messages         [RFC6503]
+                       supported by the specific
+                       conference server.
+
+  blueprintsRequest    Used by a conferencing client           [RFC6503]
+                       to query a conference server for
+                       its capabilities, in terms of
+                       available conference blueprints.
+
+  blueprintsResponse   Returns a list of blueprints supported  [RFC6503]
+                       by the specific conference server.
+
+  blueprintRequest     Sent to retrieve the conference object  [RFC6503]
+                       associated with a specific blueprint.
+
+  blueprintResponse    Returns the conference object           [RFC6503]
+                       associated with a specific blueprint.
+
+  confsRequest         Used by a conferencing client           [RFC6503]
+                       to query a conference server for
+                       its scheduled/active conferences.
+
+
+
+Barnes, et al.               Standards Track                  [Page 109]
+
+RFC 6503                          CCMP                        March 2012
+
+
+  confsResponse        Returns the list of the currently       [RFC6503]
+                       activated/scheduled conferences
+                       at the server.
+
+  confRequest          Used to create a conference object      [RFC6503]
+                       and/or to request an operation on
+                       the conference object as a whole.
+
+  confResponse         Indicates the result of the operation   [RFC6503]
+                       on the conference object as a whole.
+
+  userRequest          Used to request an operation on the     [RFC6503]
+                       <user> element in the conference object.
+
+  userResponse         Indicates the result of the requested   [RFC6503]
+                       operation on the <user> element in
+                       the conference object.
+
+  usersRequest         Used to manipulate the <users> element  [RFC6503]
+                       in the conference object, including
+                       parameters such as the <allowed-users-list>,
+                       <join-handling>, etc.
+
+  usersResponse        Indicates the result of the request     [RFC6503]
+                       to manipulate the <users> element in
+                       the conference object.
+
+  sidebarsByValRequest Used to retrieve the <sidebars-by-val>  [RFC6503]
+                       element of the target conference object.
+
+  sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503]
+                        conferences within the target
+                        conference object.
+
+  sidebarsByRefRequest  Used to retrieve the <sidebars-by-ref> [RFC6503]
+                        element of the target conference
+                        object.
+
+  sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503]
+                        conferences associated with the target
+                        conference object.
+
+  sidebarByValRequest  Used to request an operation on a       [RFC6503]
+                       sidebar-by-val conference.
+
+  sidebarByValResponse Indicates the result of the request to  [RFC6503]
+                       manipulate a sidebar-by-val conference.
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 110]
+
+RFC 6503                          CCMP                        March 2012
+
+
+  sidebarByRefRequest  Used to request an operation on a       [RFC6503]
+                       sideber-by-ref conference.
+
+  sidebarByRefResponse Indicates the result of the request to  [RFC6503]
+                       manipulate a sidebar-by-ref conference.
+
+12.5.2.  CCMP Response Codes
+
+   The following summarizes the requested registry for CCMP response
+   codes:
+
+   Related Registry:   CCMP Response Code Registry
+
+   Defining RFC:  RFC 6503.
+
+   Registration/Assignment Procedures:  Following the policies outlined
+      in [RFC5226], the IANA policy for assigning new values for the
+      Response codes for CCMP shall be Specification Required.
+
+   Registrant Contact:  IETF XCON working group (xcon@ietf.org), Mary
+      Barnes (mary.ietf.barnes@gmail.com).
+
+   This specification establishes the Response-code sub-registry under
+   http://www.iana.org/assignments/ccmp-parameters.  The initial
+   Response-code table is populated using the Response codes defined in
+   Section 5.4 as follows:
+
+         Default
+         Response
+  Number String              Description                       Reference
+  ------ -------------       ------------                      ---------
+   200   Success             The request was successfully      [RFC6503]
+                             processed.
+
+   400   Bad Request         The request was badly formed in   [RFC6503]
+                             some fashion.
+
+   401   Unauthorized        The user was not authorized for   [RFC6503]
+                             the specific operation on the
+                             conference object.
+
+   403   Forbidden           The specific operation is not     [RFC6503]
+                             valid for the target conference
+                             object.
+
+   404   Object Not Found    The specific conference object    [RFC6503]
+                             was not found.
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 111]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   409   Conflict            A requested operation cannot be   [RFC6503]
+                             successfully completed by the
+                             server. For example, the
+                             modification of an object
+                             cannot be applied because
+                             the client version of the object
+                             is obsolete and the requested
+                             modifications collide with the
+                             up-to-date state of the object
+                             stored at the server.
+
+   420   User Not Found      The user who is the target of the [RFC6503]
+                             requested operation is unknown.
+
+   421   Invalid confUserID  The <confUserID> parameter of the [RFC6503]
+                             sender in the request is invalid.
+
+
+   422   Invalid Conference  A request to access/manipulate    [RFC6503]
+         Password            a password-protected conference
+                             object contained an invalid
+                             <conference-password> parameter.
+
+   423   Conference Password A request to access/manipulate    [RFC6503]
+         Required            a password-protected conference
+                             object did not contain a
+                             <conference-password> parameter.
+
+   424   Authentication      The server wants to authenticate  [RFC6503]
+         Required            the request through the <subject>
+                             parameter but the parameter is
+                             not provided in the request.
+
+   425   Forbidden Delete    The conferencing system cannot    [RFC6503]
+         Parent              delete the specific conference
+                             object because it is a
+                             parent for another conference object.
+
+   426   Forbidden Change    The target conference object      [RFC6503]
+         Protected           cannot be changed (e.g., due to
+                             policies, roles or privileges).
+
+   427   Invalid Domain Name The domain name in an             [RFC6503]
+                             AUTO_GENERATE_X
+                             instance in the conference object
+                             is not within the conference
+                             server's domain of responsibility.
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 112]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   500   Server Internal     The conference server experienced [RFC6503]
+         Error               some sort of internal error.
+
+   501   Not Implemented     The specific operation is not     [RFC6503]
+                             implemented on the conferencing
+                             system.
+
+   510   Request Timeout     The request could not be          [RFC6503]
+                             processed within a reasonable
+                             time (as specified by the
+                             conferencing system).
+
+   511   Resources Not       The conference server cannot      [RFC6503]
+         Available           execute a command because of
+                             resource issues, e.g., it cannot
+                             create a conference because
+                             the system has reached its limits
+                             on the number of conferences.
+
+13.  Acknowledgments
+
+   The authors 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 Section 6
+   have been extracted.
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A., and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+
+
+Barnes, et al.               Standards Track                  [Page 113]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
+              Centralized Conferencing", RFC 5239, June 2008.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
+              April 2011.
+
+   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+              "Conference Information Data Model for Centralized
+              Conferencing (XCON)", RFC 6501, March 2012.
+
+   [W3C.REC-xmlschema-1-20041028]
+              Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney,
+              "XML Schema Part 1: Structures Second Edition", World Wide
+              Web Consortium Recommendation REC-xmlschema-1-20041028,
+              October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+   [W3C.REC-xmlschema-2-20041028]
+              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
+              Second Edition", World Wide Web Consortium
+              Recommendation REC-xmlschema-2-20041028, October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
+
+14.2.  Informative References
+
+   [REST]     Fielding, "Architectural Styles and the Design of Network-
+              based Software Architectures", 2000.
+
+   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+              Types", RFC 3023, January 2001.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
+              Service Location Using SRV RRs and the Dynamic Delegation
+              Discovery Service (DDDS)", RFC 3958, January 2005.
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 114]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
+              Control Protocol (BFCP)", RFC 4582, November 2006.
+
+   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
+              Service Considerations", RFC 4732, December 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
+              Urpalainen, "Conference Event Package Data Format
+              Extension for Centralized Conferencing (XCON)", RFC 6502,
+              March 2012.
+
+   [W3C.REC-soap12-part1-20070427]
+              Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M.,
+              Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2
+              Part 1: Messaging Framework (Second Edition)", World Wide
+              Web Consortium Recommendation REC-soap12-part1-20070427,
+              April 2007,
+              <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
+
+   [W3C.REC-soap12-part2-20070427]
+              Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N.,
+              Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2
+              Part 2: Adjuncts (Second Edition)", World Wide Web
+              Consortium Recommendation REC-soap12-part2-20070427,
+              April 2007,
+              <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 115]
+
+RFC 6503                          CCMP                        March 2012
+
+
+Appendix A.  Evaluation of Other Protocol Models and  Transports
+             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 Appendix A.1 and by defining resources following a
+   RESTful architecture Appendix A.2.
+
+   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
+
+
+
+Barnes, et al.               Standards Track                  [Page 116]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   messages/operations is required to use a different transport
+   protocol.
+
+A.1.  Using SOAP for CCMP
+
+   A remote procedure call (RPC) mechanism for CCMP could use SOAP
+   (Simple Object Access Protocol [W3C.REC-soap12-part1-20070427]
+   [W3C.REC-soap12-part2-20070427]), where conferences and the other
+   objects are modeled as services with associated operations.
+   Conferences and other objects are selected by their own local
+   identifiers, such as email-like names for users.  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.
+
+A.2.  A RESTful Approach for CCMP
+
+   Conference objects can also be modeled as resources identified by
+   URIs, with the basic CRUD operations mapped to the HTTP methods POST/
+   PUT for creating objects, GET for reading objects, PATCH/POST/PUT for
+   changing objects, and DELETE for deleting them.  Many of the objects,
+   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 [RFC2616] to transfer domain-specific XML-
+   encoded data objects defined in the "Conference Information Data
+   Model for Centralized Conferencing" [RFC6501].
+
+   Following on the CRUD approach, CCMP could follow the well-known REST
+   (REpresentational State Transfer) architectural style [REST].  CCMP
+   could map onto the REST philosophy, by specifying resource URIs,
+   resource formats, 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.
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 117]
+
+RFC 6503                          CCMP                        March 2012
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.               Standards Track                  [Page 118]
+
+RFC 6503                          CCMP                        March 2012
+
+
+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]
+