XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Intended status: Standards Track                              C. Boulton
Expires: September 11, 2009 January 14, 2010                                NS-Technologies
                                                             S P. Romano
                                                    University of Napoli
                                                          H. Schulzrinne
                                                     Columbia University
                                                          March 10,
                                                           July 13, 2009

             Centralized Conferencing Manipulation Protocol
                        draft-ietf-xcon-ccmp-02
                        draft-ietf-xcon-ccmp-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 11, 2009. January 14, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Centralized Conferencing Manipulation Protocol (CCMP) can create,
   retrieve, change and delete objects describing a centralized
   conference, such as state and capabilities of the conference,
   participants, and their roles.  The conference information is
   contained in XML documents and fragments conforming to the
   centralized conferencing data model schema.  CCMP is a state-less
   client-server protocol based on a request/response model.
   Conferencing clients send requests to conference servers, which
   respond to the client with the conference information.

   This document also discusses options for using existing notification
   protocols to inform conference client about the changes in the state
   of a conference during its entire lifetime.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  System Architecture  . . . . . . . . . . . . . . . . . . . . .  8  9
   6.  Conference Object and User Identifiers . . . . . . . . . . . . 10 11
     6.1.  Conference Object  . . . . . . . . . . . . . . . . . . . . 10 11
     6.2.  Conference Users and Participants  . . . . . . . . . . . . 10 11
   7.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . . 12 13
     7.1.  Implementation Approach  . . . . . . . . . . . . . . . . . 13 14
     7.2.  CCMP protocol messages . . . . . . . . . . . . . . . . . . 13 14
       7.2.1.  CCMP Request Message . . . . . . . . . . . . . . . . . 13 14
       7.2.2.  CCMP Response Message  . . . . . . . . . . . . . . . . 14 16
         7.2.2.1.  CCMP Response Codes  . . . . . . . . . . . . . . . 15 18
       7.2.3.  Detailed CCMP Messages . . . . . . . . . . . . . . . . 16 21
         7.2.3.1.  blueprintsRequest and blueprintsResponse
                   messages . . . . . . . . . . . . . . . . . . . . . 20 23
         7.2.3.2.  confsRequest and confsResponse messages  . . . . . 21 25
         7.2.3.3.  blueprintRequest and blueprintResponse messages  . 22 26
         7.2.3.4.  confRequest and confResponse messages  . . . . . . 25 28
         7.2.3.5.  usersRequest and usersResponse messages  . . . . . 28 31
         7.2.3.6.  userRequest and userResponse messages  . . . . . . 31 34
         7.2.3.7.  sidebarsByValRequest and sidebarsByValResponse
                   messages . . . . . . . . . . . . . . . . . . . . . 33 39
         7.2.3.8.  sidebarByValRequest and sidebarByValResponse
                   messages . . . . . . . . . . . . . . . . . . . . . 34 41
         7.2.3.9.  sidebarsByRefRequest and sidebarsByRefResponse
                   messages . . . . . . . . . . . . . . . . . . . . . 36 44
         7.2.3.10. sidebarByRefRequest and sidebarByRefResponse
                   messages . . . . . . . . . . . . . . . . . . . . . 37 46
   8.  A complete example of the CCMP in action . . . . . . . . . . . 40 50
     8.1.  Alice retrieves the available blueprints . . . . . . . . . 40 50
     8.2.  Alice gets detailed information about a specific
           blueprint  . . . . . . . . . . . . . . . . . . . . . . . . 43 53
     8.3.  Alice creates a new conference through a cloning
           operation  . . . . . . . . . . . . . . . . . . . . . . . . 45 55
     8.4.  Alice updates conference information . . . . . . . . . . . 47 57
     8.5.  Alice inserts a list of users in the conference object . . 49 59
     8.6.  Alice joins the conference . . . . . . . . . . . . . . . . 51 61
     8.7.  Alice adds a new user to the conference  . . . . . . . . . 52 63
   9.  Locating a Conference Control Server . . . . . . . . . . . . . 55 66
   10. XML Schema . . Managing Notifications . . . . . . . . . . . . . . . . . . . . 68
   11. HTTP Transport . . . . 57
   11. Managing notifications . . . . . . . . . . . . . . . . . . . . 69
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 71
     12.1. Assuring that the Proper Conferencing Server has been
           contacted  . . . . . . . . . . . . . . . . . . . . . . . . 72
     12.2. User Authentication and Authorization  . . . . . . . . . . 72
     12.3. Security and Privacy of Identity . . . . . . . . . . . . . 73
   13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 74
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 70
     12.1. 85
     14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 70
     12.2. 85
     14.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 70
     12.3. 85
     14.3. MIME Media Type Registration for 'application/ccmp+xml'  . 71
     12.4. 86
     14.4. DNS Registrations  . . . . . . . . . . . . . . . . . . . . 72
       12.4.1. 87
       14.4.1. Registration of a Location Server Application
               Service Tag  . . . . . . . . . . . . . . . . . . . . . 72
       12.4.2. 87
       14.4.2. Registration of a Location Server Application
               Protocol Tag for HELD  . . . . . . . . . . . . . . . . 72
     12.5. 87
     14.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 73
       12.5.1. 88
       14.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 73
       12.5.2. 88
       14.5.2. CCMP Response Codes  . . . . . . . . . . . . . . . . . 74
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 76
   14. 89
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 77
   15. 92
   16. Changes since last Version . . . . . . . . . . . . . . . . . . 78
   16. 93
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
     16.1. 95
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 79
     16.2. 95
     17.2. Informative References . . . . . . . . . . . . . . . . . . 79 95
   Appendix A.  Appendix A: Other protocol models and transports
                considered for CCMP . . . . . . . . . . . . . . . . . 81 97
     A.1.  Using SOAP for the CCMP  . . . . . . . . . . . . . . . . . 81 97
     A.2.  A RESTful approach for the CCMP  . . . . . . . . . . . . . 82 98
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 83 99

1.  Introduction

   The 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 end points.

   The CCMP implements the client-server model within the XCON
   Framework, with the conferencing client and conference control server
   acting as client and server, respectively.  The CCMP uses HTTP
   [RFC2616] as the protocol to transfer the CCMP requests and
   responses, which contain the domain-specific XML-encoded data objects
   defined in the Conference Information Data Model for Centralized
   Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model].
   Other protocol models such as the use of a REST (REpresentational
   State Transfer) architectural style [REST] were considered.  However,
   the CCMP is a request/response protocol with new or updated data
   relevant to the specific conference object returned in the response.
   Whereas, a REST approach involves singular/monolithic operations on
   data, with the response typically indicating either success or
   failure, rather than providing updated data based on a specific
   operation, thus, it was not considered a good choice.  Details of the
   use of REST for the CCMP, as well as other protocols considered
   (e.g., SOAP) are provided in Appendix A.

   Section 4 provides an overview of the design of the CCMP, followed by
   the system architecture in Section 5.  Section 6 discusses the
   primary keys in the conference object carried in the protocol.  An
   overview of the operations associated with each protocol request and
   response is provided in Section 7.  A complete example of the
   operation of the CCMP, describing a typical call flow associated with
   conference creation and manipulation, is provided in Section 8.
   Section 10 13 provides the XML schema.

2.  Conventions

   In this document, the

   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 BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations. [RFC2119].

3.  Terminology

   In additon to the terms defined in the Framework for Centralized
   Conferencing [RFC5239], this document uses the following terms and
   acronyms:

   CRUD:  CRUD stands for Create/Read/Update/Delete and indicates a
      design pattern supporting creating, retrieving, updating and
      destroying objects.

   REST:  REpresentational State Transfer (REST) is an architectural
      style, i.e., a coordinated set of architectural constraints.  REST
      is based on the consideration that a software architecture can
      often be specified as an appropriate configuration of components,
      data and connectors, all coordinated through constraining their
      mutual relationships.  Coordination and constraints help achieve a
      desired set of architectural properties.  [REST]

   SOAP:  Simple Object Access Protocol defined in
      [W3C.REC-soap12-part1-20030624] and
      [W3C.REC-soap12-part2-20030624].

4.  Protocol Overview

   This document specifies the basic operations that can create,
   retrieve, modify and delete conference-related information in a
   centralized conference.  The core set of objects includes conference
   blueprints, manipulated in the
   CCMP protocol described in this document includes conference
   blueprints, the conference itself, object, users, and sidebars.

   Each update operation in the protocol model is atomic and either succeeds or
   fails as a whole.  Thus, a  The conference server has MUST ensure that the
   operations are atomic in that the operation invoked by a specific
   conference client completes prior to another client's operation on
   the same conference object.  The details for this data locking
   functionality are out of scope for the CCMP protocol specification
   and are implementation specific for a conference server.  Thus, the
   conference server first check 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> <service-
   uris> and abort the remaining updates.

   Because  Also, since multiple clients
   can modify the same conference objects, conference clients need to SHOULD
   first obtain the current object from the conference server and then
   update the whole
   object.

   Editor's Note: Do we need locking, using WebDAV or floor control?
   Otherwise, relevant data elements in the conference object prior to
   invoking a specific operation on the conference server.  In some
   cases, the data changes made are not fully applied, since a previous
   operation by user A could get lost when user B wants to
   modify another conference client may have altered some other parameter. of the
   data.  Where appropriate (i.e., depending upon the specific data and
   policies), the conference server SHOULD indicate that the data has
   been modified and return the current conference object to the client.
   For example, A changes the subject, B
   adds one conferencing client may add a new user to the
   conference object.  Thus, a service URI. subsequent request by another
   conferencing client should provide a conference object containing
   this new user.

   It is likely that implementations and future standardization work
   will add more conference attributes and parameters.  There are three
   types of extensions.  The first and simplest type of extension adds
   elements to the overall conference description, media descriptions or
   descriptions of users.  The XML namespace mechanism makes such
   extensions relatively easy, although implementations still have to
   deal with companion implementations that may not understand the new
   namespaces.  The CCMP "blueprintsRequest" message allows clients to
   determine the capabilities of a specific server, reflected by the
   specific blueprints supported by that server.

   A second type of extension replaces the conference, user or media
   objects with completely new schema definitions, i.e., the namespaces
   for these objects themselves differ from the basic one defined in
   this document.  As long as the OPTIONS request blueprintsRequest message remains
   available and keeps to a mutually-understood definition, a compatible
   client and server will be able to bootstrap themselves into using
   these new objects.

   Finally, it is conceivable that new object types are needed beyond
   the core conference, user and media objects and their children.
   These would also be introduced by namespaces and new URIs.

5.  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.

   ........................................................
   .  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            |                  .
   .               +-------------------+                  .
   .                        ^                             .
   .........................|..............................
                            |
                            |Conference
                            |Control
                            |Manipulation
                            |Protocol
                            |
   .........................|..............................
   .                        V                             .
   .                +----------------+                    .
   .                | Conference     |                    .
   .                | Control        |                    .
   .                | Client         |                    .
   .                +----------------+                    .
   .                                                      .
   .  Conferencing Client                                 .
   ........................................................

                  Figure 1: Conference Client Interaction

   CCMP serves as the Conference Control Protocol, allowing the
   conference control client to interface with the conference object
   maintained by the conferencing system, as represented in Figure 1.
   Conference Control is one part of functionality for advanced
   conferencing supported by a conferencing client.  Other functions are
   discussed in the XCON framework and related documents.

6.  Conference Object and User Identifiers

   This section provides an overview of the conference object and
   conference users which are key protocol elements for creating the
   CCMP requests and responses.  The identifiers used in CCMP for the
   conference object (XCON-URI) and conference user (XCON-USERID) are
   introduced in the XCON framework and defined in the XCON data model
   [I-D.ietf-xcon-common-data-model].

6.1.  Conference Object

   Conference objects feature a simple dynamic inheritance-and-override
   mechanism.  Conference objects are linked into a tree, where each
   tree node inherits attributes from its parent node.  The roots of
   these inheritance trees are 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.  An
   object can mark certain of its properties as unalterable, so that
   they cannot be overridden.

   The schema for the conference object is defined in the XCON data
   model.  Conference objects are uniquely identified by the XCON-URI.
   A client MAY specify a parent element that indicates the parent from
   which the conference is to inherit values.  When creating
   conferences, the XCON-URI included by the client is only a
   suggestion.  To avoid identifier collisions and to conform to local
   server policy, the conference control server MAY choose a different
   identifier.

6.2.  Conference Users and Participants

   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.  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
   Control Server creates individual users, assigning them a unique
   Conference User Identifier (XCON-USERID).

   A variety of elements defined in the common <conference-info> element
   as specified in the XCON data model are used to determine how a
   specific user expects and is allowed to join a conference as a
   participant or as a user with specific privileges (e.g., observer).
   For example, the <method> attribute defines how the caller joins the
   conference, with a set of defined XML elements, namely <dial-in> for
   users that are allowed to dial in and <dial-out> for users that the
   conference focus will be trying to reach. <dial-in> is the default.

   If the conference is currently active, dial-out users are contacted
   immediately; otherwise, they are contacted at the start of the
   conference.  The conference control server assigns a unique
   Conference User Identifier (XCON-USERID) to each user.  The
   conference control server uses the XCON-USERID to change or delete
   <user> elements.  Depending upon policies and privileges, specific
   users MAY also manipulate <user> elements.

   In many conferences, users can dial in if they know the XCON-URI and
   an access code shared by all conference participants.  In this case,
   the system is typically not aware of the call signaling URL.  Thus,
   the initial <user> element does not have an entity attribute and the
   default type of <dial-in> is used to support this type of user.  For
   this case, the server assigns a locally-unique URI, such as a
   locally-scoped tel URI. URI [RFC3966].  The conference control server
   assigns a unique Conference User Identifier (XCON-USERID) to these
   users when they dial-in to join the conference.  If the user supports
   the notification event package [I-D.ietf-xcon-event-package], they
   can receive their XCON-USERID, thus allowing them to also manipulate
   the <user> attribute, including the entity attribute, in the
   conference object.

7.  Protocol Operations

   CCMP is a client-server, XML-based, stateless protocol, which has
   been specifically conceived to provide users with the necessary means
   for the creation, retrieval, modification and deletion of conference
   objects.  Conference-related information is encapsulated into CCMP
   messages in the form of documents or document fragments compliant
   with the XCON data model representation.

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

   create:  for the creation of a conference, 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 or a blueprint, or a
      sidebar) or a conference user.  A retrieve operation can also be
      used to obtain the XCON-URIs of the active conferences and/or
      blueprints available at the server.

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

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

   Thus, the main targets of CCMP operations are:

   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. <sidebars-by-value> elements) and external
      to it (i.e. <sidebars-by-ref> elements),

   o  <user> elements associated with conference users,

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

7.1.  Implementation Approach

   There have been a number of different proposals as to the most
   suitable implementation solution for the CCMP.  A non-exhaustive
   summary of the most interesting ones is provided in Appendix A.  The
   proposed
   solution for the 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,
   the 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 messages/operations is
   required to use a different transport protocol.

   The remainder of this document focuses on the selected approach.  The
   CCMP protocol inserts XML-based CCMP requests into the body of HTTP
   POST operations and retrieves responses from the body of HTTP '200
   OK' messages.  CCMP messages have a MIME-type of "application/
   ccmp+xml", which appears inside the "Content-Type" and "Accept"
   fields of HTTP requests and responses.  Section 11 provides the
   complete requirements for an HTTP implementation to support the CCMP.

7.2.  CCMP protocol messages

   CCMP messages are either requests or responses.  The general CCMP
   request message is defined in Section 7.2.1.  The general CCMP
   response message is defined in Section 7.2.2.  The details of the
   specific message type which is carried in the CCMP request and
   response messages are described in Section 7.2.3.

7.2.1.  CCMP Request Message

   A CCMP request message is comprised of the following parameters:

   confUserId:  A mandatory  An optional parameter containing the XCON-URI XCON-USERID of the
      client.  This  The "confUserID" parameter is REQUIRED by used to determine if the conferencing server for
      system specific
      conference control client has the authority to perform the
      operation, as well as other Authorization, Authentication and
      Accounting (AAA) procedures.

   confObjId:  an optional parameter containing, whenever necessary, the
      XCON-URI of  The attribute 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 above mentioned case
      will be provided in Section 7.2.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.

   password:  An optional parameter that MUST be inserted in all
      requests whose target conference object; object is password-protected (as
      per the <conference-password> element in
      [I-D.ietf-xcon-common-data-model]).

   specialized request message:  this  This is specialization of the generic
      request message (e.g., blueprintsRequest), containing parameters
      that are dependent on the specific request sent to the server, server.  A
      specialized response message MUST be included in the CCMP request
      message.  The details of which for the specialized messages and associated
      parameters are provided in Section 7.2.3 7.2.3.

   <xs:element name="ccmpRequest" type="ccmp-request-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>

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

    <xs:complexType abstract="true"
           name="ccmp-request-message-type">
     <xs:sequence>
      <xs:element name="confUserID" type="xs:string"
                           minOccurs="1"
            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="password" type="xs:string"
                        minOccurs="0" maxOccurs="1" />
      </xs:sequence>
    </xs:complexType>

               Figure 2: Structure of CCMP Request messages

7.2.2.  CCMP Response Message

   A CCMP response message is comprised of the following parameters:

   confUserId:  A mandatory parameter in CCMP response messages
      containing the XCON-URI XCON-USERID of the conferencing client which who issued
      the CCMP request message.

   confObjId:  An optional parameter containing the XCON-URI of the
      target conference object object.

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

   responseCode:  A mandatory parameter containing the response code
      associated with the request, request.  The response code MUST be chosen among
      from the codes listed in Section 7.2.2.1 7.2.2.1.

   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), server (e.g., blueprintsResponse).  A
      specialized request message SHOULD be included in the
      details 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 responseCode of which
      "badRequest".  The details for the specialized messages and
      associated parameters are provided in Section 7.2.3 7.2.3.

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

   <!-- CCMP response definition -->

   <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="0"
                           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 ref="response-code" minOccurs="1"
                           maxOccurs="1" />
           </xs:sequence>
   </xs:complexType>

               Figure 3: Structure of CCMP Response message

7.2.2.1.  CCMP Response Codes

   All CCMP response messages MUST include a "responseCode".  The
   following summarizes the CCMP response codes:

   success:  Successful completion of the requested operation.

   modified:  Successful completion of the requested operation, with
      partial data returned in the confObjID having been modified from
      the data included in the confObjID included request, either for a
      "create" or a "change" operation

   badRequest:  Syntactically malformed request

   objectNotFound:  Target conference object missing at the server (it
      refers to the 'confObjId' parameter in the generic request
      message)

   userNotFound:  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)

   invalidConfUserID:  User missing at the server (this code is returned
      in the case of requests in which the 'confUserID' of the sender is
      invalid).

   invalidPassword:  Target conference object's password contained in
      the request is wrong.

   passwordRequired:  Conference password missing in a request to access
      a password-protected conference object.

   unauthorized:  User not allowed to perform the required operation

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

   forbiddenDeleteParent:  Cancel operation failed since the target
      object is a parent of child objects which depend on it, or because
      it effects, based on the 'parent-enforceable' mechanism, the
      corresponding element in a child object

   forbiddenChangeProtected:  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)
   requestTimeout:  The time required to serve the request has exceeded
      the envisaged service threshold

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

   notImplemented:  Operation envisaged in the protocol, but not
      implemented in the contacted server.

7.2.3.  Detailed CCMP Messages

   Based on the request

   The handling of a responseCode of 'modified', 'objectNotFound',
   'userNotFound', 'deleteParentFailed' and response 'changeFailedProtected' are
   only applicable to specific operations for specialized message structures described in
   Section 7.2.1
   responses and Section 7.2.2, the following summarizes the
   specialized CCMP request/response types described in this document:

   1.   blueprintsRequest/blueprintsResponse

   2.   confsRequest/confsResponse

   3.   blueprintRequest/blueprintResponse

   4.   confRequest/confResponse
   5.   usersRequest/usersResponse

   6.   userRequest/userResponse

   7.   sidebarsByValRequest/sidebarsByValResponse

   8.   sidebarsByRefRequest/sidebarsByRefResponse

   9.   sidebarByValRequest/sidebarByValResponse

   10.  sidebarByRefRequest/sidebarByRefResponse

   These CCMP request/response pairs use the fundamental CCMP operations
   as defined details are provided in Section 7 to manipulate the conference data.  Table 1 7.2.3.  The
   following table summarizes the CCMP operations these responseCodes and corresponding actions that are
   valid for a specific CCMP request type, noting that neither the
   blueprintsRequest/blueprints/Response or confsRequest/ConfsResponse
   require an "operation" parameter.  The corresponding response MUST
   contain the same operation.  Note that some entries are labeled "N/A"
   indicating the operation is invalid for that request type.  In the
   case of an "N/A*", the specialized
   message and operation MAY be allowed for specific
   privileged users or system administrators, but is not part of the
   functionality included in this document. to which they are applicable:

   +---------------+------------+------------+------------+------------+
   | Operation     |  Retrieve Response code | Create     | Retrieve   | Update     | Delete     |
   +---------------+------------+------------+------------+------------+
   | ------------- | Modified      |            |            |            |
   | -Request Type |            |            |            |            |
   +---------------+------------+------------+------------+------------+
   | blueprintsReq |  Get list All create | N/A        |     N/A All update | N/A        |
   | uest          |     of     |            |            |            |
   |               | blueprints |            |            |            |               |               | . requests   |            | requests   |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | blueprintRequ |     Get    |    N/A*    |    N/A*    |    N/A*    |
   | est           | blueprint. |            |            |            |
   | objectNotFoun | userReques | All        | All update | All delete |
   | ------------- d             | ---------- t,         | ---------- retrieve   | ---------- requests   | ---------- requests   |
   |               |  sidebarBy | requests,  |            |            |
   | confsRequest               |  Get list ValRequest |     N/A EXCEPT:    |     N/A            |     N/A            |
   |               |     of   sidebars | blueprints |            |            |
   |               | conference ByRefReque | Request,   |            |            |
   |               | s (active, st         |  confsRequ |            |            |
   |               |     etc.)            | est        |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | confRequest   |    Gets    |   Creates  |   Changes  |   Deletes  |
   |               | conference | conference | conference | conference |
   |               |  object or |   object   |   object   |  Object as |
   |               | blueprint. |            |            |  a whole.  |
   |               |            |            |            |            |
   | ------------- userNotFound  | ---------- userReques | ---------- userReques | ---------- userReques | ---------- userReques |
   |               | t(3rd part | t          | t          | t          |
   | usersRequest               |   Gets a yinvite    |     N/A            |   Adds or            |     N/A            |
   |               |  specific  with thir |            |  modifies            |            |
   |               |    users duser      |            |     the            |            |
   |               |  element.  entity)   |            |  specified            |            |
   |               |  (*)       |            |    users            |            |
   |               |            |            |  element.            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | -------------               | ----------            | ----------            | ----------            | ----------            |
   | invalidConfUs | All create | All        | All update | All delete |
   | userRequest erID          |   Gets a requests,  |   Creates retrieve   |   Adds or requests   |  Deletes a requests   |
   |               |  specific EXCEPT:    | XCON-UserI requests   |  modifies            |    user            |
   |               |    user userReques | D     .            |     the            | element as            |
   |               |  element. twith no   |            |  specified            |  a whole.            |
   |               |  confUserI |            |    user            |            |
   |               | D(**)      |            |  element.            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarsByVal |    Gets forbiddenDele | N/A        | N/A        | N/A        |
   | Request       | sidebars-b |            |            |            |
   |               | y   -val   |            |            | All delete |
   | teParent      |    element            |            |            | request    |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarsByRef |    Gets    |     N/A forbiddenChan | N/A        | N/A        | All update | Request       | sidebars-b |            |            |            |
   |               | y   -ref   |            |            |            |
   |               |    element |            |            |            |
   | N/A        |
   | geProtected   |            |            | requests   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarByValR |   Gets a   |     N/A    |   Adds or  | Removes/de |
   | equest        |   sidebar  |            | modifies a | l etes the |
   |               |  element.  |            |  sidebar.  |    entire  |
   |               |            |            |            |   sidebar. |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarByRefR |   Gets a   |     N/A    |   Adds or  | Removes/de |
   | equest        |   sidebar  |            | modifies a | l etes the |
   |               |  element.  |            |  sidebar.  |    entire  |
   |               |            |            |            |   sidebar.            |
   +---------------+------------+------------+------------+------------+

             Table 1: Request Type Operation Specific Processing

   The following additional parameters are included Response codes and associated operations

   (*) 'userNotFound' in the specialized
   CCMP request/response messages detailed answer to a 'userRequest/create' operation: in
   the subsequent sections:

   operation:  An optional parameter for each CCMP request/response
      message.  This parameter is REQUIRED case of a third-party invite, this code can be returned if the
   'confUserId' (contained in all messages except for the "blueprintRequest", "blueprintResponse", "confsRequest" and
      "confsResponse" messages.

   blueprintInfo:  An optional parameter used for 'entity' attribute of the blueprintResponse
      message.  It is 'userInfo'
   parameter) of type "conference-type" as defined in the XCON
      data model and contains user to be added is unknown.  In the data case above, if
   instead it is the 'confUserID' of the conference object
      representing sender of the blueprint in request that is
   invalid, an 'invalidConfUserID' error code is returned to the conference server.  This
      parameter SHOULD client.

   (**) 'invalidConfUserID' is not be included sent in any other response type answers to 'userRequest/
   create' messages and SHOULD only be included in a "create", "update" or
      "delete" operation for having a blueprintRequest message in special cases
      where 'null' confUserId, since this case is
   associated with a user has special privileges such as an administrator.

   blueprintsInfo:  An optional parameter used for who is unaware of his own XCON-USERID, but
   wants to enter a known conference.

   In the
      blueprintsResponse message.  It contains case of a list response code of elements 'requestTimeout', a conferencing
   client MAY re-attempt the request within a period of
      type "blueprintInfo".  This parameter SHOULD not be included in
      any other response type messages and SHOULD only time that would
   be included in specific to a
      "create", "update" conference control client or "delete" operation for a blueprintRequest
      message in special cases where a user has special privileges such
      as an administrator.

   confsInfo:  An optional parameter used for conference control
   server.

   A response code of 'badRequest' indicates that the confsResponse message.
      It contains conference control
   client sent a list malformed request, which is indicative of XCON-URIs.  This parameter SHOULD not be
      included in any other response type messages and SHOULD only be
      included an error in a "create", "update"
   the conference control client or "delete" operation for a
      blueprintRequest message in special cases where the conference control server.
   The handling is specific to the conference control client
   implementation (e.g., generate a user has special
      privileges such as log, display an administrator.

   usersInfo:  An OPTIONAL parameter error message,
   etc.).  It is NOT RECOMMENDED that MAY be included the client re-attempt the request
   in a
      usersRequest this case.

   Response codes such as 'unauthorized', "forbidden' and usersReponse message, depending upon
   'operationNotAllowed' indicate the
      operation.  The 'usersInfo' parameter carries an object compliant
      with client does not have the <users> field of
   appropriate permissions, there is an error in the XCON data model.

7.2.3.1.  blueprintsRequest and blueprintsResponse messages

   A 'blueprintsRequest' (Figure 4) message permissions, or
   there is sent to request a system error in the list
   of XCON-URIs associated with client or conference control server,
   thus re-attempting the available blueprints from the
   conference server.  Such URIs can request would likely not succeed and thus is
   NOT RECOMMENDED.

   Any unexpected or unknown responseCode SHOULD be subsequently used treated by the
   client
   to access detailed information about a specified blueprint with in the same manner as a 'serverInternalError' responseCode,
   the handling of which is specific 'blueprintRequest' message per Section 7.2.3.3.  A
   'blueprintsRequest' message REQUIRES no additional parameters beyond
   those specified for to the basic conference control client
   implementation.

7.2.3.  Detailed CCMP Messages

   Based on the request message.  The associated
   'blueprintsResponse' and response message SHOULD contain, as shown structures described in Figure 4, a
   'blueprintsInfo' parameter containing
   Section 7.2.1 and Section 7.2.2, the above mentioned XCON-URI
   list.  The 'confObjId' parameter is NOT REQUIRED in following summarizes the request or
   response for
   specialized CCMP request/response types described in this transaction.

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

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

    <!-- blueprintsResponseType -->

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

   <xs:complexType name="blueprintsResponseType">
     <xs:sequence>
         <xs:element name="blueprintsInfo"
                     type="info:uris-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

    Figure 4: Structure of document:

   1.   blueprintsRequest/blueprintsResponse

   2.   confsRequest/confsResponse

   3.   blueprintRequest/blueprintResponse

   4.   confRequest/confResponse

   5.   usersRequest/usersResponse

   6.   userRequest/userResponse

   7.   sidebarsByValRequest/sidebarsByValResponse

   8.   sidebarsByRefRequest/sidebarsByRefResponse

   9.   sidebarByValRequest/sidebarByValResponse

   10.  sidebarByRefRequest/sidebarByRefResponse

   These CCMP request/response pairs use the blueprintsRequest and blueprintsResponse
                                 messages

7.2.3.2.  confsRequest and confsResponse messages

   A 'confsRequest' message is used fundamental CCMP operations
   as defined in Section 7 to retrieve, from manipulate the server, conference data.  Table 2
   summarizes the
   list of XCON-URIs associated with active CCMP operations and registered conferences A
   'confsRequest' message REQUIRES no additional parameters beyond those
   specified corresponding actions that are
   valid for the basic a specific CCMP request message.  The associated
   'confsResponse' message SHOULD contain type, noting that neither the list of XCON-URIs in the
   'confsInfo'
   blueprintsRequest/blueprintsResponse or confsRequest/ConfsResponse
   require an "operation" parameter.  The 'confObjId' parameter is NOT REQUIRED for
   this transaction.  A user, upon receipt of the corresponding response message, can
   interact with MUST
   contain the available conference objects through further CCMP
   messages.  The 'confsRequest' message is of a "retrieve-only" type,
   since same operation.  Note that some entries are labeled "N/A"
   indicating the sole purpose operation is to collect information available at invalid for that request type.  In the
   conference server.  Thus, an 'operation' parameter SHOULD NOT be
   included in a 'confsRequest' message.

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

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

   <!-- confsResponseType -->

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

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

    Figure 5: Structure
   case of the confsRequest and confsResponse messages

7.2.3.3.  blueprintRequest and blueprintResponse messages

   Through a 'blueprintRequest', a client can manipulate the conference
   object associated with a specified blueprint.  The request MUST
   include an 'operation' parameter and a 'confObjId' parameter.  Only "N/A*", the "retrieve" 'operation' SHOULD should be included in a
   'blueprintRequest message.  The 'create', 'update' and 'delete'
   operations SHOULD NOT operation MAY be included in a 'blueprintRequest' message
   except in the case of allowed for specific
   privileged users (e.g. the conference server
   administration staff).  The 'confObjId' parameter contains the XCON-
   URI of the blueprint, which might have been previously retrieved
   through a 'blueprintsRequest' message.

   In the case of responseCode or system administrators, but is not part of "success" for a 'retrieve' operation, the 'blueprintInfo' parameter SHOULD be
   functionality included in the
   'blueprintResponse' message.  Inside responses, the 'blueprintInfo'
   parameter carries the this document.

   +---------------+------------+------------+------------+------------+
   | Operation     |  Retrieve  |   Create   |   Update   |   Delete   |
   | ------------- |            |            |            |            |
   | -Request Type |            |            |            |            |
   +---------------+------------+------------+------------+------------+
   | blueprintsReq |  Get list  |     N/A    |     N/A    |     N/A    |
   | uest          |     of     |            |            |            |
   |               | blueprints |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | blueprintRequ |     Get    |    N/A*    |    N/A*    |    N/A*    |
   | est           |  blueprint |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | confsRequest  |  Get list  |     N/A    |     N/A    |     N/A    |
   |               |  of confs  |            |            |            |
   |               |  (active,  |            |            |            |
   |               |    etc.)   |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | confRequest   |    Gets    |   Creates  |   Changes  |   Deletes  |
   |               | conference | conference | conference | conference |
   |               |  object or |   object   |   object   |  Object as |
   |               |  blueprint |            |            |   a whole  |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | usersRequest  |    Gets    |     N/A    |   Changes  |     N/A    |
   |               |  specific  |            |  specified |            |
   |               |    users   |            |    users   |            |
   |               |   element  |            |   element  |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | userRequest   |    Gets    |   Adds a   |   Changes  |   Deletes  |
   |               |  specific  |  user to a |  specified |    user    |
   |               |    user    | conference |    user    | element as |
   |               |  element.  | .     *    |  element.  |  a whole.  |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarsByVal |    Gets    |     N/A    |     N/A    |     N/A    |
   | Request       | sidebars-b |            |            |            |
   |               | y   -val   |            |            |            |
   |               |    element |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarsByRef |    Gets    |     N/A    |     N/A    |     N/A    |
   | Request       | sidebars-b |            |            |            |
   |               | y   -ref   |            |            |            |
   |               |    element |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarByValR |   Gets a   |  Creates a |   Adds or  |  Removes/  |
   | equest        |   sidebar  | sidebar by | modifies a |   deletes  |
   |               |   element  |   cloning  |   sidebar  |   entire   |
   |               |            |  existing  |            |   sidebar  |
   |               |            |    conf    |            |            |
   |               |            |   object   |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarByRefR |   Gets a   |   Creates  |   Adds or  |  Removes/  |
   | equest        |   sidebar  | sidebar by |  modifies  |   deletes  |
   |               |   element  |   cloning  |   sidebar  |   entire   |
   |               |            |  existing  |            |   sidebar  |
   |               |            |    conf    |            |            |
   |               |            |   object   |            |            |
   +---------------+------------+------------+------------+------------+

            Table 2: Request Type Operation Specific Processing

   *: This operation can involve the creation of an XCON-UserID, if the
   sender does not add it in the 'confUserId' parameter, or if the
   'entity' field of the userInfo parameter is void.

   Additional parameters included in the specialized CCMP request/
   response messages are detailed in the subsequent sections.

7.2.3.1.  blueprintsRequest and blueprintsResponse messages

   A 'blueprintsRequest' (Figure 4) message is sent to request the list
   of XCON-URIs associated with the available blueprints from the
   conference server.  Such URIs can be subsequently used by the client
   to access detailed information about a specified blueprint with a
   specific 'blueprintRequest' message per Section 7.2.3.3.  A
   'blueprintsRequest' message REQUIRES no additional parameters beyond
   those specified for the basic CCMP request message.  The 'confObjId'
   and 'operation' parameters MUST NOT be included in the request or
   response for this transaction.

   The associated 'blueprintsResponse' message SHOULD contain, as shown
   in Figure 4, a 'blueprintsInfo' parameter containing the above
   mentioned XCON-URI list.  If the 'blueprintsInfo' parameter is empty,
   the conference control client MAY attempt to use a local default
   blueprint to create conferences.  However, the handling in this
   situation is specific to the conference control client
   implementation.

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

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

    <!-- blueprintsResponseType -->

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

   <xs:complexType name="blueprintsResponseType">
     <xs:sequence>
         <xs:element name="blueprintsInfo"
                     type="info:uris-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

    Figure 4: Structure of the blueprintsRequest and blueprintsResponse
                                 messages

7.2.3.2.  confsRequest and confsResponse messages

   A 'confsRequest' message is used to retrieve, from the server, the
   list of XCON-URIs associated with active and registered conferences A
   'confsRequest' message REQUIRES no additional parameters beyond those
   specified for the basic CCMP request message.  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.  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.

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

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

   <!-- confsResponseType -->

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

     <xs:complexType name="confsResponseType">
     <xs:sequence>
        <xs:element name="confsInfo"
                    type="info:uris-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>
    Figure 5: Structure of the confsRequest and confsResponse messages

7.2.3.3.  blueprintRequest and blueprintResponse messages

   Through a 'blueprintRequest', a client can manipulate the conference
   object associated with a specified blueprint.  The request MUST
   include an 'operation' parameter and a 'confObjId' parameter.  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 other than 'retrieve'.  The
   'create', 'update' and 'delete' operations SHOULD NOT be included in
   a 'blueprintRequest' message except in the case of privileged users
   (e.g. the conference server administration staff).

   In the case of responseCode of "success" for 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.

   If a response code of "objectNotFound" is received in a
   'blueprintResponse' message, it is RECOMMENDED that a conference
   control client attempt to retrieve another conference blueprint if
   more than one had been received in the "blueprintsResponse" message.
   If there was only one blueprint in the "blueprintsResponse"
   initially, then the client should send another "blueprintsRequest"
   message to determine if there may be new or additional blueprints for
   the specific conferencing system.  If this "blueprintsResponse"
   message contains no blueprints, the handling is specific to the
   conference control client.

   <!--  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:sequence>
   </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"/>
      </xs:sequence>
    </xs:complexType>

     Figure 6: Structure of the blueprintRequest and blueprintResponse
                                 messages

7.2.3.4.  confRequest and confResponse messages

   With a 'confRequest' message, CCMP clients can manipulate conference
   objects associated with either active or registered conferences
   (blueprints or reservations).  The request MUST include an
   'operation' parameter.  Depending upon the type of 'operation' a
   'confObjId' parameter MAY be included.  The 'confObjId' parameter
   contains the XCON-URI of the specific active or registered
   conference.  The requirements for inclusion of 'confInfo' parameter
   depends upon the specific 'operation' in the confRequest/confResponse
   and are detailed below.  The detailed information included in the
   'confInfo' parameter MUST follow the rules as specified in the XCON
   Data Model document [I-D.ietf-xcon-common-data-model].

   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 to be cloned, while the
       'confInfo' parameter MUST NOT be included in the confRequest;

   2.  Creation through implicit cloning (also known as "direct
       creation"): the 'confObjId' parameter MUST NOT be included in the
       request, whereas the 'confInfo' parameter describing the
       conference to be created MUST be included in the confRequest.

   In both cases, the confResponse, for a successful completion of a
   'create' operation, contains a responseCode of 'success' and MUST
   contain the XCON-URI of the created conference in the 'confObjID'
   parameter.  In addition, the 'confInfo' parameter transporting the
   created conference document MUST be included.  Obviously, the newly
   created object can be manipulated by the client through a subsequent
   'update' operation.  For example, after the creation and addition of
   the participants, the creator may want to lock the conference object.
   This can be accomplished with a confRequest with an operation of
   'update' by setting the 'locked' element in the confInfo included in
   the confRequest message described below.

   In the case of a confRequest with a 'retrieve' operation, the
   'confObjId' representing the XCON-URI of the target conference the
   conference control client MUST be included and the 'confInfo'
   parameter SHOULD NOT be included in the request.  The conferencing
   server MUST ignore any 'confInfo' parameter that is received in a
   'confRequest' and this 'confInfo' parameter MUST NOT be included in
   the confResponse.  If the confResponse for the 'retrieve' operation
   contains a responseCode of 'success', 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.

   In case of of a confRequest with an 'update' operation, the
   'confInfo' and 'confObjID' 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 is
   'confObjId'.  In the case of a confResponse with a responseCode of
   'success', no additional information is REQUIRED in the
   'confResponse' message.  A responseCode of 'success' indicates that
   the referenced conference document has not been changed by the
   conference server.  However, if the target conference object was not
   updated exactly as indicated by the client a responseCode of
   'modified' MUST be included in the 'confResponse' and the 'confInfo'
   parameter MUST contain the entire conference document to which any
   changes have been applied.  A responseCode of 'changeFailedProtected'
   indicates that the conferencing client is not allowed to make the
   changes reflected in the 'confInfo' 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.
   Thus, it is RECOMMENDED that the client continue using the previous
   version of the 'confInfo', if the conference was active.  If the
   conference was not active, it is RECOMMENDED that the client revert
   to an original version of the blueprint or use another blueprint -
   one previously retrieved with a blueprintRequest or one obtained via
   a new blueprintsRequest/blueprintRequest sequence.

   In the case of a confRequest with a 'delete' operation, the
   'confObjId' representing the XCON-URI of the target conference MUST
   be included and the 'confInfo' SHOULD NOT be included in the request.
   The conferencing server MUST ignore any 'confInfo' parameter that is
   received.  The confResponse MUST contain the same 'confObjId'that was
   included in the confRequest.  The confResponse MUST contain a
   responseCode of 'success' if the targeted conference is successfully
   deleted.  If the confResponse for the 'retrieve' operation contains a
   responseCode of 'success', the confResponse SHOULD NOT contain the
   'confInfo' parameter.  If the conferencing server cannot delete the
   conference referenced by the 'confObjId' received in the confRequest
   because it is the parent of another conference object that is in use,
   the conferencing server MUST return a responseCode of
   'deleteParentFailed'.

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

   <!-- 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:sequence>
   </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"/>
     </xs:sequence>
   </xs:complexType>

     Figure 7: Structure of the confRequest and confResponse messages

   The following provides an example of the 'confInfo' parameter
   required to change the title of a conference:

   <conf-info entity="123">
           <conference-description>
                   <display-text>New conference title</display-text>
           </conference-description>
   </conf-info>

     Figure 8: Updating a conference object: modifying the title of a
                                conference

   Similarly, to remove the title of an existing conference, an 'update'
   operation carrying the following 'confInfo' parameter would do the
   job.

   <conf-info entity="123">
           <conference-description>
                   <display-text/>
           </conference-description>
   </conf-info>

      Figure 9: Updating a conference object: removing the title of a
                                conference

7.2.3.5.  usersRequest and usersResponse messages

   Through a usersRequest message the CCMP client manipulates the
   <users> element of the conference document associated with the
   conference identified by the 'confObjId' parameter.  Inside the
   <users> element, along with the list of conference users, there is
   information that the client may be interested in controlling, such as
   the lists of users to which access to the conference is allowed/
   denied, conference participation policies, etc.; for this reason, a
   customized message has been designed to allow for the manipulation of
   this specific part of a conference document.

   A 'usersInfo' parameter MAY be included in a usersRequest message
   depending upon the operation.  If the 'userInfo' 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 SHOULD NOT include a
       'usersInfo' parameter, while a successful response MUST contain
       the desired <users> element in the 'usersInfo' parameter.  The
       conference server MUST be ignore a 'usersInfo' parameter if it is
       received in a request with a 'retrieve' operation.

   2.  update: In this case, the 'usersInfo' parameter MUST contain the
       modifications to be applied to the referred <users> element.  If
       the responseCode is 'success', then the 'usersInfo' parameter
       SHOULD NOT be returned.  Any 'usersInfo' parameter that is
       returned SHOULD be ignored.  If the responseCode is 'modified',
       the 'usersInfo' parameter MUST be included in the response.  The
       'usersInfo' reflects to the client the (partial) modifications
       that have been applied.  A responseCode of
       'changeFailedProtected' indicates that the conferencing client is
       not allowed to make the changes reflected in the 'usersInfo' in
       usersRequest message.  This could be due to policies, roles,
       specific privileges, etc.), with the reason specific to a
       conferencing system and its configuration.  Thus, it is
       RECOMMENDED that the client continue using the previous version
       of the 'usersInfo'.

   Operations of 'create' and 'delete' are not applicable to a
   usersRequest message and MUST NOT be considered by the server, which
   means that a responseCode of 'forbidden' 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:sequence>
   </xs:complexType>

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

   <!-- usersResponseType -->

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

   <xs:complexType name="usersResponseType">
     <xs:sequence>
        <xs:element name="usersInfo" type="info:users-type"/>
     </xs:sequence>
   </xs:complexType>

    Figure 10: Structure of the usersRequest and usersResponse messages

7.2.3.6.  userRequest and userResponse messages

   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', the
   'operation' parameter, and 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").

   We remark that 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 AAA checks), like creating a conference,
   retrieving conference information, etc..

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

   o  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 which 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 responseCode of 'success'.

   o  Conferencing client acts on behalf of a third 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 third user in question.  No
      additional parameters beyond those previously described are
      REQUIRED in the userResponse message, in the case of a
      responseCode of 'success'.

   o  A conferencing client 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.  The involved messages
      (userRequest and userResponse) in such case should look like the
      following:

   Request fields:

   confUserId=null;
   confObjId=confXYZ;
   operation=create;
   userInfo=

   <userInfo entity=null>
           <endpoint entity=''sip:GHIL345@blablabla''>
           ...

   Response fields (in case of success):

   confUserId=user345;
   confObjId=confXYZ;
   operation=create;
   response-code=success;
   userInfo=null; //or the entire userInfo object

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

   o  Conferencing client is unaware of the XCON-USERID of a third user:
      In this case, the 'entity' attribute MUST NOT be included in the
      request.  The XCON-USERID generated by the conference server for
      such a user MUST also be returned to the client as the value of
      the 'entity' attribute in the 'userInfo' parameter of the response
      if the responseCode is "success".  This scenario is mainly
      intended to support the case whereby an XCON aware client is added
      to a conference by a third party, e.g. the chairperson of the
      conference.

   o  Conferencing client obtains a new user profile in the context of a
      conference: this case is handled in the same manner as the
      previous case associated with the creation of a user on behalf of
      a third party when the XCON-USERID is unknown, thus indicating to
      the conference server that the client wants a new XCON-USERID and
      associated 'userInfo' parameter to be allocated and populated
      respectively.

   In both cases, the confResponse, for a successful completion of a
   'create' operation, contains a responseCode of 'success' and MUST
   contain the XCON-URI of the created conference in the 'confObjID'
   parameter.  In addition, the 'confInfo' parameter transporting the
   created conference document MUST be included.  Obviously, the newly
   created object can be manipulated by the client through a subsequent
   'update' operation.

   In the case of a userRequest with a 'retrieve' operation, the
   'confObjId' representing the XCON-URI of the target conference MUST
   be included.  The 'confUserId' MUST be included in the userRequest
   message.  This 'confUserId' indicates the specific <user> element in
   XCON data model, as reflected by the 'entity' attribute in the <user>
   element that the conference client is requesting to retrive.  The
   'userInfo' parameter SHOULD NOT be included in the request.  The
   conferencing server MUST ignore any 'userInfo' parameter that is
   received in a 'userRequest' and this 'userInfo' parameter MUST NOT be
   included in the userResponse.  If the userResponse for the 'retrieve'
   operation contains a responseCode of 'success', the 'userInfo'
   parameter MUST be included in the response.

   In case of of a userRequest with an 'update' operation, the
   'confObjID', 'confUserID' and 'userInfo' MUST be included in the
   request.  The 'userInfo' 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' in the userRequest message.  The
   'entity' attribute in the 'userInfo' MUST be equal to the
   'confUserID' in the userRequest message.  In the case of a user
   Response with a responseCode of 'success', no additional information
   is REQUIRED in the 'confResponse' message.  A responseCode of
   'success' indicates that the referenced user element has been updated
   by the conference server.  However, if the specific <user> element
   was not updated exactly as indicated by the client a responseCode of
   'modified' MUST be included in the 'confResponse' and the 'userInfo'
   parameter MUST contain the entire <user> element which to which the
   conference server has applied changes.  A responseCode of
   'changeFailedProtected' 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.  Thus, it is RECOMMENDED that the client
   continue using the previous version of the 'userInfo'.

   In the case of a userRequest with a 'delete' operation, the
   'confObjId' representing the XCON-URI of the target conference and
   the 'confUserID' associated with the specific <user> element (i.e.,
   matching the 'entity' attribute) that the conferencing client is
   requesting be deleted MUST be included in the userRequest message.
   The 'userInfo' SHOULD NOT be included in the request.  The
   conferencing server MUST ignore any 'userInfo' parameter that is
   received.  The userResponse MUST contain the same 'confObjId' that
   was included in the userRequest.  The userResponse MUST contain a
   responseCode of 'success' if the <user> element associated with the
   specific 'confUserId' is successfully deleted.  If the userResponse
   for the 'retrieve' operation contains a responseCode of 'success',
   the userResponse SHOULD NOT contain the 'userInfo' parameter.

   <!-- 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:sequence>
   </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"/>
     </xs:sequence>
   </xs:complexType>

     Figure 12: Structure of the userRequest and userResponse messages

7.2.3.7.  sidebarsByValRequest and sidebarsByValResponse messages

   A "sidebarsByValRequest" is used to execute a retrieve-only operation
   on the <sidebars-by-val> field of the conference object represented
   by the 'confObjId'.  The request MUST include an 'operation' of
   "retrieve" and a 'confObjId' parameter.  Operations of 'create',
   'update' and 'delete' MUST NOT be included in a sidebarsByValRequest
   message.  A "sidebarsByValResponse" with a responseCode of 'success'
   MUST contain a 'sidebarsByValInfo' parameter containing the desired
   <sidebars-by-val> element.  The 'sidebarsByValInfo' parameter
   contains the identifiers of the sidebars derived from the main
   conference in the form of XCON-URIs.  The retrieved sidebars can then
   be updated or deleted using the "sidebarByValRequest" message, which
   is described in Section 7.2.3.8.

   <!-- sidebarsByValRequest -->

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

   <!-- sidebarsByValRequestType -->

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

   <xs:complexType name="sidebarsByValRequestType">
     <xs:sequence>
        <xs:element name="sidebarsByValInfo"
                    type="info:sidebars-by-val-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

   <!-- sidebarsByValResponse -->

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

   <!-- sidebarsByValResponseType -->

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

   <xs:complexType name="sidebarsByValResponseType">
     <xs:sequence>
        <xs:element name="sidebarsByValInfo"
                    type="info:sidebars-by-val-type"/>
     </xs:sequence>
   </xs:complexType>
           Figure 13: Structure of the sidebarsByValRequest and
                      sidebarsByValResponse messages

7.2.3.8.  sidebarByValRequest and sidebarByValResponse messages

   A sidebarByValRequest message MUST contain the 'operation' parameter
   which discriminates 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 is to be created.  The 'sidebarByValInfo' parameter
   SHOULD NOT be included in the request, since, as envisaged in the
   XCON framework ([RFC5239]), sidebars are always created by cloning
   the main conference.  Any 'sidebarByValInfo' included in the request
   MUST be ignored.  The conference server sets the 'active' element to
   'false' of the cloned conference to reflect that it is a "reserved"
   conference.  The conference server MUST update the conference object
   reflected by the 'confObjID' parameter, in the sidebarbyVal request
   message, from which the sidebar was created to reflect the newly
   created sidebar.  The newly created conference object MUST be
   included in the response in the 'sidebarByValInfo' parameter, if the
   responseCode is 'success'.  The URI for the conference object
   associated with the newly created sidebar object MUST appear in the
   'entity' attribute in the 'sidebarByValInfo'.  The conference server
   can notify any conferencing clients that have subscribed to the
   conference event package, and are authorized to receive the
   notifications, of the addition of the sidebar to the conference.

   In the case of a 'sidebarByVal' request with an operation of
   'retrieve', the URI for the conference object created for the
   sidebar, as reflected by the 'entity' attribute in the
   'sidebarByValInfo', received in the 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 document associated server in the same manner as a 'retrieve'
   operation included in a confRequest message as detailed in
   Section 7.2.3.4.

   In the case of a 'sidebarByVal' request with an operation of
   'update', the
   blueprint specified 'sidebarByValInfo' MUST also be included in the
   request.  The 'entity' attribute in the 'sidebarByValInfo' identifies
   the specific sidebar instance to be updated.  The URI for the
   conference object containing the specific sidebar-by-value element to
   be updated MUST be included in the 'confObjID' parameter in the
   request.  An 'update' operation on the 'sidebarByValInfo' 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 7.2.3.4.

   If an 'operation' of 'delete' is included in the sidebarByVal
   request, the 'sidebarByValInfo' parameter SHOULD NOT be included in
   the request.  Any 'sidebarByValInfo' included in the request SHOULD
   be ignored by the conference server.  The URI for the conference
   object for the sidebar, as reflected by the 'entity' attribute in the
   'sidebarByValInfo', received in the response to a 'create' operation
   or in a sidebarsByValResponse message, MUST be included in the
   'confObjID' parameter in the request.  If the specific conferencing
   user as reflected by the 'confUserID' 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 request. 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 are authorized to
   receive the notifications, of the deletion of the sidebar to the
   conference.

   <!--  blueprintRequest sidebarByValRequest -->

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

   <!-- blueprintRequestType sidebarByValRequestType -->

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

   <xs:complexType name="blueprintRequestType"> name="sidebarByValRequestType">
    <xs:sequence>
      <xs:element name="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="blueprintInfo" name="sidebarByValInfo"
                    type="info:conference-type" minOccurs="0"/>
    </xs:sequence>
   </xs:complexType>

   <!-- blueprintResponse sidebarByValResponse -->

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

   <!-- blueprintResponseType sidebarByValResponseType -->

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

   <xs:complexType name="blueprintResponseType"> name="sidebarByValResponseType">
     <xs:sequence>
        <xs:element name="blueprintInfo" name="sidebarByValInfo"
                    type="info:conference-type"/>
     </xs:sequence>
   </xs:complexType>
            Figure 6: 14: Structure of the blueprintRequest sidebarByValRequest and blueprintResponse
                       sidebarByValResponse messages

7.2.3.4.  confRequest

7.2.3.9.  sidebarsByRefRequest and confResponse sidebarsByRefResponse messages

   With a 'confRequest' message, CCMP clients can manipulate conference
   objects associated with either active or registered conferences
   (blueprints or reservations).  The request MUST include an
   'operation' parameter.  Depending upon the type of 'operation' a
   'confObjId' parameter and/or 'confInfo' parameter MAY be included.
   The 'confObjId' parameter contains the XCON-URI of the specific
   active or registered conference.  The 'confInfo' parameter contains
   the conference data that is the target of the 'confRequest' - i.e.
   the <conference-info> document (compliant with the XCON data model
   structure).

   To create a new conference through a 'confRequest' message, two
   approaches can be embraced:

   1.  Creation through explicit cloning: the 'confObjId' parameter MUST
       contain the XCON-URI of the blueprint to be cloned, while the
       'confInfo' parameter SHOULD NOT be included in the request;

   2.  Creation through implicit cloning (also known as "direct
       creation"): the 'confObjId' parameter SHOULD NOT be included in
       the request, whereas the 'confInfo' parameter describing the
       conference

   Similar to be created MUST be included in the request.

   In both cases, a successful completion of the request carries back a
   responseCode of 'success' and SHOULD contain, in the 'confObjId'
   parameter, the XCON-URI of the created conference.  In addition, the
   'confInfo' parameter transporting the created conference document
   SHOULD be included.  Obviously, the newly created object the sidebarsByValRequest, a sidebarsByRefRequest can be
   manipulated by the client through subsequent 'update' operations.

   In
   invoked to retrieve the case <sidebars-by-ref> element of 'retrieve' or 'delete' operations, the conference
   object identified by the 'confObjId'
   representing parameter.  The 'confObjID'
   parameter MUST be included in the XCON-URI request.  An operation of the target conference
   'retrieve' MUST also be included
   and in the 'confInfo' SHOULD request.  Operations of
   'create', 'update' and 'delete' MUST NOT be included in the request.  Inside the
   response to a 'retrieve' request, in
   sidebarsByValRequest message.  In the case of a responseCode of
   'success', the 'confInfo' 'sidebarsByRefInfo' parameter, containing a description of the target
   conference object MUST be included.  On the other hand, a response to
   a 'delete' operation SHOULD NOT include the 'confInfo' parameter.

   In case
   <sidebars-by-ref> element of an 'update' operation, the 'confInfo' and 'confObjID conference object, MUST be included
   in the request. response.  The 'confInfo' <sidebars-by-ref> element represents an object the set of
   URIs of
   type "conference-type" containing all the changes to be applied to sidebars associated with the conference main conference, whose identifier is 'confObjId'.  In
   description (in the case of a
   responseCode form of success, no additional information is REQUIRED in the
   'confResponse'message.  For a successful response, the conference
   server should consider as unchanged all parts of the referenced
   conference document.  However, if the target standard XCON conference object has
   not been modified exactly as required by the client the responsecode
   MUST be set document) is
   external to 'modified' and the 'confInfo' parameter MUST contain the entire main conference document to which the required changes have
   been (at least partially) applied.

   The schema for itself.  Through the confRequest/confResponse pair retrieved URIs,
   it is shown then possible to access single sidebars using the
   "sidebarByRef" request message, described in
   Figure 7. Section 7.2.3.10.

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

   <!-- confRequestType sidebarsByRefRequestType -->

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

   <xs:complexType name="confRequestType">
     <xs:sequence>
        <xs:element name="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" /> name="sidebarsByRefRequestType">
     <xs:sequence>
        <xs:element name="confInfo"
                    type="info:conference-type" name="sidebarsByRefInfo"
                    type="info:uris-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

   <!-- confResponse sidebarsByRefResponse -->

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

   <!-- confResponseType sidebarsByRefResponseType -->

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

   <xs:complexType name="confResponseType"> name="sidebarsByRefResponseType">
     <xs:sequence>
        <xs:element name="confInfo" type="info:conference-type"/> name="sidebarsByRefInfo"
                    type="info:uris-type"/>
     </xs:sequence>
   </xs:complexType>
           Figure 7: 15: Structure of the confRequest sidebarsByRefRequest and confResponse
                      sidebarsByRefResponse messages

7.2.3.10.  sidebarByRefRequest and sidebarByRefResponse messages

   A sidebarByRefRequest message MUST contain the 'operation' parameter
   which discriminates among retrieval, creation, modification and
   deletion of a specific sidebar.  The following provides other required parameters depend
   upon the type of operation.

   In the case of an example 'operation of 'create', the 'confInfo' 'confObjId' parameter
   required
   representing the XCON-URI of the conference from which the sidebar is
   to change be created (cloned) MUST be included in all sidebarByRefRequest
   messages.  The'sidebarByRefInfo' parameter SHOULD NOT be included in
   the title request, since, as envisaged in the XCON framework ([RFC5239]),
   sidebars are always created by cloning the main conference.  Any
   'sidebarByRefInfo' included in the request MUST be ignored.  If the
   creation of a conference:

   <conf-info entity="123">
           <conference-description>
                   <display-text>New the sidebar is successful, the conference title</display-text>
           </conference-description>
   </conf-info>

     Figure 8: Updating a server MUST
   update the 'sidebars-by-ref' element in the conference object: modifying object from
   which the title of a sidebar was created (i.e., as identified by the 'confObjID'
   in the original sidebarByRef request), with the URI for the newly
   created sidebar.  The newly created conference

   Similarly, to remove object MUST be
   included in the title of an existing conference, an 'update'
   operation carrying response in the following 'confInfo' 'sidebarByRefInfo' parameter would do the
   job.

   <conf-info entity="123">
           <conference-description>
                   <display-text/>
           </conference-description>
   </conf-info>

      Figure 9: Updating with a
   responseCode 'success'.  The URI for the conference object: removing object associated
   with the newly created sidebar object MUST appear in the 'entity'
   attribute in the 'sidebarByRefInfo'.  The conference server can
   notify any conferencing clients that have subscribed to the title of a
   conference

7.2.3.5.  usersRequest event package, and usersResponse messages

   Through a usersRequest message the CCMP client manipulates are authorized to receive the
   <users> element
   notifications, of the conference document associated with addition of the
   conference identified by sidebar to the 'confObjId' parameter.  Inside conference.

   In the
   <users> element, along case of a 'sidebarByRef' request with the list an operation of
   'retrieve', the URI for the conference users, there is
   information that object created for the client may sidebar
   MUST be interested included in controlling, such as the lists 'confObjID' parameter in the request.  The
   'sidebarByRefInfo' MUST also be included in the request in the case
   of users to which access to an 'operation' of 'update'.  An 'update' operation on the conference
   'sidebarByRefInfo' is allowed/
   denied, handled by the conference participation policies, etc.; for this reason, server in the same
   manner as a
   customized 'retrieve' operation on the confInfo included in a
   confRequest message has been designed to allow for as detailed in Section 7.2.3.4.

   In the manipulation of
   this specific part case of a 'sidebarByRef' request with an operation of
   'update', the URI for the conference document.  Besides object created for the usual
   'operation' parameter, a 'usersInfo' sidebar
   MUST be included in the 'confObjID' parameter MAY in the request.  The
   'sidebarByRefInfo' MUST also be included
   depending upon in the operation.  The 'usersInfo' parameter carries an
   object compliant with request in the <users> field case
   of the XCON data model. an 'operation' of 'update'.  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 7.2.3.4.

   If an 'operation' of 'delete' is included in the sidebarByRef
   request, the 'sidebarByRefInfo' parameter MUST SHOULD NOT be included in a "usersRequest"
   message.  Two operations are allowed in a "usersRequest" message:

   1.  retrieve: In this case
   the request.  Any 'sidebarByRefInfo' included in the request SHOULD NOT include a
       'usersInfo' parameter, while a successful response MUST contain
   be ignored by the desired <users> element in conference server.  The URI for the 'usersInfo' parameter.

   2.  update: In this case, conference
   object for the 'usersInfo' parameter sidebar MUST contain the
       modifications to be applied to included in the referred <users> element. 'confObjID' parameter
   in the request.  If the responseCode specific conferencing user as reflected by
   the 'confUserID' in the request is 'success', then authorized to delete the 'usersInfo' parameter
   conference, the conference server SHOULD NOT be returned.  If delete the responseCode is 'modified', conference object
   reflected by the
       'usersInfo' 'confObjID' parameter MUST be included in and SHOULD update the response.  The
       'usersInfo' reflects to
   'sidebars-by-ref' element in the client conference object from which the (partial) modifications
   sidebar was originally cloned.  The conference server can notify any
   conferencing clients that have been applied.

   Operations of 'create' subscribed to the conference event
   package, and 'delete' make little sense in are authorized to receive the case notifications, of
   a usersRequest and SHOULD NOT be considered by the server, which
   means that a responseCode
   deletion of 'forbidden' SHOULD be included in the
   usersResponse message. sidebar.

   <!-- usersRequest sidebarByRefRequest -->

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

   <!-- usersRequestType sidebarByRefRequestType -->

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

   <xs:complexType name="usersRequestType"> name="sidebarByRefRequestType">
   <xs:sequence>
        <xs:element name="operation" type="operationType"
                           minOccurs="1" maxOccurs="1" />
                   <xs:element name="usersInfo"
                   type="info:users-type" minOccurs="0" /> name="sidebarByRefInfo"
                    type="info:conference-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

   <!-- usersResponse sidebarByRefResponse -->

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

   <!-- usersResponseType sidebarByRefResponseType -->

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

   <xs:complexType name="usersResponseType"> name="sidebarByRefResponseType">
     <xs:sequence>
        <xs:element name="usersInfo" type="info:users-type"/> name="sidebarByRefInfo"
                    type="info:conference-type"/>
     </xs:sequence>
   </xs:complexType>
            Figure 10: 16: Structure of the usersRequest and usersResponse messages

7.2.3.6.  userRequest and userResponse messages

   A "userRequest" message sidebarByRefRequest and
                       sidebarByRefResponse messages

8.  A complete example of the CCMP in action

   [spromano-09] This section has to be updated, since we added the
   'operation' parameter in response messages.  Hence, we first have to
   update the schema file; then, we have to change the excrpts in this
   section.

   In this section a typical scenario in which the CCMP comes into play
   is described, by showing the actual composition of the various CCMP
   messages.  In the call flows of the example, the Conference Control
   Client is used to manipulate <user> elements inside a conference document associated with CCMP-enabled client, whereas the Conference Control
   Server is a conference identified by CCMP-enabled server.  The 'confUserId' of the
   'confObjId' parameter.  Besides retrieving client is
   "Alice" and appears in all requests.  The sequence of operations is
   as follows:

   1.  Alice retrieves from the server the list of available blueprints
       (Section 8.1);

   2.  Alice asks for detailed information about a specific conference user, the message MAY be used blueprint
       (Section 8.2);

   3.  Alice decides to either create,
   or modify, or delete information about create a user.  A "userRequest" MUST
   include new conference by cloning the 'operation' parameter, and MAY include a 'userInfo'
   parameter containing retrieved
       blueprint (Section 8.3);

   4.  Alice modifies information (e.g.  XCON-URI, name, description)
       associated with the detailed user's information.

   Conference users can be newly created in blueprint (Section 8.4);

   5.  Alice specifies a number list of different ways.  Let
   us first consider users to be contacted when the case of
       conference is activated (Section 8.5);

   6.  Alice joins the conference (Section 8.6);

   7.  Alice lets a new user who wants to enter a (whose 'confUserId' is "Ciccio") join the
       conference
   (i.e. to add himself to (Section 8.7).

   Note, the examples do not include any details beyond the conference). basic
   operation.

   In such a case, the
   'userInfo' parameter in following sections we deal with each of the above mentioned
   actions separately.

8.1.  Alice retrieves the request (which MUST have an 'operation'
   value set to "create") SHOULD contain a <user> element (compliant available blueprints

   This section illustrates the transaction associated with retrieval of
   the XCON data model) having its 'entity' attribute set to blueprints, together with a
   value which represents the XCON-USERID dump of the user in question.

   A different situation is one in which two messages exchanged
   ("blueprintsRequest" and "blueprintsResponse").  As it comes out from
   the CCMP client acts on behalf
   of a third user, whose XCON-USERID is known.  In this case, figure, the
   <user> element SHOULD contain an 'entity' attribute whose value is
   set to "blueprintsResponse" message contains, in the XCON-USERID of
   'blueprintsInfo' parameter, information about the user available
   blueprints, in question.  As a final case, if the CCMP client is not aware form of the XCON-USERID standard XCON-URI of the user to be
   inserted, blueprint,
   plus additional (and optional) information, like its display-text and
   purpose.

   Alice retrieves from the key attribute (i.e. 'entity') SHOULD NOT be included in server the list of available blueprints:

     CCMP Client                                             CCMP Server
          |                                                       |
          | CCMP blueprintsRequest message                        |
          |   - confUserID: Alice                                 |
          |   - confObjId: (null)                                 |
          |------------------------------------------------------>|
          |                                                       |
          |                     CMP blueprintsResponse message    |
          |                      - confUserID: Alice              |
          |                      - confObjId: (null)              |
          |                      - responseCode: success          |
          |                      - blueprintsInfo: bp123,bp124,.. |
          |<------------------------------------------------------|
          |                                                       |
          .                                                       .
          .                                                       .

   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="xcon:ccmp-blueprints-request-message-type">
       <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
    </ccmpRequest>
   </ccmp:ccmpRequest>

   2. blueprintsResponse message form 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@meetecho.com</confUserID>
       <ccmp:response-code>success</ccmp:response-code>
        <ccmp:blueprintsResponse>
         <blueprintsInfo>
          <info:entry>
           <info:uri>xcon:AudioRoom@meetecho.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 request: same time
              and the XCON-USERID generated by requests for the AudioFloor
              are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:VideoRoom@meetecho.com</info:uri>
           <info:display-text>VideoRoom</info:display-text>
           <info:purpose>Video Room:
               conference server for
   such a user MUST room with public access,
               where both audio and video are available,
               8 users can talk and be returned to the client as the value of the
   'entity' attribute in the 'userInfo' parameter of seen at the response if same time,
               and the
   responseCode floor requests are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:AudioConference1@meetecho.com</info:uri>
           <info:display-text>AudioConference1</info:display-text>
           <info:purpose>Public Audio Conference:
                conference with public access,
                where only audio is "success".  The last case also applies to a CCMP
   client that obtains a new available,
                only one user profile in the context of a
   conference.

   <!-- 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="operation" type="operationType"
                           minOccurs="1" maxOccurs="1" />
                   <xs:element name="userInfo"
                   type="info:user-type" minOccurs="0" />
           </xs:sequence>
   </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"/>
     </xs:sequence>
   </xs:complexType>
     Figure 11: Structure of can talk at the userRequest same time,
                and userResponse messages

7.2.3.7.  sidebarsByValRequest the requests for the AudioFloor MUST
                be accepted by a Chair.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:VideoConference1@meetecho.com</info:uri>
           <info:display-text>VideoConference1</info:display-text>
             <info:purpose>Public Video Conference: conference
                 where both audio and sidebarsByValResponse messages

   A "sidebarsByValRequest" video are available,
                 only one user can talk
             </info:purpose>
           </info:entry>
           <info:entry>
            <info:uri>xcon:AudioConference2@meetecho.com</info:uri>
            <info:display-text>AudioConference2</info:display-text>
            <info:purpose>Basic Audio Conference:

                 conference with private access,
                 where only audio is used to execute a retrieve-only operation
   on available,
                 only one user can talk at the <sidebars-by-val> field of same time,
                 and the conference object represented
   by requests for the 'confObjId'.  The request AudioFloor MUST include an 'operation' of
   "retrieve" and
                 be accepted by a 'confObjId'.  A "sidebarsByValResponse" MUST contain Chair.
            </info:purpose>
           </info:entry>
        </blueprintsInfo>
      </ccmp:blueprintsResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

               Figure 17: Getting blueprints from the server

8.2.  Alice gets detailed information about a 'sidebarsByValInfo' parameter reporting specific blueprint

   This section illustrates the desired <sidebars-by-
   val> element.  The 'sidebarsByValInfo' parameter contains second transaction in the
   identifiers overall flow.
   In this case, Alice, who now knows the XCON-URIs of the sidebars derived from blueprints
   available at the main conference.  For server, makes a drill-down query, in the creation and manipulation form of sidebars, a different message has
   been envisaged, namely "sidebarByValRequest", which is described in
   Section 7.2.3.8

   <!-- sidebarsByValRequest -->

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

   <!-- sidebarsByValRequestType -->

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

   <xs:complexType name="sidebarsByValRequestType">
     <xs:sequence>
        <xs:element name="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="sidebarsByValInfo"
                    type="info:sidebars-by-val-type" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

   <!-- sidebarsByValResponse -->

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

   <!-- sidebarsByValResponseType -->

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

   <xs:complexType name="sidebarsByValResponseType">
     <xs:sequence>
        <xs:element name="sidebarsByValInfo"
                    type="info:sidebars-by-val-type"/>
     </xs:sequence>
   </xs:complexType>

           Figure 12: Structure
   CCMP "blueprintRequest" message, to get detailed information about
   one of them (the one called with XCON-URI
   "xcon:AudioRoom@meetecho.com").  The picture shows such transaction.
   Notice that the sidebarsByValRequest and
                      sidebarsByValResponse messages

7.2.3.8.  sidebarByValRequest and sidebarByValResponse messages

   A "sidebarByValRequest" response contains, in the 'blueprintInfo' parameter,
   a document compliant with the standard XCON data model.

   Alice retrieves detailed information about a specified blueprint:

     CCMP Client                                             CCMP Server
          |                                                       |
          | CCMP blueprintRequest message                         |
          |   - confUserID: Alice                                 |
          |   - confObjId: bp123                                  |
          |   - operation: retrieve                               |
          |   - blueprintInfo: (null)                             |
          |------------------------------------------------------>|
          |                                                       |
          |                        CCMP blueprintResponse message MUST contain |
          |                          - confUserID: Alice          |
          |                          - confObjId: bp123           |
          |                          - operation: retrieve        |
          |                          - responseCode: success      |
          |                          - 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">
           <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
           <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
           <operation>retrieve</operation>
           <ccmp:blueprintRequest/>
     </ccmpRequest>
   </ccmp:ccmpRequest>

   2. blueprintResponse message form the 'operation'
   parameter which discriminates among creation, modification and
   deletion of 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">
       <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
       <operation>retrieve</operation>
       <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
       <ccmp:response-code>success</ccmp:response-code>
       <ccmp:blueprintResponse>
         <blueprintInfo entity="xcon:AudioRoom@meetecho.com">
           <info:conference-description>
              <info:display-text>AudioRoom</info:display-text>
              <info:maximum-user-count>2</info:maximum-user-count>
              <info:available-media>
                <info:entry label="audioLabel">
                    <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="audioLabel"></xcon:floor>
             </xcon:conference-floor-policy>
           </xcon:floor-information>
         </blueprintInfo>
       </ccmp:blueprintResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

            Figure 18: Getting info about a specific sidebar.  The 'sidebarByValInfo' parameter, in
   turn, contains the description (in an XCON data model compliant
   fashion) of the sidebar itself.  The 'confObjId' parameter of such
   messages MUST contain blueprint

8.3.  Alice creates a new conference through a cloning operation

   This section illustrates the XCON-URI of third transaction in the main overall flow.
   Alice decides to create a new conference which by cloning the
   sidebar belongs to.  The blueprint
   having XCON-URI of "xcon:AudioRoom@meetecho.com", for which she just
   retrieved detailed information through the sidebar "blueprintRequest"
   message.  This is contained in achieved by sending a "confRequest/create" message
   having the
   'entity' attribute of blueprint's URI in the above mentioned 'sidebarByValInfo'
   document.  In case of creation, 'confObjId' parameter.  The picture
   shows such transaction.  Notice that the 'sidebarByValInfo' SHOULD NOT be
   included response contains, in the request, since, as envisaged in
   'confInfo' parameter, the XCON framework
   ([RFC5239]), sidebars are always document associated with the newly created by cloning
   conference, which is compliant with the main
   conference. standard XCON data model.
   The 'sidebarByValInfo' parameter MUST be included 'confObjId' in a
   successful response.  The 'sidebarByValInfo' represents the created
   sidebar, whose URI appears in response is set to the 'entity' attribute.

   <!-- 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="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
      <xs:element name="sidebarByValInfo"
                    type="info:conference-type" minOccurs="0"/>
    </xs:sequence>
   </xs:complexType>

   <!-- sidebarByValResponse -->

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

   <!-- sidebarByValResponseType -->

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

   <xs:complexType name="sidebarByValResponseType">
     <xs:sequence>
        <xs:element name="sidebarByValInfo"
                    type="info:conference-type"/>
     </xs:sequence>
   </xs:complexType>
            Figure 13: Structure XCON-URI of the sidebarByValRequest and
                       sidebarByValResponse messages

7.2.3.9.  sidebarsByRefRequest and sidebarsByRefResponse messages

   Similar new
   conference (in this case, "xcon:8977794@meetecho.com").  We also
   notice that this value is equal to the "sidebarsByValRequest", a "sidebarsByRefRequest" can
   be invoked to retrieve value of the <sidebars-by-ref> "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@meetecho.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     |
         |                               - responseCode: success |
         |                               - 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">
        <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
        <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
        <operation>create</operation>
        <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">
       <confObjID>xcon:8977794@meetecho.com</confObjID>
       <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
           <operation>create</operation>
       <ccmp:response-code>success</ccmp:response-code>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@meetecho.com">
              <info:conference-description>
                  <info:display-text>
                     New conference object identified by the 'confObjId' parameter.  The
   'confObjID' parameter MUST be included in the request.  An operation
   of 'retrieve' MUST also be included in the request.  In the case of a
   responseCode of success, the 'sidebarsByRefInfo' parameter,
   containing the <sidebars-by-ref> element of the Alice cloned from AudioRoom
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@meetecho.com
                        </info:uri>
                        <info:display-text>
                            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 xcon-uri
                        </info:display-text>
                        <xcon:conference-password>
                            8601
                        </xcon:conference-password>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <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:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

        Figure 19: Creating a standard XCON
   conference document) is external to the main new conference itself.
   Through the retrieved URIs, it is then possible to access single
   sidebars by exploiting the ad-hoc defined "sidebarByRef" request,
   described in Section 7.2.3.10.

   <!-- 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="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="sidebarsByRefInfo"
                    type="info:uris-type" minOccurs="0"/>
     </xs:sequence>
   </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"/>
     </xs:sequence>
   </xs:complexType>

           Figure 14: Structure cloning a blueprint

8.4.  Alice updates conference information

   This section illustrates the fourth transaction in the overall flow.
   Alice decides to modify some of the sidebarsByRefRequest and
                      sidebarsByRefResponse messages

7.2.3.10.  sidebarByRefRequest and sidebarByRefResponse messages

   A "sidebarByRefRequest" message along details associated with the REQUIRED 'operation'
   parameter, MAY contain a 'sidebarByRefInfo' parameter describing the
   conference object (compliant with she just created.  More precisely, she changes the XCON data model) associated
   with
   <display-text> element under the sidebar.  In case <conference-description> element of 'retrieve', 'delete', 'update' and
   'create' operations,
   the 'confObjId' parameter document representing the XCON-
   URI of the target sidebar MUST be included.  The 'sidebarByRefInfo'
   parameter conference.  This is NOT REQUIRED in the first two cases ('retrieve' and
   'delete'), whereas in achieved through a
   "confRequest/update" message carrying the case fragment of an 'update' the 'sidebarByRefInfo'
   parameter MUST contain conference
   document to which the required changes have to be applied to the referenced
   sidebar.  The 'sidebarByRefInfo' MUST NOT be included for a 'create'
   operation since, as already stated, sidebar creation is by default
   achieved by cloning the main conference.

   <!-- 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="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="sidebarByRefInfo"
                    type="info:conference-type" minOccurs="0"/>
     </xs:sequence>
   </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"/>
     </xs:sequence>
   </xs:complexType>
            Figure 15: Structure of the sidebarByRefRequest and
                       sidebarByRefResponse messages

8.  A complete example of the CCMP in action

   In this section a typical scenario applied.  As shown
   in which the CCMP comes into play
   is described, by showing the actual composition of the various CCMP
   messages.  In picture, the call flows response contains a code of 'success', which
   acknowledges the example, modifications requested by the Conference Control
   Client is a CCMP-enabled client, whereas client.

   Alice updates information about the Conference Control conference she just created:

     CCMP Client                                             CCMP Server is
          |                                                       |
          | CCMP confRequest message                              |
          |   - confUserID: Alice                                 |
          |   - confObjId: 897779                                 |
          |   - operation: update                                 |
          |   - confInfo: conf456Updates                          |
          |------------------------------------------------------>|
          |                                                       |
          |                             CCMP confResponse message |
          |                               - confUserID: Alice     |
          |                               - confObjId: 8977794    |
          |                               - operation: update     |
          |                               - responseCode: success |
          |                               - 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">
       <confObjID>xcon:8977794@meetecho.com</confObjID>
       <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
       <operation>update</operation>
       <ccmp:confRequest>
            <confInfo entity="xcon:8977794@meetecho.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 form 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">
        <confObjID>xcon:8977794@meetecho.com</confObjID>
        <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
            <operation>update</operation>
        <ccmp:response-code>success</ccmp:response-code>
        <ccmp:confResponse/>
     </ccmpResponse>
   </ccmp:ccmpResponse>

                Figure 20: Updating conference information

8.5.  Alice inserts a CCMP-enabled server.  The 'confUserId' list of users in the client is
   "Alice" and appears conference object

   This section illustrates the fifth transaction in all requests.  The sequence of operations is
   as follows:

   1. the overall flow.
   Alice retrieves from modifies the server <allowed-users-list> under the <users> element in
   the document associated with the list of available blueprints
       (Section 8.1);

   2.  Alice asks for detailed information about a specific blueprint
       (Section 8.2);

   3.  Alice decides to create a new conference she created.  To the
   purpose, she exploits the "usersRequest" message provided by cloning the retrieved
       blueprint (Section 8.3);

   4.
   CCMP.  The picture below shows the transaction.

   Alice modifies updates information (e.g.  XCON-URI, name, description)
       associated with about the newly created blueprint (Section 8.4);

   5.  Alice specifies a list of users to be contacted when whom access to
   the conference is activated (Section 8.5);

   6. permitted:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP usersRequest message                             |
        |   - confUserID: Alice joins the conference (Section 8.6);

   7.                                 |
        |   - confObjId: 8977794                                |
        |   - operation: update                                 |
        |   - usersInfo: usersUpdates                           |
        |------------------------------------------------------>|
        |                                                       |
        |                            CCMP usersResponse message |
        |                              - confUserID: Alice lets a new user (whose 'confUserId' is "Ciccio") join the
       conference (Section 8.7).

   Note, the examples do not include any details beyond      |
        |                              - confObjId: 8977794     |
        |                              - operation: update      |
        |                              - responseCode: success  |
        |                              - 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">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
         <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:+390817683823"/>
                     <xcon:target method="refer"
                                  uri="sip:Carol@example.com"/>
                 </xcon:allowed-users-list>
             </usersInfo>
         </ccmp:usersRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. usersResponse message form the basic
   operation.

   In 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">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
                 <operation>update</operation>
         <ccmp:response-code>success</ccmp:response-code>
         <ccmp:confResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

     Figure 21: Updating the following sections we deal with each list of allowed users for the above mentioned
   actions separately.

8.1. conference
                        'xcon:8977794@meetecho.com'

8.6.  Alice retrieves joins the available blueprints conference

   This section illustrates the sixth transaction associated with retrieval of
   the blueprints, together with a dump of in the two messages exchanged
   ("blueprintsRequest" and "blueprintsResponse").  As it comes out from overall flow.
   Alice uses the figure, CCMP to add herself to the "blueprintsResponse" newly created conference.
   This is achieved through a "userRequest/create" message contains, containing,
   in the
   'blueprintsInfo' 'userInfo' parameter, a <user> element compliant with the XCON
   data model representation.  Notice that such element includes
   information about the available
   blueprints, in the form user's Address of Records, as well as her
   current end-point.  The picture below shows the standard XCON-URI transaction.  Notice
   how the 'confUserId' parameter is equal to the "entity" attribute of
   the blueprint,
   plus additional (and optional) information, like its display-text and
   purpose. <userInfo> element, which indicates that the request issued by
   the client is a first-party one.

   Alice retrieves from joins the server conference by issuing a "userRequest/create" message
   with her own id to the list of available blueprints: server:

    CCMP Client                                             CCMP Server
         |                                                       |
         | CCMP blueprintsRequest userRequest message                              |
         |   - confUserID: Alice                                 |
         |   - confObjId: (null) 8977794                                |
         |   - operation: create                                 |
         |   - userInfo: AliceUserInfo                           |
         |------------------------------------------------------>|
         |                                                       |
         |                     CMP blueprintsResponse                             CCMP userResponse message |
         |                               - confUserID: Alice     |
         |                               - confObjId: (null) 8977794    |
         |                               - operation: create     |
         |                               - responseCode: success |
         |                               - blueprintsInfo: bp123,bp124,.. userInfo: (null)      |
         |<------------------------------------------------------|
         |                                                       |
         .                                                       .
         .                                                       .

  1. blueprintsRequest 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="xcon:ccmp-blueprints-request-message-type">
       <confUserID>Alice</confUserID>
    </ccmpRequest>
   </ccmp:ccmpRequest>

   2. blueprintsResponse message form 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>Alice</confUserID>
       <ccmp:response-code>success</ccmp:response-code>
        <ccmp:blueprintsResponse>
         <blueprintsInfo>
          <info:entry>
           <info:uri>xcon:AudioRoom@meetecho.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@meetecho.com</info:uri>
           <info:display-text>VideoRoom</info:display-text>
           <info:purpose>Video Room:
               conference room with public access,
               where both audio and video are available,
               8 users can talk and be seen at the same time,
               and the floor requests are automatically accepted.
           </info:purpose>
          </info:entry>
          <info:entry>
           <info:uri>xcon:AudioConference1@meetecho.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>
              xsi:type="ccmp:ccmp-confUser-request-message-type">
          <confObjID>xcon:8977794@meetecho.com</confObjID>
          <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
                  <operation>create</operation>
          <ccmp:confUserRequest>
              <userInfo entity="xcon-userid:Alice@meetecho.com">
                  <info:associated-aors>
                      <info:entry>
           <info:uri>xcon:VideoConference1@meetecho.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:uri>
                             mailto:Alice83@example.com
                          </info:uri>
                          <info:display-text>email</info:display-text>
                      </info:entry>
           <info:entry>
            <info:uri>xcon:AudioConference2@meetecho.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
                  </info:associated-aors>
                  <info:endpoint entity="sip:alice_789@example.com"/>
              </userInfo>
          </ccmp:confUserRequest>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  2. userResponse message form the AudioFloor MUST
                 be accepted by a Chair.
            </info:purpose>
           </info:entry>
        </blueprintsInfo>
      </ccmp:blueprintsResponse> 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-confUser-response-message-type">
          <confObjID>xcon:8977794@meetecho.com</confObjID>
          <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
          <operation>create</operation>
          <ccmp:response-code>success</ccmp:response-code>
          <ccmp:confUserResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>

          Figure 16: Getting blueprints from 22: Alice joins the server

8.2. conference through the CCMP

8.7.  Alice gets detailed information about adds a specific blueprint new user to the conference

   This section illustrates the second seventh and last transaction in the
   overall flow.
   In this case, Alice, who now knows the XCON-URIs of  Alice uses the blueprints
   available at CCMP to add a new user to the server, makes
   conference.  This is achieved through a drill-down query, "userRequest/create" message
   containing, in the form of 'userInfo' parameter, a
   CCMP "blueprintRequest" message, to get detailed <user> element compliant
   with the XCON data model representation.  Notice that such element
   includes information about
   one the user's Address of them (the one called with XCON-URI
   "xcon:AudioRoom@meetecho.com"). Records, as well as
   his current end-point.  The picture below shows such the transaction.
   Notice how the 'confUserId' parameter in the request is Alice's id,
   whereas the <userInfo> element has no "entity" attribute and contains
   information about a different user, thus indicating that the response contains, in request
   issued by the client is a third-party one.  This is also reflected in
   the response coming from the server, which this time contains a non-
   void <userInfo> element, whose "entity" attribute has been set by the
   server to the 'blueprintInfo' parameter,
   a document compliant with value of the standard XCON data model. newly created conference user id.

   Alice retrieves detailed information about adds user "Ciccio" to the conference by issuing a specified blueprint: third-party
   "userRequest/create" message to the server:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP blueprintRequest userRequest message                              |
        |   - confUserID: Alice                                 |
        |   - confObjId: bp123 8977794                                |
        |   - Operation: retrieve operation: create                                 |
        |   - blueprintInfo: (null) usersInfo: CiccioUserInfo                         |
        |------------------------------------------------------>|
        |                                                       |
        |                             CCMP blueprintResponse userResponse message |
        |                               - confUserID: Alice     |
        |                               - confObjId: bp123 8977794    |
        |                               - operation: create     |
        |                               - responseCode: success |
        |                               - blueprintInfo: bp123Info   | usersInfo: (not null!)|
        |<------------------------------------------------------|
        |                                                       |
        .                                                       .

        .                                                       .

 1. blueprintRequest message: "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-blueprint-request-message-type">
           <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
           <confUserID>Alice</confUserID>
           <ccmp:blueprintRequest>
               <operation>retrieve</operation>
           </ccmp:blueprintRequest>
                  xsi:type="ccmp:ccmp-confUser-request-message-type">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
         <operation>create</operation>
         <ccmp:confUserRequest>
             <userInfo>
                 <info:associated-aors>
                     <info:entry>
                         <info:uri>
                             mailto:ciccio@pernacchio.com
                         </info:uri>
                         <info:display-text>email</info:display-text>
                     </info:entry>
                 </info:associated-aors>
                 <info:endpoint entity="sip:ciccio@pernacchio.com"/>
             </userInfo>
         </ccmp:confUserRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. blueprintResponse "third party" userResponse message form 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">
        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-blueprint-response-message-type">
       <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
       <confUserID>Alice</confUserID>
                   xsi:type="ccmp:ccmp-confUser-response-message-type">
         <confObjID>8977794</confObjID>
         <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
         <ccmp:response-code>success</ccmp:response-code>
       <ccmp:blueprintResponse>
         <blueprintInfo entity="AudioRoom">
           <info:conference-description>
              <info:display-text>AudioRoom</info:display-text>
              <info:maximum-user-count>2</info:maximum-user-count>
              <info:available-media>
                <info:entry label="audioLabel">
                    <info:type>audio</info:type>
         <operation>create</operation>
         <ccmp:confUserResponse>
             <confUserInfo entity="xcon-userid:bn90ujbkj@meetecho.com">
                 <info:associated-aors>
                     <info:entry>
                         <info:uri>
                            mailto:ciccio@pernacchio.com
                         </info:uri>
                         <info:display-text>email</info:display-text>
                     </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="audioLabel"></xcon:floor>
             </xcon:conference-floor-policy>
           </xcon:floor-information>
         </blueprintInfo>
       </ccmp:blueprintResponse>
                 </info:associated-aors>
                 <info:endpoint entity="sip:ciccio@pernacchio.com"/>
             </confUserInfo>
         </ccmp:confUserResponse>
     </ccmpResponse>
 </ccmp:ccmpResponse>

    Figure 17: Getting info about a specific blueprint

8.3. 23: Alice creates adds a new user to the conference through the CCMP

9.  Locating a cloning operation

   This section illustrates Conference Control Server

   If a conference control client is not pre-configured to use a
   specific conference control server for the third transaction in requests, the overall flow.
   Alice decides client MUST
   first discover the conference control 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.

   This document proposes the use of DNS to create a new conference by cloning locate the blueprint
   having XCON-URI "xcon:AudioRoom@meetecho.com", conferencing
   server.  U-NAPTR resolution for which she just
   retrieved detailed information through conferencing takes a domain name as
   input and produces a URI that identifies the "blueprintRequest"
   message. conferencing 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 14.4.1 defines an Application Service tag of "XCON", which is achieved by sending a "confRequest/create" message
   having the blueprint's URI in
   used to identify the 'confObjId' parameter. centralized conferencing (XCON) server for a
   particular domain.  The picture
   shows such transaction.  Notice Application Protocol tag "CCMP", defined in
   Section 14.4.2, is used to identify an XCON server that understands
   the response contains, CCMP protocol.

   The NAPTR records in the
   'confInfo' parameter, following example Figure 24 demonstrate the document associated with
   use of the newly created
   conference, which Application Service and Protocol tags.  Iterative NAPTR
   resolution is compliant with used to delegate responsibility for the standard XCON data model.
   The 'confObjId' conferencing
   service from "zonea.example.com." and "zoneb.example.com." to
   "outsource.example.com.".

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

   Details for the "XCON" Application Service tag and the "CCMP"
   Application Protocol tag are included in Section 14.4.

10.  Managing Notifications

   In cases where the response is set conference control client uses SIP [RFC3261] as
   the signaling protocol to participate in the XCON-URI of conference, SIP event
   notification can be used.  This would REQUIRE the new conference (in this case, "xcon:8977794@meetecho.com").  We also
   notice that this value is equal control
   client to implement the value of the "entity"
   attribute of Conference event package for XCON
   [I-D.ietf-xcon-event-package].  This is the <conference-info> element of default mechanism for
   conferencing clients as is SIP for signaling per the document
   representing XCON Framework
   [RFC5239].

   In the newly created conference object.

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

  CCMP Client                                             CCMP Server
         |                                                       |
         | CCMP confRequest message                              |
         |   - confUserID: Alice                                 |
         |   - confObjId: xcon:AudioRoom@meetecho.com            |
         |   - Operation: create                                 |
         |   - confInfo: (null)                                  |
         |------------------------------------------------------>|
         |                                                       |
         |                             CCMP confResponse message |
         |                               - confUserID: Alice     |
         |                               - confObjId: newConfId  |
         |                               - responseCode: success |
         |                               - 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">
        <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
        <confUserID>Alice</confUserID>
        <ccmp:confRequest>
            <operation>create</operation>
        </ccmp:confRequest>
     </ccmpRequest>
  </ccmp:ccmpRequest>

  2. confResponse message from interface to 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">
       <confObjID>xcon:8977794@meetecho.com</confObjID>
       <confUserID>Alice</confUserID>
       <ccmp:response-code>success</ccmp:response-code>
       <ccmp:confResponse>
            <confInfo entity="xcon:8977794@meetecho.com">
              <info:conference-description>
                  <info:display-text>
                     New conference by Alice cloned from AudioRoom
                  </info:display-text>
                  <info:conf-uris>
                     <info:entry>
                        <info:uri>
                            xcon:8977794@meetecho.com
                        </info:uri>
                        <info:display-text> conference xcon-uri
                        </info:display-text>
                        <xcon:conference-password>
                            8601
                        </xcon:conference-password>
                      </info:entry>
                   </info:conf-uris>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="11">
                              <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:conference-floor-policy>
                  </xcon:floor-information>
              </confInfo>
          </ccmp:confResponse>
      </ccmpResponse>
  </ccmp:ccmpResponse>

        Figure 18: Creating server is entirely
   web based, there is a common mechanism for web-based systems that
   could be used - a new "call back".  With this mechanism, the conference by cloning a blueprint

8.4.  Alice updates
   client provides the conference information server with an HTTP URL which is
   invoked when a change occurs.  This section illustrates the fourth transaction is a common implementation
   mechanism for e-commerce.  This works well in the overall flow.
   Alice decides to modify some of scenarios whereby
   the details associated with conferencing client is a web server that provides the graphical
   HTML user interface and uses CCMP as the backend interface to the
   conference she just created.  More precisely, she changes server.  And, this model can co-exist with the
   <display-text> element under SIP event
   notification model.  PC-based clients behind NATs could provide a SIP
   event URI, whereas web servers would probably find the <conference-description> element HTTP model
   much easier to program.  The details of this approach are out of
   scope for the document representing CCMP per se, thus the conference. expectation is that a future
   specification will document this solution.

11.  HTTP Transport

   This section describes the use of HTTP [RFC2616] and HTTP Over TLS
   [RFC2818] as transport mechanisms for the CCMP protocol, which a
   conforming conference Server and Conferencing client MUST support.

   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 may not a fully compliant HTTP server.  It is achieved through
   intended that a
   "confRequest/update" message carrying 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 implementors avoid ambiguity with the many options
   the full HTTP protocol offers.

   A conferencing client that conforms to this specification SHOULD NOT
   be required to support HTTP authentication [RFC2617] or cookies
   [RFC2965].  Because the conferencing client and the fragment of conference server
   may have a prior relationship, the conference
   document server SHOULD NOT
   require a conferencing client to which authenticate, either using the required changes have to be applied.  As shown above
   HTTP authentication methods or TLS client authentication.

   A CCMP request is carried in the picture, the response contains a code body of 'success', which
   acknowledges the modifications requested by the client.

   Alice updates information about an HTTP POST request.  The
   conferencing client MUST include a Host header in the conference she just created:

     CCMP Client                                             CCMP Server
          |                                                       |
          | CCMP confRequest message                              |
          |   - confUserID: Alice                                 |
          |   - confObjId: xcon:8977794@meetecho.com              |
          |   - Operation: update                                 |
          |   - confInfo: conf456Updates                          |
          |------------------------------------------------------>|
          |                                                       |
          | request.

   The MIME type of CCMP confResponse message |
          |                               - confUserID: Alice     |
          |                               - confObjId: xcon:89..  |
          |                               - responseCode: success |
          |                               - 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">
       <confObjID>xcon:8977794@meetecho.com</confObjID>
       <confUserID>Alice</confUserID>
       <ccmp:confRequest>
          <operation>update</operation>
            <confInfo entity="xcon:8977794@meetecho.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 form 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">
        <confObjID>xcon:8977794@meetecho.com</confObjID>
        <confUserID>Alice</confUserID>
        <ccmp:response-code>success</ccmp:response-code>
        <ccmp:confResponse/>
     </ccmpResponse>
   </ccmp:ccmpResponse>

                Figure 19: Updating request and response bodies is "application/
   ccmp+xml".  The conference information

8.5.  Alice inserts a list of users server and conferencing client MUST
   provide this value in the HTTP Content-Type and Accept header fields.
   If the conference object

   This section illustrates server does not receive the fifth transaction in appropriate Content-
   Type and Accept header fields, the overall flow.
   Alice modifies 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 <allowed-users-list> under "Expect" header or the <users> element "Range"
   header in CCMP requests.  The conference server MAY return 501 (not
   implemented) errors if either of these HTTP features are used.  In
   the document associated with case that the conference she created.  To server receives a request from the
   purpose, she exploits
   conferencing client containing a If-* (conditional) header, the "usersRequest" message provided by
   conference server SHOULD return a 412 (precondition failed) response.

   The POST method is the only method REQUIRED for CCMP.  The picture below shows  If a
   conference server chooses to support GET or HEAD, it SHOULD consider
   the transaction.

   Alice updates kind of application doing the GET.  Since a conferencing client
   only uses a POST method, the GET or HEAD MUST be either an escaped
   URL (e.g., somebody found a URL in protocol traces or log files and
   fed it into their browser) or somebody doing testing/ debugging.  The
   conference server could provide information about in the list of users HELD response
   indicating that the URL corresponds to whom access a conference server and only
   responds to CCMP POST requests or the conference is permitted:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP usersRequest message                             |
        |   - confUserID: Alice                                 |
        |   - confObjId: xcon:8977794@meetecho.com              |
        |   - Operation: update                                 |
        |   - usersInfo: usersUpdates                               |
        |------------------------------------------------------>|
        |                                                       |
        |                            CCMP usersResponse message |
        |                              - confUserID: Alice      |
        |                              - confObjId: xcon:89..   |
        |                              - responseCode: success  |
        |                              - 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">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>Alice</confUserID>
         <ccmp:usersRequest>
           <operation>update</operation>
             <usersInfo>
                 <xcon:allowed-users-list>
                     <xcon:target method="dial out"
                                  uri="xmpp:cicciolo@pippozzo.com"/>
                     <xcon:target method="refer"
                                  uri="tel:+390817683823"/>
                     <xcon:target method="refer"
                                  uri="sip:Carol@example.com"/>
                 </xcon:allowed-users-list>
             </usersInfo>
         </ccmp:usersRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. usersResponse server could instead
   try to avoid any leak of information by returning a very generic HTTP
   error message form such as 404 (not found).

   The conference server populates 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">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>Alice</confUserID>
         <ccmp:response-code>success</ccmp:response-code>
         <ccmp:confResponse/>
     </ccmpResponse>
 </ccmp:ccmpResponse>

     Figure 20: Updating HTTP headers of responses so that
   they are consistent with the list contents of allowed users for the message.  In particular,
   the "CacheControl" header SHOULD be set to disable caching of any
   conference
                        'xcon:8977794@meetecho.com'

8.6.  Alice joins 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

   This section illustrates server MAY redirect a CCMP request.  A conferencing
   client MUST handle redirects, by using the sixth transaction Location header provided
   by the server in a 3xx response.  When redirecting, the overall flow.
   Alice uses conferencing
   client MUST observe the CCMP to add herself to delay indicated by the newly created conference.
   This 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 achieved through not supported, the conference
   server MUST NOT allow persistent connections.  The conference server
   MUST support termination of a "userRequest/create" response by the closing of a
   connection.

   Implementations of CCMP that implement HTTP transport MUST implement
   transport over TLS [RFC2818].  TLS provides message containing, integrity and
   confidentiality between the conference control client and the
   conference control server.  The conferencing client MUST implement
   the server authentication method described in HTTPS [RFC2818].  The
   device uses the 'userInfo' parameter, a <user> element compliant with URI obtained during conference server discovery to
   authenticate the XCON
   data model representation.  Notice that such element includes
   information about 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.

12.  Security Considerations

   As identified in the user's Address XCON framework [RFC5239], there are a wide
   variety of Records, as well as her
   current end-point.  The picture below shows potential attacks related to conferencing, due to the transaction.  Notice
   how
   natural involvement of multiple endpoints and the 'confUserId' parameter is equal capability to
   manipulate the "entity" attribute data on the conference server using CCMP.  Examples of
   attacks include the <userInfo> element, following: an endpoint attempting to listen to
   conferences in which indicates that the request issued it is not authorized to participate, an endpoint
   attempting to disconnect or mute other users, and theft of service by
   an endpoint in attempting to create conferences it is not allowed to
   create.

   The following summarizes the security considerations for CCMP:

   1.  The client is a first-party one.

   Alice joins MUST determine the proper conference by issuing a "userRequest/create" message
   with her own id server.  The
       conference server discovery is described in .

   2.  The client MSUT connect to the server:

    CCMP Client                                             CCMP Server
         |                                                       |
         | CCMP userRequest message                              |
         |   - confUserID: Alice                                 |
         |   - confObjId: xcon:8977794@meetecho.com              |
         |   - Operation: create                                 |
         |   - userInfo: AliceUserInfo                           |
         |------------------------------------------------------>|
         |                                                       |
         | proper conference server.  The
       mechanisms for addressing this security consideration are
       described in Section 12.1.

   3.  The protocol MUST support a confidentiality and integrity
       mechanism.  As described in Section 11, implementations of CCMP userResponse message |
         |                               - confUserID: Alice     |
         |                               - confObjId: xcon:89..  |
         |                               - responseCode: success |
         |                               - 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-confUser-request-message-type">
          <confObjID>xcon:8977794@meetecho.com</confObjID>
          <confUserID>Alice</confUserID>
          <ccmp:confUserRequest>
              <operation>create</operation>
              <userInfo entity="Alice">
                  <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:confUserRequest>
      </ccmpRequest>
  </ccmp:ccmpRequest>

  2. userResponse message form
       MUST implement the HTTP transport over TLS [RFC2818].

   4.  There are security issues associated with 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-confUser-response-message-type">
          <confObjID>xcon:8977794@meetecho.com</confObjID>
          <confUserID>Alice</confUserID>
          <ccmp:response-code>success</ccmp:response-code>
          <ccmp:confUserResponse/>
      </ccmpResponse>
  </ccmp:ccmpResponse>

          Figure 21: Alice joins authorization to
       perform actions on the conferencing system to invoke specific
       capabilities.  A conference through server SHOULD ensure that only
       authorized entities can manipulate the CCMP

8.7.  Alice adds conference data.  The
       mechanisms for addressing this security consideration are
       described in Section 12.2.

   5.  The privacy and security of the identity of a new user to in the
       conference

   This section illustrates MUST be assured.  The mechanisms to ensure the seventh
       security and last transaction privacy of identity are discussed in the
   overall flow.  Alice uses the CCMP Section 12.3.

   6.  A final issue is related to add a new user Denial of Service (DoS) attacks on
       the conferencing server itself.  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 is achieved can be accomplished
       through a "userRequest/create" message
   containing, the use of the mechanisms described in Section 12.2, as
       well as by using the 'userInfo' parameter, a <user> element compliant security mechanisms associated with the XCON data model representation.  Notice
       specific signaling (e.g., SIPS) and media protocols (e.g., SRTP).

12.1.  Assuring that such element
   includes information about the user's Address of Records, Proper Conferencing Server has been contacted

   When the CCMP transaction is conducted using TLS [RFC5246], the
   conference server can authenticate its identity, either as well a domain
   name or as
   his current end-point.  The picture below shows the transaction.
   Notice how an IP address, to the 'confUserId' parameter in conference client by presenting a
   certificate containing that identifier as a subjectAltName (i.e., as
   an iPAddress or dNSName, respectively).  With the request use of HTTP as a
   transport for CCMP, this is Alice's id,
   whereas exactly the <userInfo> element authentication described by
   TLS [RFC2818].  If the client has no "entity" attribute and contains external information about as to the
   expected identity or credentials of the proper conference server
   (e.g., a different user, thus indicating certificate fingerprint), these checks MAY be omitted.  Any
   implementation of CCMP MUST be capable of being transacted over TLS
   so that the client can request
   issued by the client is above authentication, and a third-party one.  This is also reflected
   conference server implementation MUST include this feature.  Note
   that in order for the response coming from presented certificate to be valid at the server, which this time contains a non-
   void <userInfo> element, whose "entity" attribute has been set by
   client, the
   server client must be able to validate the value certificate.  In
   particular, the validation path of the newly created conference user id.

   Alice adds user "Ciccio" to certificate must end in one of
   the conference by issuing a third-party
   "userRequest/create" message to client's trust anchors, even if that trust anchor is the server:

   CCMP Client                                             CCMP Server
        |                                                       |
        | CCMP userRequest message                              |
        |   - confUserID: Alice                                 |
        |   - confObjId: xcon:8977794@meetecho.com              |
        |   - Operation: create                                 |
        |   - usersInfo: CiccioUserInfo                         |
        |------------------------------------------------------>|
        |                                                       |
        |                             CCMP userresponse message |
        |                               - confUserID: Alice     |
        |                               - confObjId: xcon:89..  |
        |                               - responseCode: success |
        |                               - usersInfo: (not null!)|
        |<------------------------------------------------------|
        |                                                       |
        .                                                       .
        .                                                       .

 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-confUser-request-message-type">
         <confObjID>xcon:8977794@meetecho.com</confObjID>
         <confUserID>Alice</confUserID>
         <ccmp:confUserRequest>
             <operation>create</operation>
             <userInfo>
                 <info:associated-aors>
                     <info:entry>
                         <info:uri>
                             mailto:ciccio@pernacchio.com
                         </info:uri>
                         <info:display-text>email</info:display-text>
                     </info:entry>
                 </info:associated-aors>
                 <info:endpoint entity="sip:ciccio@pernacchio.com"/>
             </userInfo>
         </ccmp:confUserRequest>
     </ccmpRequest>
 </ccmp:ccmpRequest>

 2. "third party" userResponse message form
   conference server certificate itself.

12.2.  User Authentication and Authorization

   Many policy authorization decisions are based on 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-confUser-response-message-type">
         <confObjID>8977794</confObjID>
         <confUserID>Alice</confUserID>
         <ccmp:response-code>success</ccmp:response-code>
         <ccmp:confUserResponse>
             <confUserInfo entity="bn90ujbkj">
                 <info:associated-aors>
                     <info:entry>
                         <info:uri>
                            mailto:ciccio@pernacchio.com
                         </info:uri>
                         <info:display-text>email</info:display-text>
                     </info:entry>
                 </info:associated-aors>
                 <info:endpoint entity="sip:ciccio@pernacchio.com"/>
             </confUserInfo>
         </ccmp:confUserResponse>
     </ccmpResponse>
 </ccmp:ccmpResponse>

    Figure 22: Alice adds identity of the
   user or the role that a user may have.  The conferencing server MUST
   implement mechanisms for authentication of users to validate their
   identity.  There are several ways that a new user might authenticate its
   identity to the system.  For users joining a conference through using one of
   the call signaling protocols, the user authentication mechanisms for
   the specific protocol can be used.  For the case of users joining the
   conference using the CCMP, TLS is RECOMMENDED.

   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
   correlate the authorization of the CCMP

9.  Locating interface with other
   authorization mechanisms - e.g., PSTN users that join with a Conference Control Server

   If PIN and
   control the conference using CCMP.  When a conference control client 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 not pre-configured 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 use a specific user through the
   conference control server notification interface and MUST be provided to users that
   interact with the conferencing system using the CCMP (i.e., in the
   appropriate CCMP response messages).  This conference user identifier
   is REQUIRED for any subsequent operations on the conference object.

12.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 requests, identity in the client MUST
   first discover form of the XCON-USERID is
   provided in the CCMP protocol through the use of TLS.

   The conference control server before it can send any
   requests.  The result SHOULD provide mechanisms to ensure the privacy
   of the discovery process, XCON-USERID.  This is accomplished by the address conference client
   manipulation of the
   server supporting conferencing.  In this document, "provide-anonymity" element defined in the result is an
   http: or https: URI, XCON
   data model ([I-D.ietf-xcon-common-data-model].  The "provide-
   anonymity" element controls the degree to which identifies a user reveals their
   identity.  The conference server.

   This document proposes client MUST set the use of DNS "provide-anonymity"
   element to locate "hidden" if the conferencing
   server.  U-NAPTR resolution for conferencing takes a domain name as
   input and produces a URI user does not want other participants to
   even be aware that identifies the conferencing server.
   This process also requires an Application Service tag and there is an
   Application Protocol tag, which differentiate conferencing-related
   NAPTR records from additional participant in the
   conference.  The conference client MUST set the "provide-anonymity"
   field to "private" the user wants to be entirely "anonymous" (i.e.,
   other records for participants are aware that domain.

   Section 12.4.1 defines an Application Service tag of "XCON", which there is
   used another participant, but
   have no information as to identify the centralized conferencing (XCON) server for a
   particular domain. their identity).  The Application Protocol tag "CCMP", defined in
   Section 12.4.2, conference client
   MUST set the "provide-anonymity" field to "semi-private" if their
   identity is used only to identify an XCON server be revealed to other participants or users that understands
   have a higher level authorization (e.g., a conferencing system can be
   configured such that an administrator can see all users).  To provide
   the required privacy, the conference client SHOULD include the
   "provide-anonymity" element in the "confInfo" parameter in a CCMP protocol.

   The NAPTR records
   confRequest message with an "update" or "create" operation or in the following example Figure 23 demonstrate the
   use of the Application Service and Protocol tags.  Iterative NAPTR
   resolution is used
   "userInfo" parameter in a CCMP userRequest message with an "update"
   or "create" operation, to delegate responsibility for ensure the conferencing
   service from "zonea.example.com." and "zoneb.example.com." to
   "outsource.example.com.".

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

   Details for user is provided the "XCON" Application Service tag and appropriate
   level of privacy.  If the "CCMP"
   Application Protocol tag are "provide-anonymity" element is not included
   in Section 12.4.

10. the conference object, then other users can see the participant's
   identity.

13.  XML Schema

   This section provides the XML schema definition of the "application/
   ccmp+xml" format.

  <?xml version="1.0" encoding="utf-8"?>
     <xs:schema
         targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
         xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:xs="http://www.w3.org/2001/XMLSchema">

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

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

  <!-- CCMP request definition -->

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

  <!-- CCMP response definition -->

  <xs:complexType name="ccmp-response-type">
          <xs:sequence>
                  <xs:element name="ccmpResponse"
                          type="ccmp-response-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="confUserID" type="xs:string"
          minOccurs="1"
                                  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="password" type="xs:string"
                                          minOccurs="0" maxOccurs="1" />
      </xs:sequence>
     </xs:complexType>

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

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

     <!-- blueprintRequestType -->

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

     <xs:complexType name="blueprintRequestType">
       <xs:sequence>
          <xs:element name="operation" type="operationType"
                        minOccurs="1" maxOccurs="1" />
            <xs:element name="blueprintInfo"
             type="info:conference-type" minOccurs="0"/>
       </xs:sequence>
     </xs:complexType>

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

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

     <!-- confRequestType -->

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

       <xs:complexType name="confRequestType">
       <xs:sequence>
          <xs:element name="operation" type="operationType"
                        minOccurs="1" maxOccurs="1" />
            <xs:element name="confInfo"
              type="info:conference-type" minOccurs="0"/>
       </xs:sequence>
     </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"/> ref="usersRequest" />
        </xs:sequence>
       </xs:extension>
      </xs:complexContent>
     </xs:complexType>

     <!-- usersRequestType -->

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

                  <xs:complexType name="usersRequestType">
                          <xs:sequence>
                                  <xs:element name="operation" type="operationType"
                                          minOccurs="1" maxOccurs="1" />
                   <xs:element name="usersInfo"
              type="info:users-type" minOccurs="0" />
                          </xs:sequence>
                  </xs:complexType>

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

     <!-- userRequestType -->

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

                  <xs:complexType name="userRequestType">
                          <xs:sequence>
                                  <xs:element name="operation"
          type="operationType"
                            minOccurs="1" maxOccurs="1" />
            <xs:element name="userInfo"
              type="info:user-type" minOccurs="0" />
                          </xs:sequence>
                  </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> base="tns:ccmp-request-message-type"/>
      </xs:complexContent>
     </xs:complexType>

                  <!-- sidebarsByValRequestType -->

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

  <xs:complexType name="sidebarsByValRequestType">
       <xs:sequence>
          <xs:element name="operation" type="operationType"
                      minOccurs="1" maxOccurs="1" />
          <xs:element name="sidebarsByValInfo"
              type="info:sidebars-by-val-type" minOccurs="0"/>
       </xs:sequence>
  </xs:complexType>

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

                  <!-- sidebarsByRefRequestType -->

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

    <xs:complexType name="sidebarsByRefRequestType">
         <xs:sequence>
            <xs:element name="operation" type="operationType"
                        minOccurs="1" maxOccurs="1" />
            <xs:element name="sidebarsByRefInfo"
               type="info:uris-type" minOccurs="0"/>
         </xs:sequence>
       </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="operation" type="operationType"
              minOccurs="1" maxOccurs="1"
         type="sidebarByValRequestType" />

       <xs:complexType name="sidebarByValRequestType">
       <xs:sequence>
          <xs:element name="sidebarByValInfo"
              type="info:conference-type" minOccurs="0"/>
       </xs:sequence>
     </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="operation" type="operationType"
                minOccurs="1" maxOccurs="1" />
            <xs:element name="sidebarByRefInfo"
              type="info:conference-type" minOccurs="0"/>
       </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="0"
                                  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 ref="response-code" minOccurs="1"
                                  maxOccurs="1" />
      </xs:sequence>
     </xs:complexType>

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

     <!-- blueprintsResponseType -->

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

       <xs:complexType name="blueprintsResponseType">
       <xs:sequence>
          <xs:element name="blueprintsInfo"
              type="info:uris-type" minOccurs="0"/>
       </xs:sequence>
     </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"/> 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"/>
       </xs:sequence>
     </xs:complexType>
                  <!-- confsResponse -->
     <xs:complexType name="ccmp-confs-response-message-type">
      <xs:complexContent>
       <xs:extension base="tns:ccmp-response-message-type">
        <xs:sequence>
         <xs:element ref="confsResponse" />
        </xs:sequence>
       </xs:extension>
      </xs:complexContent>
     </xs:complexType>

     <!-- confsResponseType -->

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

       <xs:complexType name="confsResponseType">
       <xs:sequence>
          <xs:element name="confsInfo"
          type="info:uris-type" minOccurs="0"/>
       </xs:sequence>
     </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"/>
       </xs:sequence>
     </xs:complexType>

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

     <!-- usersResponseType -->

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

     <xs:complexType name="usersResponseType">
       <xs:sequence>
          <xs:element name="usersInfo" type="info:users-type"/>
       </xs:sequence>
     </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"/>
       </xs:sequence>
     </xs:complexType>

                  <!-- sidebarsByValResponse -->

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

     <!-- sidebarsByValResponseType -->

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

     <xs:complexType name="sidebarsByValResponseType">
       <xs:sequence>
          <xs:element name="sidebarsByValInfo"
              type="info:sidebars-by-val-type"/>
       </xs:sequence>
     </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"/>
       </xs:sequence>
     </xs:complexType>

                  <!-- sidebarByValResponse -->

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

     <!-- sidebarByValResponseType -->

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

      <xs:complexType name="sidebarByValResponseType">
       <xs:sequence>
          <xs:element name="sidebarByValInfo"
              type="info:conference-type"/>
       </xs:sequence>
     </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"/>
         </xs:sequence>
     </xs:complexType>

          <!-- response-code -->

  <xs:element name="response-code" type="response-codeType" />

          <xs:simpleType name="response-codeType">
            <xs:restriction base="xs:token">
              <xs:enumeration value="success"/>
              <xs:enumeration value="pending"/>
              <xs:enumeration value="modified"/>
              <xs:enumeration value="badRequest"/>
              <xs:enumeration value="unauthorized"/>
              <xs:enumeration value="forbidden"/>
              <xs:enumeration value="objectNotFound"/>
              <xs:enumeration value="forbiddenDeleteParent"/>
              <xs:enumeration value="forbiddenChangeProtected"/>
              <xs:enumeration value="requestTimeout"/>
              <xs:enumeration value="serverInternalError"/>
              <xs:enumeration value="notImplemented"/>
            </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>
    </xs:schema>

                                 Figure 24

11.  Managing notifications

   This section is still "Under Construction" and currently contains
   some views on handling notifications.

   One proposal is to stick with SIP notification.  Another alternative,
   which is commonly done in other web-based systems, is a "call back",
   i.e., the CCMP client provides the conference server with an HTTP URL
   which is invoked when a change occurs.  This is apparently how most
   credit card shopping cards work, having implemented one.  This works
   well for our scenario since a CCMP "client" is likely to be a web
   server that provides the graphical HTML user interface and uses CCMP
   as the backend to talk to the conference server.  In that particular
   case, there doesn't seem to be a problem of having both models.  PC-
   based clients behind NATs would provide a SIP event URI, web servers
   would probably find the HTTP model much easier to program with.

   Another option being considered is BOSH
   (http://xmpp.org/extensions/xep-0124.html), which is basically an
   extension to XMPP designed with the following aim: "...a transport
   protocol that emulates a bidirectional stream between two entities
   (such as a client and a server) by efficiently using multiple
   synchronous HTTP request/response pairs without requiring the use of
   polling or asynchronous chunking."

   A final consideration (under discussion only) is basic XMPP.

12. 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"/>
       </xs:sequence>
     </xs:complexType>

     <!-- response-code -->

     <xs:element name="response-code" type="response-codeType" />

     <xs:simpleType name="response-codeType">
       <xs:restriction base="xs:token">
         <xs:enumeration value="success"/>
         <xs:enumeration value="pending"/>
         <xs:enumeration value="modified"/>
         <xs:enumeration value="badRequest"/>
         <xs:enumeration value="unauthorized"/>
         <xs:enumeration value="forbidden"/>
         <xs:enumeration value="objectNotFound"/>
         <xs:enumeration value="userNotFound"/>
         <xs:enumeration value="invalidConfUserID"/>
         <xs:enumeration value="passwordRequired"/>
         <xs:enumeration value="invalidPassword"/>
         <xs:enumeration value="forbiddenDeleteParent"/>
         <xs:enumeration value="forbiddenChangeProtected"/>
         <xs:enumeration value="requestTimeout"/>
         <xs:enumeration value="serverInternalError"/>
         <xs:enumeration value="notImplemented"/>
       </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>
    </xs:schema>

                                 Figure 25

14.  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.  This document also defines registries for the CCMP operation
   types and response codes.

12.1.

14.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.barnes@nortel.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>CCMP Messages</title>
             </head>
             <body>
               <h1>Namespace for CCMP Messages</h1>
               <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

12.2.

14.2.  XML Schema Registration

   This section registers an XML schema as 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.barnes@nortel.com).

   Schema:  The XML for this schema can be found as the entirety of
      Section 10 13 of this document.

12.3.

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

   Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default XML for which the
      default is UTF-8.

   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], section 3.2.

   Security considerations:  This content type is designed to carry
      protocol data related conference control.  Some of the data could
      be considered private and thus should be protected.

   Interoperability considerations:  This content type provides a basis
      for a protocol  None.

   Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]

   Applications which use this media type:  Centralized Conferencing
      control clients and servers.

   Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:  Mary
      Barnes <mary.barnes@nortel.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.

14.4.  DNS Registrations

   Section 12.4.1 14.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, 14.4.2, is used to identify an XCON server that understands
   the CCMP protocol.

12.4.1.

14.4.1.  Registration of a Location 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: RFCXXXX

   Contact information: The authors of this document

   Author/Change controller: The IESG

12.4.2.

14.4.2.  Registration of a Location Server Application Protocol Tag for
         HELD

   This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
   for the CCMP protocol, 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: RFCXXXX

   Contact Information: The authors of this document

   Author/Change Controller: The IESG

12.5.

14.5.  CCMP Protocol Registry

   This document requests that the IANA create a new registry for the
   CCMP protocol including an initial registry for operation types and
   response codes.

12.5.1.

14.5.1.  CCMP Message Types

   The CCMP messages are described in Section 7 and defined in the XML
   schema in Section 10. 13.  The following summarizes the requested
   registry:

   Related Registry:   CCMP Message Types Registry

   Defining RFC:  RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
      with the RFC number for this specification.]

   Registration/Assignment Procedures:  New CCMP message types are
      allocated on a specification required basis.

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

   This section pre-registers the following initial CCMP message types:

   blueprintsRequest:  Used by a conference control client to query a
      conferencing system for its capabilities, in terms of available
      conference blueprints.

   blueprintsResponse:  The optionsResponse returns a list of Blueprints
      supported by the specific conference server.

   confsRequest:  Used by a conference control client to query a
      conferencing system for its scheduled/active conferences.

   confsResponse:  The confsResponse returns the list of the currently
      activated/scheduled conferences at the server.

   confRequest:  The confRequest is used to create a conference object
      and/or to request an operation on the conference object as a
      whole.

   confResponse:  The confResponse indicates the result of the operation
      on the conference object as a whole.

   userRequest:  The userRequest is used to request an operation on the
      "user" element in the conference object.

   userResponse:  The userResponse indicates the result of the requested
      operation on the "user" element in the conference object.

   usersRequest  This usersRequest is used to manipulate the "users"
      element in the conference object, including parameters such as the
      allowed-users-list, join-handling, etc.

   usersResponse:  This usersResponse indicates the result of the
      request to manipulate the "users" element in the conference
      object.

   sidebarRequest:  This sidebarRequest is used to retrieve the
      information related to a sidebar or to create, change or delete a
      specific sidebar.

   sidebarResponse:  This sidebarResponse indicates the result of the
      sidebarRequest.

12.5.2.

14.5.2.  CCMP Response Codes

   The following summarizes the requested registry for CCMP Response
   codes:

   Related Registry:   CCMP Response Code Registry

   Defining RFC:  RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
      with the RFC number for this specification.]

   Registration/Assignment Procedures:  New response codes are allocated
      on a first-come/first-serve basis with specification required.

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

   This section pre-registers the following thirteen initial response
   codes as described above in Section 7:

   success:  This code indicates that the request was successfully
      processed.

   modified:  This code indicates that the object was created, but may
      differ from the request.

   badRequest:  This code indicates that the request was badly formed in
      some fashion.

   unauthorized:  This code indicates that the user was not authorized
      for the specific operation on the conference object.

   forbidden:  This code indicates that the specific operation is not
      valid for the target conference object.

   objectNotFound:  This code indicates that the specific conference
      object was not found.

   userNotFound:  This code is returned in answer to a 'userRequest/
      create' operation, in the case of a third-party invite, when the
      'confUserId' (contained in the 'entity' attribute of the
      'userInfo' parameter) of the user to be added is unknown.

   invalidConfUserID:  This code is returned in the case of requests in
      which the 'confUserID' of the sender is invalid.

   invalidPassword:  This code is returned in response to all requests
      wishing to access/manipulate a password-protected conference
      object, when the 'password' parameter contained in the request is
      wrong.

   passwordRequired:  This code is returned in response to all requests
      wishing to access/manipulate a password-protected conference
      object, when the 'password' parameter is missing in the request.

   operationNotAllowed:  This code indicates that the specific operation
      is not allowed for the target conference object (e.g.., due to
      policies, etc.)

   deleteFailedParent:  This code indicates that the conferencing system
      cannot delete the specific conference object because it is a
      parent for another conference object.

   changeFailedProtected:  This code indicates that the target
      conference object cannot be changed (e.g., due to policies, roles,
      privileges, etc.).

   requestTimeout:  This code indicates that the request could not be
      processed within a reasonable time, with the time specific to a
      conferencing system implementation.

   serverInternalError:  This code indicates that the conferencing
      system experienced some sort of internal error.

   notImplemented:  This code indicates that the specific operation is
      not implemented on that conferencing system.

13.  Security Considerations

   Access to conference control functionality needs to be tightly
   controlled to keep attackers from disrupting conferences, adding
   themselves to conferences or engaging in theft of services.  In the
   case of a RESTful implementation of the CCMP, implementors need to
   deploy standard HTTP authentication and authorization mechanisms.
   Since conference information may contain secrets such as participant
   lists and dial-in codes, all conference control information SHOULD be
   carried over TLS (HTTPS).

14.

15.  Acknowledgments

   The authors appreciate the feedback provided by Dave Morgan, Pierre
   Tane, Lorenzo Miniero and Miniero, Tobia Castaldi. Castaldi, Theo Zourzouvillys, Sean Duddy
   and Oscar Novo.  Special thanks go to Roberta Presta for her
   invaluable contribution to this document.  Roberta has worked on the
   specification of the CCMP protocol 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 8 have been extracted.

15.

16.  Changes since last Version

   NOTE TO THE RFC-Editor: Please remove this section prior to
   publication as an RFC.

   The following summarizes the changes between the WG 02 and the 03:

   1.  Clarified that the confUserID is optional in the generic CCMP
       request message for a userRequest with a "create" operation.

   2.  Added responseCode (error cases) handling - a general section for
       each of the operations (as part of CCMP Response Code section),
       so we don't need to re-iterate for each of the messages and
       message specific cases as appropriate (e.g., deleteParentFailed,
       modified)

   3.  Moved "operation" parameter to be part of general CCMP request
       and response messages since it is used for more than one message
       type.  And, it's necessary to define before describing the
       operation specific responseCode handling.

   4.  Revised normative statements for the various protocol messages
       and operations - e.g., messages MUST include parameter x versus
       SHOULD, adding text for handling of cases where the SHOULDs don't
       happen and the SHOULD NOTs do.  Added descriptions for all the
       operation types, as appropriate.

   5.  Added lots more details in the security section.

   6.  Added section to describe requirements for an HTTP implementation
       to support CCMP.

   7.  Updated section on notifications - XCON SIP event package is
       default, with some discussion of an HTTP callback mechanism
       (ffs).

   8.  Misc editorial nits: qualifying message names in the text, etc.,
       etc., etc.

   The following summarizes the changes between the WG 01 and the 02:

   1.  Changed the basic approach from REST to HTTP as a transport.
       This impacted most of the document - i.e., a major rewrite - 02
       is closer to 00 than the 01.

   2.  Added full example based on prototype.

   The following summarizes the changes between the WG 00 and the 01:

   1.  Changed the basic approach from using SOAP to REST - the
       fundamentals are the same in terms of schema, basic operations.
       This impacted most sections, in particular introduction and
       motivation.

   2.  Added new request types - blueprintsRequest, blueprintRequest and
       confsRequest.  The first replaces the optionsRequest and the
       latter allows the client to get a list of all active conferences.

   3.  Merged all requests into the basic operations table.  Added
       summary of RESTful examples (referenced by the basic operations
       table.

   4.  Added examples showing RESTful approach - i.e., HTTP methods for
       message exchange.

   5.  Removed requestID from the schema (it should be handle by the
       transport - e.g., HTTP).  Updated schema (based on current
       prototype - it still needs another revision.

   6.  Added placeholders for Notifications and Role Based Access
       Control.

   7.  Added some text for discovery using DNS (including IANA
       registrations)

   8.  Updated References: updated XCON FW RFC, SOAP/W3C moved to
       informational section.

16.

17.  References

16.1.

17.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.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 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.

   [I-D.ietf-xcon-common-data-model]
              Novo, O., Camarillo, G., Morgan, D., Even, R., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)",
              draft-ietf-xcon-common-data-model-12 draft-ietf-xcon-common-data-model-13
              (work in progress),
              October 2008.

16.2. April 2009.

17.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.

   [RFC3880]  Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
              Language (CPL): A Language for User Control of Internet
              Telephony Services", RFC 3880, October 2004.

   [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.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [I-D.ietf-xcon-event-package]
              Camarillo, G., Srinivasan, S., Even, R., and J.
              Urpalainen, "Conference Event Package Data Format
              Extension for Centralized Conferencing  (XCON)",
              draft-ietf-xcon-event-package-01 (work in progress),
              September 2008.

   [I-D.royer-calsch-xcal]
              Royer, D., "iCalendar in XML Format (xCal-Basic)",
              draft-royer-calsch-xcal-03 (work in progress),
              October 2005.

   [W3C.REC-soap12-part1-20030624]
              Gudgin, M., Hadley, M.,
              Mendelsohn, N., Gudgin, M., Nielsen, H., and
              J. Moreau, J., and
              M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
              World Wide Web Consortium FirstEdition REC-soap12-part1-
              20030624, June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.

   [W3C.REC-soap12-part2-20030624]
              Gudgin, M., Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and
              J. Moreau, J., and
              M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
              Web Consortium FirstEdition REC-soap12-part2-20030624,
              June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.

Appendix A.  Appendix A: Other protocol models and transports considered
             for CCMP

   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 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 the 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.

   Neither of these approaches were considered ideal as SOAP was not
   considered to be general purpose enough for use in a broad range of
   operational environments.  It is quite awkward to apply a RESTful
   approach since the 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 the CCMP, the same
   data in the server is used for both the 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.

A.1.  Using SOAP for the CCMP

   A remote procedure call (RPC) mechanism for the CCMP could use SOAP
   (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC
   -soap12-part2-20030624]), 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 the 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 [I-D.ietf-xcon-common-data-model].

   Following on the CRUD approach, CCMP could follow the well-known REST
   (REpresentational State Transfer) architectural style [REST].  The
   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.

   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.

Authors' Addresses

   Mary Barnes
   Nortel
   2201 Lakeside Blvd
   Richardson, TX

   Email: mary.barnes@nortel.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