XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Intended status: Standards Track                              C. Boulton
Expires: May 7, September 11, 2009                                               Avaya                              NS-Technologies
                                                             S P. Romano
                                                    University of Napoli
                                                          H. Schulzrinne
                                                     Columbia University
                                                        November 3, 2008
                                                          March 10, 2009

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 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 May 7, September 11, 2009.

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  . . . . . . . . . . . . . . . . . . . . . . . . .  5  6
   4.  Rationale and Motivation  Protocol Overview  . . . . . . . . . . . . . . . . . . .  5 . . .  7
   5.  System Architecture  . . . . . . . . . . . . . . . . . . . . .  7  8
   6.  Conference Object and User Identifiers . . . . . . . . . . . .  9 10
     6.1.  Conference Object  . . . . . . . . . . . . . . . . . . . .  9 10
     6.2.  Conference Users and Participants  . . . . . . . . . . . .  9 10
   7.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . . 10 12
     7.1.  Retrieve . . . . . . .  Implementation Approach  . . . . . . . . . . . . . . . . . . 10 13
     7.2.  Create  CCMP protocol messages . . . . . . . . . . . . . . . . . . 13
       7.2.1.  CCMP Request Message . . . . . . . . 11
     7.3.  Change . . . . . . . . . 13
       7.2.2.  CCMP Response Message  . . . . . . . . . . . . . . . . 14
         7.2.2.1.  CCMP Response Codes  . 12
     7.4.  Delete . . . . . . . . . . . . . . 15
       7.2.3.  Detailed CCMP Messages . . . . . . . . . . . . 12
   8.  Protocol Operations on Conference Objects . . . . 16
         7.2.3.1.  blueprintsRequest and blueprintsResponse
                   messages . . . . . . 13
     8.1.  Locating a Conference Control Server . . . . . . . . . . . 14
     8.2.  Constructing a CCMP Request . . . . 20
         7.2.3.2.  confsRequest and confsResponse messages  . . . . . 21
         7.2.3.3.  blueprintRequest and blueprintResponse messages  . 22
         7.2.3.4.  confRequest and confResponse messages  . . . . . 15
       8.2.1.  blueprintsRequest . 25
         7.2.3.5.  usersRequest and usersResponse messages  . . . . . 28
         7.2.3.6.  userRequest and userResponse messages  . . . . . . 31
         7.2.3.7.  sidebarsByValRequest and sidebarsByValResponse
                   messages . . . . . . 16
       8.2.2.  confsRequest . . . . . . . . . . . . . . . 33
         7.2.3.8.  sidebarByValRequest and sidebarByValResponse
                   messages . . . . . . 16
       8.2.3.  Operations Requests . . . . . . . . . . . . . . . 34
         7.2.3.9.  sidebarsByRefRequest and sidebarsByRefResponse
                   messages . . 16
     8.3.  Handling a CCMP Response . . . . . . . . . . . . . . . . . 18
       8.3.1.  blueprintsResponse . . 36
         7.2.3.10. sidebarByRefRequest and sidebarByRefResponse
                   messages . . . . . . . . . . . . . . . . 20
       8.3.2.  confsResponse . . . . . 37
   8.  A complete example of the CCMP in action . . . . . . . . . . . 40
     8.1.  Alice retrieves the available blueprints . . . . 20
       8.3.3.  Operation Responses . . . . . 40
     8.2.  Alice gets detailed information about a specific
           blueprint  . . . . . . . . . . . . 21
   9.  Managing sidebars . . . . . . . . . . . . 43
     8.3.  Alice creates a new conference through a cloning
           operation  . . . . . . . . . . 25
     9.1.  Sidebars by value . . . . . . . . . . . . . . . . . . . . 25
     9.2.  Sidebars by reference  . . . . . . . . . . . . . . . . . . 26
   10. Protocol Parameters  . . . . 45
     8.4.  Alice updates conference information . . . . . . . . . . . 47
     8.5.  Alice inserts a list of users in the conference object . . 49
     8.6.  Alice joins the conference . . . . 26
     10.1. Operation Parameter . . . . . . . . . . . . 51
     8.7.  Alice adds a new user to the conference  . . . . . . . 26
     10.2. ConfObjID Parameter . . 52
   9.  Locating a Conference Control Server . . . . . . . . . . . . . 55
   10. XML Schema . . . . 26
     10.3. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 27
     10.4. ResponseCode Parameter . . . 57
   11. Managing notifications . . . . . . . . . . . . . . . 27
     10.5. Blueprints Parameter . . . . . 69
   12. IANA Considerations  . . . . . . . . . . . . . . 28
     10.6. Conference-info Parameter . . . . . . . 70
     12.1. URN Sub-Namespace Registration . . . . . . . . . 28
     10.7. User Parameter . . . . . 70
     12.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 29
     10.8. Users Parameter 70
     12.3. MIME Media Type Registration for 'application/ccmp+xml'  . 71
     12.4. DNS Registrations  . . . . . . . . . . . . . . . . . . . . 29
     10.9. Sidebar Parameters 72
       12.4.1. Registration  of a Location Server Application
               Service Tag  . . . . . . . . . . . . . . . . . . . . 29
   11. Examples . 72
       12.4.2. Registration of a Location Server Application
               Protocol Tag for HELD  . . . . . . . . . . . . . . . . 72
     12.5. CCMP Protocol Registry . . . . . . . . . . 30
     11.1. HTTP methods for realizing a RESTful CCMP . . . . . . . . 30
     11.2. 73
       12.5.1. CCMP Detailed Message Body Examples  . . . . . . . Types . . . . 33
       11.2.1. Creating a New Conference . . . . . . . . . . . . . . 33
       11.2.2. Creating a New Conference User 73
       12.5.2. CCMP Response Codes  . . . . . . . . . . . . 36
       11.2.3. Adding a User to a Conference . . . . . 74
   13. Security Considerations  . . . . . . . 36
   12. XML Schema . . . . . . . . . . . . 76
   14. Acknowledgments  . . . . . . . . . . . . . . 37
   13. Managing notifications . . . . . . . . . 77
   15. Changes since last Version . . . . . . . . . . . 45
   14. Role based access control . . . . . . . 78
   16. References . . . . . . . . . . . 46
   15. IANA Considerations . . . . . . . . . . . . . . . 79
     16.1. Normative References . . . . . . 46
     15.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 79
     16.2. Informative References . 46
     15.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
     15.3. MIME Media Type Registration 79
   Appendix A.  Appendix A: Other protocol models and transports
                considered for 'application/ccmp+xml'  . 47
     15.4. DNS Registrations  . . . . . . . CCMP . . . . . . . . . . . . . 48
       15.4.1. Registration  of a Location Server Application
               Service Tag . . . . 81
     A.1.  Using SOAP for the CCMP  . . . . . . . . . . . . . . . . . 48
       15.4.2. Registration of a Location Server Application
               Protocol Tag 81
     A.2.  A RESTful approach for HELD  . . . . . . . . . the CCMP  . . . . . . . 48
     15.5. CCMP Protocol Registry . . . . . . 82
   Authors' Addresses . . . . . . . . . . . . 49
       15.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 49
       15.5.2. CCMP Response Codes  . . . . . . . . . . . . . . . . . 50
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 51
   17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 51
   18. Changes since last Version . . . . . . . . . . . . . . . . . . 51
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 52
     19.2. Informative References . . . . . . . . . . . . . . . . . . 52
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
   Intellectual Property and Copyright Statements . . . . . . . . . . 55 83

1.  Introduction

   The Framework for Centralized Conferencing [RFC5239] (XCON FW) Framework)
   defines a signaling-agnostic framework, naming conventions and
   logical entities required for building advanced conferencing systems.
   The XCON FW 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 FW,
   Framework, with the conferencing client and conference control server
   acting as client and server, respectively.  The CCMP is an instance of conference control
   protocol (CCP).

   CCMP can be mapped into uses HTTP
   [RFC2616] as the CRUD (Create, Read, Update, Delete)
   design pattern.  The basic CRUD operations are used protocol to manipulate
   conference objects, transfer the CCMP requests and
   responses, which are XML documents containing contain 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.

   CCMP can 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 (XCON Data Model) [I-D.ietf-xcon-common-data-model].

   CCMP follows
   Other protocol models such as the well-known use of a REST (REpresentational
   State Transfer) architectural style [REST] This document describes how were considered.  However,
   the CCMP
   specification maps onto the REST philosophy, by specifying resource
   URIs, resource formats, methods supported at each URI and status
   codes that have is a request/response protocol with new or updated data
   relevant to be the specific conference object returned when in the response.
   Whereas, a certain method is invoked 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 URI.
   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 motivates 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, with 7.  A complete example of the sequence
   operation of protocol requests and
   responses discussed in Section 8 the CCMP, describing a typical call flow associated with
   conference creation and examples manipulation, is provided in Section 11.
   The protocol parameters are detailed in Section 10. 8.
   Section 12 10 provides the XML schema.

2.  Conventions

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

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].
   W3C:  World Wide Web Consortium, the organization that developed the
      SOAP and WSDL specifications referenced within this document.

4.  Rationale and Motivation  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, the conference itself, users, and sidebars.

   The operations on these objects can be implemented

   Each update operation in at least two
   different ways, namely as remote procedure calls and by defining
   resources.  A remote procedure call (RPC) mechanism 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.

   Alternatively, conference objects can 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 a natural
   URIs.

   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.  The coarser-grained approach in 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.

   We assume that each update operation is atomic protocol model is atomic and either
   succeeds or fails as a whole.  Thus, a server has to first check all
   parameters, before making any changes to the internal representation
   of the conference object.  For example, it would be undesirable to
   change the <subject> of the conference, but then detect an invalid
   URI in one of the <service-uris> and abort the remaining updates.

   Because multiple clients can modify the same conference objects,
   clients need to obtain the current object and then update the whole
   object.

   Editor's Note: Do we need locking, using WebDAV or floor control?
   Otherwise, changes made by user A could get lost when user B wants to
   modify some other parameter.  For example, A changes the subject, B
   adds the a service URI.

   In summary, a REST-style approach must ensure sure that all
   operations can be mapped to HTTP operations, while 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.

   For CCMP, the resource (REST) model appears more attractive, since
   the conference operations fit the CRUD approach.

   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 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 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 for centralized conferencing. .  Figure 1 depicts a subset of the
   'Conferencing System Logical Decomposition' architecture from the
   XCON framework for centralized conferencing 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 for centralized conferencing document 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,
   participant or users 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.  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

   The primary function of the protocol defined within this document

   CCMP is a client-server, XML-based, stateless protocol, which has
   been specifically conceived to provide a conference control client users with the ability to carry out
   operations on a conference object as a whole and on specific elements
   within a conference object.  This section describes necessary means
   for the four basic
   operations on a conference object: retrieve, create, change creation, retrieval, modification and
   delete.  The recommended HTTP method for each deletion of the basic operations conference
   objects.  Conference-related information is described.  The XCON-URI as discussed encapsulated into CCMP
   messages in Section 6.1 is the
   primary target for each of these operations.  The normative protocol
   details as to the applicability of each form of documents or document fragments compliant
   with the XCON data model representation.

   The main operations for the
   various CCMP requests and responses are provided in Section 8.

7.1.  Retrieve

   The "retrieve" operation is used by a client to query a system for a
   specific template CCMP belong in the form of a blueprint prior to four general
   categories:

   create:  for the creation of a conference.  In this case, the "retrieve" operation often follows conference, a
   "blueprintsRequest" operation, although conference user, a conferencing control client
   may be pre-configured to perform the "retrieve" operation on
      sidebar, or a
   specific blueprint.

   The "retrieve" operation is also used

   retrieve:  to get information about the current
   representation state of either a specific
      conference object (or specific
   parameters in the (be it an actual conference object) for or a conference reservation blueprint, or
   an active conference.  The unique a
      sidebar) or a conference identifier (XCON-URI) is
   included in the CCMP request.

   The "retrieve" user.  A retrieve operation returns can also be
      used to obtain the XML document describing XCON-URIs of the active conferences and/or
      blueprints available at the server.

   update:  to modify the
   conference object in its current state including all inherited values features of a specified conference or
      conference user.

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

   Thus, the specific request type.  Elements
   may be marked by attributes, in particular, whether they are specific
   to this instance or have been inherited from the parent node.

   In the case main targets of a RESTful implementation of the protocol, HTTP GET
   MUST be used on XCON-URIs, so that clients can obtain data about CCMP operations are:

   o  conference objects in the form of XML data model documents.

7.2.  Create

   The "create" operation is used by a client to create and reserve a
   conference object associated with either active or a new conference user.  The creation of a
   conference object can be explicit by requesting it to be created
   based upon a specific blueprint, based on an existing conference
   object (e.g., cloning a registered
      conferences,

   o  conference reservation or active objects associated with blueprints,

   o  conference
   object) or based on the data included in the request.  In the first
   two cases, a specific XCON-URI MUST be included objects associated with sidebars, both embedded in the request.

   When the creation of a
      main conference object is implicit, (i.e. <sidebars-by-value> elements) and external
      to it (i.e. <sidebars-by-ref> elements),

   o  <user> elements associated with no
   conference object for a blueprint or existing conference specified
   and no data included in users,

   o  the request (i.e., an "empty" request sent 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 specific conference server), number of different proposals as to the creation and reservation most
   suitable implementation solution for the CCMP.  A non-exhaustive
   summary of the
   conference instance most interesting ones is based on the default conference object. provided in Appendix A.  The
   default conference object
   proposed solution for the CCMP is specific to viewed as a conference control server good compromise amongst
   the most notable past candidates and its specification is outside the scope of referred to as 'HTTP single
   verb transport plus CCMP body'.  With this document.

   A client may first send a request with "retrieve" operation in order approach, CCMP is able to obtain all
   take advantage of existing HTTP functionality.  As with SOAP, the data
   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 defined with any
   RESTful approach, CCMP messages are inserted directly in
   [I-D.ietf-xcon-common-data-model] for the specific blueprint or
   existing conference object.  This would allow the client to modify
   the data prior to sending the request body of
   HTTP messages, thus avoiding any unnecessary processing and
   communication burden associated with the "create" operation.
   In further intermediaries.  With
   this case, the request would also include all the data.  If the
   client wants to create the new conference by cloning the blueprint or
   existing conference object, there would be approach, no data included in modification to the
   request. CCMP messages/operations is
   required to use a different transport protocol.

   The client may later modify remainder of this data by sending a request
   with a "change" operation.

   When creating conferences, any XCON-URI included by the client is
   considered as document focuses on the target conference object from which selected approach.  The
   CCMP protocol inserts XML-based CCMP requests into the new
   conference is to be created.  To avoid identifier collisions body of HTTP
   POST operations and to
   conform to local server policy, retrieves responses from the conference control server
   typically chooses body of HTTP '200
   OK' messages.  CCMP messages have a different identifier for MIME-type of "application/
   ccmp+xml", which appears inside the newly created
   conference object. "Content-Type" and "Accept"
   fields of HTTP requests and responses.

7.2.  CCMP protocol messages

   CCMP messages are either requests or responses.  The identifier general CCMP
   request message is returned defined in Section 7.2.1.  The general CCMP
   response message is defined in Section 7.2.2.  The details of the response.

   In addition, the conference description MAY contain a calendar
   element,
   specific message type which is carried in the iCal format in XML rendition defined CCMP request and
   response messages are described in CPL [RFC3880]
   or (preferable, if available as stable reference) xCal
   [I-D.royer-calsch-xcal].  This description indicates when the
   conference Section 7.2.3.

7.2.1.  CCMP Request Message

   A CCMP request message is active.

   The "create" operation may also be used to create a new conference
   user with the "userRequest" message.  In this case, the
   "userResponse" to this operation includes an XCON-USERID.

   In the case of a RESTful implementation comprised of the protocol, HTTP PUT
   MUST be used to create a new object as identified by the XCON-URI or
   XCON-USERID.

7.3.  Change

   The "change" operation updates the conference object as referenced by
   the XCON-URI included in the request. following parameters:

   confUserId:  A request which attempts to
   change a non-existing object is an error, as is a request which
   attempts to change a mandatory parameter that is inherited from a protected
   element.

   During containing the lifetime XCON-URI of a conference, this operation the
      client.  This parameter is used REQUIRED by a
   conference control client to manipulate a conference object.  This
   includes the ability to manipulate conferencing server for
      system specific elements in Authorization, Authentication and Accounting (AAA)
      procedures.

   confObjId:  an optional parameter containing, whenever necessary, the
   conference object through element specific requests such as
   "userRequest" or "sideBarRequest", etc.

   Upon receipt
      XCON-URI of a "change" operation, the target conference control server
   updates the specific elements in object;
   specialized request message:  this is specialization of the referenced conference object.
   Object properties generic
      request message (e.g., blueprintsRequest), containing parameters
      that are not explicitly changed, remain as-is.
   This approach allows a conference control client dependent on the specific request sent to manipulate
   objects created by another application even if the manipulating
   application does not understand all object properties.

   In server, the case of a RESTful implementation
      details of the protocol, either HTTP
   PATCH or HTTP POST MUST be used to change the conference object
   identified by the XCON-URI.

7.4.  Delete

   This conference control operation which are provided in Section 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" maxOccurs="1" />
                   <xs:element name="confObjID" 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 used to delete the current
   representation comprised of a conference object or a specific parameter in the
   conference object and requires following parameters:

   confUserId:  A mandatory parameter containing the unique conference identifier
   (XCON-URI) be provided by XCON-URI of the client.

   A request
      client which attempts to delete a conference object that is being
   referenced by a child object is an error.

   In case of a RESTful implementation of issued the protocol, HTTP DELETE MUST
   be used to delete conference objects and parameters within conference
   objects identified by request

   confObjId:  An optional parameter containing the XCON-URI.

8.  Protocol Operations on Conference Objects

   The primary function XCON-URI of CCMP is to provide a conference control
   client with the ability to carry out specific operations (Section 7)
   on a
      target conference object through
   responseCode:  A mandatory parameter containing the protocol requests and responses.
   In case of a RESTful implementation of response code
      associated with the protocol, request, chosen among the CCMP
   requests (Section 8.2)and responses (Section 8.3) MUST be represented
   as HTTP requests and responses.  The basic CCMP request/response
   pairs defined codes listed in this document are:

   blueprintsRequest/blueprintsResponse:  The blueprintsRequest
      Section 7.2.2.1

   specialized response message:  This is used specialization of the generic
      response message, containing parameters that are dependent on the
      specific request sent to ascertain the list of blueprints available at server(e.g., blueprintsResponse), the conference
      server.  The blueprintsResponse returns a list
      details of the requested
      blueprints, which are provided in the form Section 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 XCON URIs.
   confsRequest/confsResponse: ccmp-response-message-type -->

      <xs:complexType abstract="true"
           name="ccmp-response-message-type">
           <xs:sequence>
                   <xs:element name="confUserID" type="xs:string"
                           minOccurs="0" maxOccurs="1" />
                   <xs:element name="confObjID" type="xs:string"
                           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 confsRequest is used to ascertain
      conference reservations and active conferences supported by
   following summarizes the
      server.  The confsResponse returns a list CCMP response codes:

   success:  Successful completion of the requested types operation.

   modified:  Successful completion of conference objects (i.e.  Conference Reservations and/or Active
      Conferences) supported by the specific conference server.
   blueprintRequest/blueprintResponse:  The blueprintRequest is used to 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 an

   objectNotFound:  Target object missing at the server

   unauthorized:  User not allowed to perform the required operation on

   forbidden:  Operation not allowed (e.g., cancellation of a specific blueprint.
   confRequest/confResponse:  The confRequest is used to request an blueprint)

   forbiddenDeleteParent:  Cancel operation on failed since the conference target
      object as a whole.
   userRequest/userResponse:  The userRequest is used to request an
      operation a parent of child objects which depend on it, or because
      it effects, based on the "user" 'parent-enforceable' mechanism, the
      corresponding element in a child object

   forbiddenChangeProtected:  Update refused by the conference object.
      [Editor's Note: we may want server because the
      target element cannot be modified due to add more discrete user requests/
      responses as this is its implicit dependence
      on the value of a very broad parameter]
   usersRequest/usersResponse:  This usersRequest is used parent object ('parent-enforceable' mechanism)

   requestTimeout:  The time required to manipulate serve the "users" element in request has exceeded
      the conference object, including parameters
      such as the allowed-users-list, join-handling, etc.
   sidebarRequest/sidebarResponse:  This sidebarRequest is used to
      retrieve envisaged service threshold

   serverInternalError:  The server cannot complete the information related to a sidebar or required service
      due to create, change
      or delete a specific sidebar.  [Editor's Note: system internal error

   notImplemented:  Operation envisaged in the data model
      defines a byVal protocol, but not
      implemented in the contacted server.

7.2.3.  Detailed CCMP Messages

   Based on the request and byRef sidebar type.  Rather than define two
      root operations, response message structures described in
   Section 7.2.1 and Section 7.2.2, the preference is to have these two following summarizes the
   specialized CCMP request/response types
      reflected by a parameter 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 request.]

   With respect fundamental CCMP operations
   as defined in Section 7 to manipulate the above mentioned operations, we remark that conference data.  Table 1
   summarizes the
   difference between "blueprintsRequest" CCMP operations and "confsRequest" only exists
   at the semantic level.  They both ask corresponding actions that are
   valid for a list of XCON-URIs and
   they have exactly the same format.  The returned XCON-URIs, though,
   represent blueprints in specific CCMP request type, noting that neither the former case, real (i.e. either active
   blueprintsRequest/blueprints/Response or
   reserved) conferences in the latter. confsRequest/ConfsResponse
   require an "operation" parameter.  The fact that blueprints and
   conferences share corresponding response MUST
   contain the same representation (a conference object
   compliant with operation.  Note that some entries are labeled "N/A"
   indicating the XCON data model) operation is a mere coincidence.  The same
   holds for "confRequest/blueprintRequest", which aim at managing,
   respectively, a specific conference object and a specific blueprint.

   To simplify operations, a conference control server treats certain
   parameters as suggestions (e.g., invalid for that request type.  In the "create" and "change"
   operations), as noted in the object description.  If the conference
   control server cannot set the parameter to
   case of an "N/A*", the values desired, it
   picks operation MAY be allowed for specific
   privileged users or system administrators, but is not part of the next best value, according to local policy and returns the
   values selected in the response.  If the client is not satisfied with
   these values, it simply deletes the object.

   As illustrated above, along with the protocol requests and responses
   for manipulating the conference object, there are also querying
   mechanisms ("blueprintsRequest"/"blueprintsResponse" and
   "confsRequest/confsResponse") to get information about either
   blueprints or scheduled/active conferences supported by the server.
   Any elements with namespaces not understood by the server are to be
   ignored by the server.  This allows a client to include optional
   elements
   functionality included in requests without having to tailor its request to the
   capabilities this document.

   +---------------+------------+------------+------------+------------+
   | Operation     |  Retrieve  |   Create   |   Update   |   Delete   |
   | ------------- |            |            |            |            |
   | -Request Type |            |            |            |            |
   +---------------+------------+------------+------------+------------+
   | blueprintsReq |  Get list  |     N/A    |     N/A    |     N/A    |
   | uest          |     of each server.

   A conference client must first discover the conference control server
   as described in Section 8.1.  The conference control server is the
   recipient     |            |            |            |
   |               | blueprints |            |            |            |
   |               | .          |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | blueprintRequ |     Get    |    N/A*    |    N/A*    |    N/A*    |
   | est           | blueprint. |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | confsRequest  |  Get list  |     N/A    |     N/A    |     N/A    |
   |               |     of the CCMP requests.

8.1.  Locating a Conference Control Server

   If a     |            |            |            |
   |               | conference control client is not pre-configured to use a
   specific conference control server for the requests, the 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 locate the conferencing
   server.  U-NAPTR resolution for conferencing takes a domain name as
   input and produces a URI that identifies the 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 15.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 15.4.2, is used to identify an XCON server that understands
   the CCMP protocol.

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

             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 2: Sample XCON:CCMP Service NAPTR Records

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

8.2.  Constructing a CCMP Request

   Construction of a valid CCMP request is based upon the operations
   defined in Section 7, depending upon the function and associated
   information desired by the conference control client.  The next two
   sections provide details of the "blueprintsRequest" and
   "confsRequest" messages, which differ from the other CCMP messages in
   that they are only used to ask the conference system for general
   information (blueprints and conferences).  Subsequent sections
   summarize the CCMP requests related to the specific operations in
   Section 7.

8.2.1.  blueprintsRequest

   The "blueprintsRequest" is used by a client to query a system for its
   capabilities in terms of types of conferences supported and isn't
   targeted toward a particular conference object.  Detailed information
   about a specific blueprint, can be subsequently obtained through the
   blueprintRequest operation, which is used to retrieve a whole XCON
   blueprint (in the form of a conference object) available at the
   server.

   The "blueprintsResponse" returns the XML namespaces that the server
   understands and the namespaces to be used in responses that it
   requires the client to understand.  Within the conferencing system,
   the namespaces correlate with blueprints, as specified in the XCON
   framework.  The blueprints are comprised of conference information
   initialized to specific values and ranges.  Each blueprint has a
   corresponding XCON-URI.

8.2.2.  confsRequest

   The "confsRequest" is used by a client to query a system for
   information about reserved/active conferences and isn't targeted
   toward a particular conference object.  Detailed information about a
   specific conference, can be subsequently obtained through the
   confRequest operation, which can be used to retrieve a whole XCON
   conference (in the form of a conference object) available at the
   server.

   The "confsResponse" returns the XCON-URIs of all reserved and active
   conferences currently hosted by the server.

8.2.3.  Operations Requests

   Construction of other valid CCMP requests is based upon the
   operations defined in Section 7, depending upon the function and
   associated information desired by the conference control client.  The
   following table summarizes specific request type and processing for
   each of the "operations".  A value of "N/A" indicates the specific
   operation is not valid for the specific CCMP request.  Following the
   table examples for each of the HTTP operations for each of the
   request types is provided.

   Editors' Notes:

   1.  Sidebars need additional consideration - e.g., due to the byVal
       and byRef options, it's messy.  Operations approach may need
       additional consideration (or we need separate request types).

   +---------------+------------+------------+------------+------------+
   | Operation     |  Retrieve  |   Create   |   Change   |   Delete   |
   | (HTTP method) |    (GET)   |    (PUT)   |  (PATCH or |  (DELETE)  |
   | ------------- |            |            |    POST)   |            |
   | Request Type  |            |            |            |            |
   +---------------+------------+------------+------------+------------+
   | blueprintsReq |  Gets list |     N/A    |     N/A    |     N/A    |
   | uest          |     of     |            |            |            |
   |               |  available |            |            |            |
   |               | blueprints |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | confsRequest  |  Gets list |     N/A    |     N/A    |     N/A    |
   |               |  of active |            |            |            |
   |               |     or     |            |            |            |
   |               |  reserved  |            |            |            |
   |               |    confs   |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | blueprintRequ |   Gets a   |  Creates a |  Changes a |  Deletes a |
   | est           |  specific  |  blueprint |  blueprint |  blueprint |
   |               |  blueprint |   (needs   |   (needs   |   (needs   |
   |               |            |    admin   |    admin   |    admin   |
   |               |            | privileges | privileges | privileges |
   |               |            | )          | )          | )          |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | confRequest   |    Gets    |   Creates  |   Changes  |   Deletes  |
   |               | conference | conference | conference | conference |
   |               |   object   |   object   |   object   |  Object as |
   |               |            |            |            |   a whole  |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | userRequest   |   Gets a   |  Creates a |  Modifies  |  Deletes a |
   |               |  specific  |  user and  |     the    |    user    |
   |               |    user    | associated |  specified | element as |
   |               |   element  | XCON-UserI |    user    |   a whole  |
   |               |            | D          |   element  |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | usersRequest  |   Gets a   |     N/A    |  Modifies  |  Deletes a |
   |               |  specific  |            |     the    |    users   |
   |               |    users   |            |  specified | element as |
   |               |   element  |            |    users   |   a whole  |
   |               |            |            |   element  |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarReques |   Gets a   |  Creates a | Modifies a | Removes/de |
   | t             |   sidebar  |     new    | sidebar by | l etes the |
   |               | element by | sidebar by |     Val    |    entire  |
   |               |  Val or by |     Val    |            |  sidebar b |
   |               |     Ref    |            |            | y    Val   |
   +---------------+------------+------------+------------+------------+

            Table 1: Request Type Operation Specific Processing

   The following provides HTTP examples for each of the valid operations
   for each request type in the above table Table 1

   o  blueprintsRequest: GET /blueprints
   o  confsRequest: GET /confs
   o  blueprintRequest
      *  GET /blueprint/blueprintId
      *  PUT /blueprint/blueprintId
      *  POST /blueprint/blueprintId
      *  DELETE /blueprint/blueprintId
   o  confRequest
      *  GET /confs/confObjId
      *  PUT /confs/confObjId
      *  POST /confs/confObjId
      *  DELETE /confs/confObjId
   o  userRequest
      *  GET /user/confUserId
      *  PUT /user/confUserId
      *  POST /user/confUserId
      *  DELETE /user/confUserId
   o  usersRequest
      *  GET /confs/confObjId/users
      *  POST /confs/confObjId/users
      *  DELETE /confs/confObjId/users
   o  sidebarRequest
      *  By val: GET /confs/confObjId/sidebars/entityAttribute
      *  By val: N/A (use a "confRequest" message with a "change"
         operation for this)
      *  By val: N/A (use a "confRequest" message with a "change"
         operation for this)
      *  By val: N/A (use a "confRequest" message with a "change"
         operation for this)
      *  By ref: GET /sidebars/sidebarId

8.3.  Handling a CCMP Response

   A response to the CCMP request MUST contain a response code and may
   contain other elements depending upon the specific request and the
   value of the response code.

   In case of a RESTful implementation, the CCMP response message MUST
   be enclosed in a HTTP response message.  CCMP-related error codes
   will be carried in the body of the response: no mapping is proposed
   in this document regarding the potential association between CCMP and
   HTTP error codes.  For the sake of adhering to the principle of
   separation of concerns, HTTP maintains its own semantics, while
   delegating to the CCMP response message (which is in the body of the
   HTTP response) the task of informing the CCMP client about error
   conditions.  This means that, in case of a CCMP error, the client
   receives a 200 OK in the HTTP response, but a CCMP-specific response
   code in the body of such response.

   All response codes are application-level, and MUST only be provided
   in successfully processed transport-level responses.  For example
   where HTTP is used, CCMP Response messages MUST be accompanied by a
   200 OK HTTP response.

   The set of CCMP Response codes currently contain the following
   tokens:

   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 |            |            |            |
   |               | s (active, |            |            |            |
   |               |     etc.)  |            |            |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | confRequest   |    Gets    |   Creates  |   Changes  |   Deletes  |
   |               | 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 | conference |
   |               |  object was not found.
   operationNotAllowed:  This code indicates that the or |   object   |   object   |  Object as |
   |               | blueprint. |            |            |  a whole.  |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | usersRequest  |   Gets a   |     N/A    |   Adds or  |     N/A    |
   |               |  specific operation
      is not allowed for  |            |  modifies  |            |
   |               |    users   |            |     the target conference object (e.g.., when
      trying to make    |            |
   |               |  element.  |            |  specified |            |
   |               |            |            |    users   |            |
   |               |            |            |  element.  |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | userRequest   |   Gets a "confRequest" operation with   |   Creates  |   Adds or  |  Deletes a request type equal
      to "delete" on |
   |               |  specific  | XCON-UserI |  modifies  |    user    |
   |               |    user    | D     .    |     the    | element as |
   |               |  element.  |            |  specified |  a conference object representing whole.  |
   |               |            |            |    user    |            |
   |               |            |            |  element.  |            |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | 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 blueprint, etc.)
   deleteFailedParent:  This code indicates that the conferencing system
      cannot delete the specific conference object because it is   |     N/A    |   Adds or  | Removes/de |
   | equest        |   sidebar  |            | modifies 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 | l etes the request could not be
      processed within |
   |               |  element.  |            |  sidebar.  |    entire  |
   |               |            |            |            |   sidebar. |
   |               |            |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   |               |            |            |            |            |
   | sidebarByRefR |   Gets a reasonable time, with the time specific to   |     N/A    |   Adds or  | Removes/de |
   | equest        |   sidebar  |            | modifies a
      conferencing system implementation.

   serverInternalError:  This code indicates that | l etes the conferencing
      system experienced some sort of internal error.
   notImplemented:  This code indicates that |
   |               |  element.  |            |  sidebar.  |    entire  |
   |               |            |            |            |   sidebar. |
   +---------------+------------+------------+------------+------------+

            Table 1: Request Type Operation Specific Processing

   The following additional parameters are included in the specific operation is
      not implemented on that conferencing system. specialized
   CCMP Response codes are defined to allow for extensibility.  A
   conference control client SHOULD treat unrecognized response codes as
   it handles a Response code of "notImplemented".

8.3.1.  blueprintsResponse

   A "blueprintsResponse" message containing a response code of
   "success" MUST include request/response messages detailed in the XML namespaces that subsequent sections:

   operation:  An optional parameter for each CCMP request/response
      message.  This parameter is REQUIRED in all messages except for
      the server understands "blueprintRequest", "blueprintResponse", "confsRequest" and the namespaces to be
      "confsResponse" messages.

   blueprintInfo:  An optional parameter used in subsequent responses that it
   requires the client to understand.  Future work may add more global
   capabilities rather than conferencing system specific.  Within the
   conferencing system, for the namespaces correlate with blueprints, blueprintResponse
      message.  It is of type "conference-type" as
   specified defined in the XCON framework.  The blueprints are comprised of
   conference information initialized to specific values and ranges.

   Upon receipt of a successful "blueprintsResponse" message, a
   conference control client may then initiate a "blueprintRequest" with
   a "retrieve" operation per Section 7.1 to get a specific conference
   blueprint.

   In the case of a response code of "requestTimeout", a conference
   control client MAY re-attempt the request within a period of time
   that would be specific to a conference control client or conference
   control server.

   The response codes of "modified", "deleteParentFailed" and
   "changeFailedProtected" are not applicable to a "blueprintsRequest"
      data model and should be treated as "serverInternalError", contains the handling data of which
   is specific to the conference control client.

   A "blueprintsResponse" message containing object
      representing the blueprint in the conference server.  This
      parameter SHOULD not be included in any other response code is
   an error type
      messages and the handling is specific to the conference control
   client.  Typically, an error for a "blueprintsRequest" indicates a
   configuration problem SHOULD only be included in the conference control server a "create", "update" or in the
   client.

8.3.2.  confsResponse

   A "confsResponse"
      "delete" operation for a blueprintRequest message containing in special cases
      where a response code of "success"
   MUST include user has special privileges such as an administrator.

   blueprintsInfo:  An optional parameter used for the
      blueprintsResponse message.  It contains a list of XCON-URIs associated with reserved/active
   conferences at the server.

   Upon receipt elements of
      type "blueprintInfo".  This parameter SHOULD not be included in
      any other response type messages and SHOULD only be included in a successful "confsResponse" message, a conference
   control client may then initiate a "confRequest" with a "retrieve"
      "create", "update" or "delete" operation per Section 7.1 to get a specific conference object.

   In the case of for a response code of "requestTimeout", blueprintRequest
      message in special cases where a conference
   control client MAY re-attempt user has special privileges such
      as an administrator.

   confsInfo:  An optional parameter used for the request within confsResponse message.
      It contains a period list of time
   that would XCON-URIs.  This parameter SHOULD not be specific to a conference control client or conference
   control server.

   The
      included in any other response codes of "modified", "deleteParentFailed" type messages and
   "changeFailedProtected" are not applicable to SHOULD only be
      included in a "confsRequest" "create", "update" or "delete" operation for a
      blueprintRequest message in special cases where a user has special
      privileges such as an administrator.

   usersInfo:  An OPTIONAL parameter that MAY be included in a
      usersRequest and
   should be treated as "serverInternalError", usersReponse message, depending upon the handling
      operation.  The 'usersInfo' parameter carries an object compliant
      with the <users> field of which is
   specific to the conference control client. XCON data model.

7.2.3.1.  blueprintsRequest and blueprintsResponse messages

   A "confsResponse" 'blueprintsRequest' (Figure 4) message containing any other response code is an
   error and the handling is specific sent to request the conference control client.
   Typically, an error for a "blueprintsRequest" indicates a
   configuration problem in the conference control server or in the
   client.

8.3.3.  Operation Responses

   The following sections detail the operation specific handling list
   of the
   response codes, including details XCON-URIs associated with specific types of
   responses in the cases where the response handling is not generic.

8.3.3.1.  Retrieve Operation Responses

   A confResponse for a "retrieve" operation containing a response code
   of "success" MUST contain the full XML document describing available blueprints from the
   conference object in its current state including all inherited
   values.  Elements may server.  Such URIs can be marked subsequently used by attributes, in particular, whether
   they are specific to this instance or have been inherited from the
   parent node. client
   to access detailed information about a specified blueprint with a
   specific 'blueprintRequest' message per Section 7.2.3.3.  A blueprintResponse
   'blueprintsRequest' message REQUIRES no additional parameters beyond
   those specified for the basic CCMP request message.  The associated
   'blueprintsResponse' message SHOULD contain, as shown in Figure 4, a "retrieve" operation
   'blueprintsInfo' parameter containing a the above mentioned XCON-URI
   list.  The 'confObjId' parameter is NOT REQUIRED in the request or
   response
   code for 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 "success" MUST contain the full XML document describing blueprintsRequest and blueprintsResponse
                                 messages

7.2.3.2.  confsRequest and confsResponse messages

   A 'confsRequest' message is used to retrieve, from the server, the
   conference object
   list of XCON-URIs associated with active and registered conferences A
   'confsRequest' message REQUIRES no additional parameters beyond those
   specified for the requested blueprint

   Any other basic CCMP response request message.  The associated
   'confsResponse' message (e.g., userResponse, usersResponse,
   etc.) for a "retrieve" operation containing a response code of
   "success" MUST SHOULD contain the XML document describing the specific
   target parameter (as indicated by the specific type of Request) from
   the conference object.

   If a response code list of "objectNotFound" is received XCON-URIs in a
   "blueprintResponse" message to a "blueprintRequest" to get the
   initial blueprint, it
   'confsInfo' parameter.  The 'confObjId' parameter 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 NOT REQUIRED for the specific conferencing
   system.  If
   this "blueprintsResponse" message contains no blueprints, transaction.  A user, upon receipt of the handling is specific to response message, can
   interact with the available conference control client.  This
   might indicate, for example, that something objects through further CCMP
   messages.  The 'confsRequest' message is going wrong at the
   server, of a "retrieve-only" type,
   since no more blueprints are now the sole purpose is to collect information available at it.  In such
   case, the client MAY interpret the new answer as a
   'serverInternalError' and assume that no more service associated with
   blueprints (e.g. creation of a new
   conference starting from a server-
   side template) is available.

   If server.  Thus, an 'operation' parameter SHOULD NOT be
   included in a response code '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 of "requestTimeout" is received in the CCMP
   response, confsRequest and confsResponse messages

7.2.3.3.  blueprintRequest and blueprintResponse messages

   Through a 'blueprintRequest', a conference control client MAY re-attempt can manipulate the conference
   object associated with a specified blueprint.  The request
   within MUST
   include an 'operation' parameter and a period of time that would 'confObjId' parameter.  Only
   the "retrieve" 'operation' SHOULD should be specific to included in a conference
   control client or conference control server.

   Response codes such as "notImplemented"
   'blueprintRequest message.  The 'create', 'update' and "forbidden" indicate that
   a subsequent "retrieve" would not likely 'delete'
   operations SHOULD NOT be sucessful.  Handling included in a 'blueprintRequest' message
   except in the case of
   these and other response codes is specific to privileged users (e.g. the conference control
   client.  For example, in 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 some clients responseCode of "success" for a
   "blueprintsRequest" operation might 'retrieve' operation,
   the 'blueprintInfo' parameter SHOULD be performed again or another included in the
   'blueprintResponse' message.  Inside responses, the 'blueprintInfo'
   parameter carries the conference control server may be accessed.

   The response codes document associated with the
   blueprint specified in the request.

   <!--  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>

   <!-- 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 "modified", "deleteParentFailed" and
   "changeFailedProtected" are not applicable to the "retrieve"
   operation blueprintRequest and SHOULD 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 and/or 'confInfo' parameter MAY be treated as "serverInternalError", included.
   The 'confObjId' parameter contains the
   handling XCON-URI of which is the specific to
   active or registered conference.  The 'confInfo' parameter contains
   the conference control client.

8.3.3.2.  Create Operation Responses

   The only valid responses containing a "create" operation are a
   "confResponse", a "blueprintResponse" and data that is the "userResponse".  The
   "blueprintRequest" containing a "create" operation has to be
   considered a special operation, used by target of the 'confRequest' - i.e.
   the <conference-info> document (compliant with the XCON data model
   structure).

   To create a new conference server
   administrator wishing to remotely add through a new '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
   conference server.  The operation requires that
       'confInfo' parameter SHOULD NOT be included in the new blueprint is
   associated with an XCON-URI.  Such URI is provided by request;

   2.  Creation through implicit cloning (also known as "direct
       creation"): the
   administrator 'confObjId' parameter SHOULD NOT be included in
       the request, but has whereas the 'confInfo' parameter describing the
       conference to be considered as a
   suggestion.  The conference server MAY change such identifier and
   create a new one.  The new identifier created MUST be returned to included in the client
   as part request.

   In both cases, a successful completion of the "blueprintResponse" message.  If the CCMP response
   contains request carries back a response code
   responseCode of "success", a "confResponse" message MUST
   contain 'success' and SHOULD contain, in the 'confObjId'
   parameter, the XCON-URI for of the created conference.  In addition, the
   'confInfo' parameter transporting the created conference document
   SHOULD be included.  Obviously, the newly created object and a "userResponse"
   message MUST contain can be
   manipulated by the XCON-USERID.

   If client through subsequent 'update' operations.

   In the confResponse to a "create" operation contains a response code case of "modified", along with 'retrieve' or 'delete' operations, the 'confObjId'
   representing the XCON-URI for of the target conference object, the
   response MUST also contain be included
   and the entire XML document associated with
   that conference object for 'confInfo' SHOULD NOT be included in the request.  Inside the
   response to a "confRequest".  For example, 'retrieve' request, in case of responseCode of
   'success', the case
   where 'confInfo' containing a description of the target
   conference object contained a calendar element, MUST be included.  On the
   conference server may only offer other hand, a subset of response to
   a 'delete' operation SHOULD NOT include the dates requested,
   thus 'confInfo' parameter.

   In case of an 'update' operation, the updated dates are 'confInfo' and 'confObjID MUST
   be included in the returned XML document. 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 response code
   responseCode of "requestTimeout", a conference
   control client MAY re-attempt success, no additional information is REQUIRED in the request within
   'confResponse'message.  For a period successful response, the conference
   server should consider as unchanged all parts of time
   that would be specific to a the referenced
   conference control client or document.  However, if the target conference
   control server.

   Response codes such object has
   not been modified exactly as "unauthorized", "forbidden" and
   "operationNotAllowed" indicate required by the client does not the responsecode
   MUST be set to 'modified' and the 'confInfo' parameter MUST contain
   the entire conference document to which the required changes have
   been (at least partially) applied.

   The schema for the
   appropriate permissions, there confRequest/confResponse pair is an error 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="operation" type="operationType"
                    minOccurs="1" maxOccurs="1" />
        <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 permissions, or
   there is a system error in confRequest and confResponse messages
   The following provides an example of the client or 'confInfo' parameter
   required to change the title of a conference:

   <conf-info entity="123">
           <conference-description>
                   <display-text>New conference control server,
   thus re-attempting title</display-text>
           </conference-description>
   </conf-info>

     Figure 8: Updating a conference object: modifying the request would likely not succeed.

   The response codes title of "deleteParentFailed" and
   "changeFailedProtected" are not applicable a
                                conference

   Similarly, to remove the "create" title of an existing conference, an 'update'
   operation
   and SHOULD be treated as "serverInternalError", carrying the handling of which
   is specific to following 'confInfo' parameter would do the
   job.

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

      Figure 9: Updating a conference control client.

   Any other response code indicates an error in object: removing the client or title of a
                                conference control server (e.g., "forbidden", "badRequest")

7.2.3.5.  usersRequest and the
   handling is specific to the conference control client.

8.3.3.3.  Change Operation Responses

   If usersResponse messages

   Through a usersRequest message the CCMP response to client manipulates the "change" operation contains a response
   code
   <users> element of "success", the response SHOULD also contain the XCON-URI for conference document associated with the
   conference object that was changed.

   The "blueprintRequest" containing a "change" operation has to be
   considered a special operation, used identified by a conference server
   administrator wishing to remotely an existing blueprint in the
   conference server.

   If 'confObjId' parameter.  Inside the CCMP response to
   <users> element, along with the "change" operation contains a response
   code list of "modified", conference users, there is
   information that the response MUST contain client may be interested in controlling, such as
   the XCON-URI for lists of users to which access to the conference object and the appropriate XML document (either the full
   XML document is allowed/
   denied, conference participation policies, etc.; for this reason, a confResponse or specific paramaters
   customized message has been designed to allow for the other
   CCMP request types) associated with that conference object.  For
   example, a conferencing system may not have the resources to support manipulation of
   this specific capabilities that were changed, such as <codecs> in the
   <available-media>, thus part of a conference document.  Besides the <codecs> supported are usual
   'operation' parameter, a 'usersInfo' parameter MAY also be included in
   depending upon the
   returned XML document.

   If operation.  The 'usersInfo' parameter carries an
   object compliant with the CCMP response code <users> field of "requestTimeout" is received, the XCON data model.

   An 'operation' parameter MUST be included in a
   conference control client MAY re-attempt "usersRequest"
   message.  Two operations are allowed in a "usersRequest" message:

   1.  retrieve: In this case the request within SHOULD NOT include a period
   of time that would be specific to
       'usersInfo' parameter, while a conference control client or
   conference control server.

   Response codes such as "unauthorized", "forbidden",
   "operationNotAllowed" and "changeFailedProtected" indicate successful response MUST contain
       the client
   does not have desired <users> element in the appropriate permissions, 'usersInfo' parameter.

   2.  update: In this case, the conference is locked,
   there is an error in 'usersInfo' parameter MUST contain the permissions, or there is a system error in
       modifications to be applied to the client or conference control server, thus re-attempting referred <users> element.  If
       the
   request would likely not succeed.

   The response code of "deleteParentFailed" responseCode is not applicable to 'success', then the
   "change" operation and 'usersInfo' parameter
       SHOULD NOT be treated as "serverInternalError", returned.  If the handling of which responseCode is specific to 'modified', the conference control client.

   Any other response code indicates an error
       'usersInfo' parameter MUST be included in the response.  The
       'usersInfo' reflects to the client or
   conference control server (e.g., "forbidden", "badRequest") and the
   handling is specific to (partial) modifications
       that have been applied.

   Operations of 'create' and 'delete' make little sense in the conference control client.

   [Note by spromano: In case of "change" with
   a userRequest, the server
   first has to change usersRequest and SHOULD NOT be considered by the user's information stored; then, it has to
   update all conference objects server, which include
   means that user.  The
   association between a responseCode of 'forbidden' SHOULD 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="operation" type="operationType"
                           minOccurs="1" maxOccurs="1" />
                   <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 user usersRequest and the conferences in which she/he is
   participating usersResponse messages

7.2.3.6.  userRequest and userResponse messages

   A "userRequest" message is guaranteed through the "entity" attribute of the used to manipulate <user> element.  IMO, after doing all that, the server just answers elements inside
   a conference document associated with a userResponse message; then, if it is also using notifications,
   it might raise events towards the interested subscribers, to notify
   them about the changes in the updated conference objects.  Is this
   right??]

8.3.3.4.  Delete Operation Responses

   If the CCMP response to identified by the "delete" operation contains
   'confObjId' parameter.  Besides retrieving information about a response
   code of "success", the response MUST contain the XCON-URI for the
   specific conference object that was deleted for a "confResponse" or whose data
   element(s) were deleted for user, the other response types.

   The "blueprintRequest" containing a "delete" operation has to message MAY be
   considered a special operation, used by a conference server
   administrator wishing to remotely remove either create,
   or modify, or delete information about a blueprint from user.  A "userRequest" MUST
   include the
   conference server.

   The response code of "deleteParentFailed" indicates that 'operation' parameter, and MAY include a 'userInfo'
   parameter containing the
   conference object could not detailed user's information.

   Conference users can be deleted because it is the Parent of
   another conference object that is created in use.  In this case, the response
   also includes the XCON-URI for the conference object and is only
   applicable to a "confResponse".  If this response code is received
   for any other type of CCMP response, it should be treated as
   "serverInternalError", the handling number of which is specific to different ways.  Let
   us first consider the
   conference control client.

   If a response code case of "requestTimeout" is received, a conference
   control client MAY re-attempt the request within a period of time
   that would be specific user who wants to enter a conference control client or conference
   control server.

   Response codes
   (i.e. to add himself to the conference).  In such as "unauthorized", "forbidden" and
   "operationNotAllowed" indicate a case, the client does not
   'userInfo' parameter in the request (which MUST have an 'operation'
   value set to "create") SHOULD contain a <user> element (compliant
   with the
   appropriate permissions, XCON data model) having its 'entity' attribute set to a
   value which represents the conference is locked, XCON-USERID of the object that user in question.

   A different situation is one in which the CCMP client is trying to delete is actually acts on behalf
   of a blueprint, there third user, whose XCON-USERID is an
   error in known.  In this case, the permissions, or there
   <user> element SHOULD contain an 'entity' attribute whose value is a system error
   set to the XCON-USERID of the user in question.  As a final case, if
   the CCMP client or
   conference control server, thus re-attempting the request would
   likely not succeed.

   The response code of "changeFailedProtected" is not applicable aware of the XCON-USERID of the user to be
   inserted, the
   "delete" operation and key attribute (i.e. 'entity') SHOULD NOT be included in
   the request: the XCON-USERID generated by the conference server for
   such a user MUST be treated returned to the client as "serverInternalError", the handling value of which is specific to the conference control client.

   Any other response code indicates an error
   'entity' attribute in the client or
   conference control server (e.g., "forbidden", "badRequest") and 'userInfo' parameter of the
   handling response if the
   responseCode is specific "success".  The last case also applies to a CCMP
   client that obtains a new user profile in the conference control client.

   [Note by spromano (same comment as for "change"): In case 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 "delete"
   with a userRequest, the server first has to delete the user's
   information stored; then, it has to update all conference objects
   which include that user.  The association between the user userRequest and the
   conferences in which she/he is participating is guaranteed through
   the "entity" attribute of the <user> element.  IMO, after doing all
   that, the server just answers with a userResponse message; then, if
   it messages

7.2.3.7.  sidebarsByValRequest and sidebarsByValResponse messages

   A "sidebarsByValRequest" is also using notifications, it might raise events towards the
   interested subscribers, used to notify them about the changes in the
   updated conference objects.  Is this right??]

9.  Managing sidebars

   Sidebars can be either "by reference" or "by value".  The management
   of sidebars differs in execute a retrieve-only operation
   on the two cases, as discussed below

9.1.  Sidebars by value

   Sidebars by value represent an inner part <sidebars-by-val> field of the conference object
   associated with the root conference from which they stem.  One or
   more sidebars by value are then created represented
   by using the "confRequest"
   message with an operation of "change". 'confObjId'.  The conference description
   provided in the request MUST include an 'operation' of
   "retrieve" and a 'confObjId'.  A "sidebarsByValResponse" MUST contain
   a 'sidebarsByValInfo' parameter reporting the desired sidebars
   information, in <sidebars-by-
   val> element.  The 'sidebarsByValInfo' parameter contains the form of a sequence
   identifiers of one or more <entry>
   elements under the <sidebars-by-val> element.  Information about a
   sidebar by value can be accessed directly through a "sidebarRequest"
   message containing sidebars derived from the identifier of main conference.  For
   the required sidebar (i.e. its
   "entity" attribute value).

9.2.  Sidebars by reference

   Sidebars by reference represent semi-independent conference objects,
   i.e. objects that exist on their own, but creation and manipulation of sidebars, a different message has
   been envisaged, namely "sidebarByValRequest", which are strictly coupled
   to 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 of the conference object from which they stem. sidebarsByValRequest and
                      sidebarsByValResponse messages

7.2.3.8.  sidebarByValRequest and sidebarByValResponse messages

   A sidebar by
   reference is then created by using the "confRequest" "sidebarByValRequest" message with an
   operation of "create".

   Editor's Note: should we have a means to indicate that the object we
   are creating is actually a sidebar?  This would go in MUST contain the
   confRequest/create message.  Otherwise, we might add a
   sidebarRequest/create operation 'operation'
   parameter which basically does a conference discriminates among creation, but, e.g., stores it in modification and
   deletion of a different repository (/sidebars
   rather than /confs).

   Once specific sidebar.  The 'sidebarByValInfo' parameter, in
   turn, contains the description (in an XCON data model compliant
   fashion) of the sidebar has been created, you can add it to a conference by
   issuing a "confRequest" message with a "change" operation on itself.  The 'confObjId' parameter of such
   messages MUST contain the XCON-URI of the main conference object which the
   sidebar belongs to.  Information about a
   sidebar by reference can be accessed directly through a
   "sidebarRequest" message containing the identifier  The XCON-URI of the required sidebar (i.e. is contained in the value
   'entity' attribute of its <uri> element).

10.  Protocol Parameters

   This section describes the above mentioned 'sidebarByValInfo'
   document.  In case of creation, the 'sidebarByValInfo' SHOULD NOT be
   included in detail the parameters that request, since, as envisaged in the XCON framework
   ([RFC5239]), sidebars are used for always created by cloning the
   CCMP protocol.

10.1.  Operation Parameter main
   conference.  The "operation" attribute is a mandatory token 'sidebarByValInfo' parameter MUST be included in all CCMP
   request and response messages.  This document defines four possible
   values for this parameter: "retrieve", "create", "change" and
   "delete".

10.2.  ConfObjID Parameter a
   successful response.  The "confObjID" attribute is an optional 'sidebarByValInfo' represents the created
   sidebar, whose URI included appears in the CCMP
   request '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 of the sidebarByValRequest and response messages.  This attribute is required in the
   case of an "operation" of "retrieve", "change",
                       sidebarByValResponse messages

7.2.3.9.  sidebarsByRefRequest and "delete" in sidebarsByRefResponse messages

   Similar to the
   CCMP request and response messages.  The attribute is optional for an
   "operation" "sidebarsByValRequest", a "sidebarsByRefRequest" can
   be invoked to retrieve the <sidebars-by-ref> element of "create" in the "confRequest" message.
   conference object identified by the 'confObjId' parameter.  The "create"
   cases for which this
   'confObjID' parameter is REQUIRED are described in
   Section 7.2.  This attribute is the XCON-URI which is the target for
   the specific operation.  [Editor's Note: it might MUST be good to re-
   iterate the normative text here.]

   This attribute is not included in the "userRequest" message for an request.  An operation
   of "create".  In this case, 'retrieve' MUST also be included in the conference control client
   is requesting request.  In the creation case of a new conference user, as detailed in
   Section 10.3.

   In
   responseCode of success, the cases where 'sidebarsByRefInfo' parameter,
   containing the "conference-info" parameter Section 10.6 is
   also <sidebars-by-ref> element of the conference object,
   MUST be included in the requests and responses, response.  The <sidebars-by-ref> element
   represents the "confObjID" MUST
   match set of URIs of the XCON-URI in sidebars associated with the "entity" attribute.

10.3.  ConfUserID Parameter

   The "confUserID" attribute is optional URI included in main
   conference, whose description (in the CCMP
   request and response messages.  This form of a standard XCON
   conference document) is external to the XCON-USERID for the main conference control client initiating itself.
   Through the request.  The attribute retrieved URIs, it is
   required 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 of the CCMP request sidebarsByRefRequest and response
                      sidebarsByRefResponse messages with the exception
   of the "userRequest" message.  The "confUserID" parameter is used to
   determine if the conference control client has the authority to
   perform the operation.  Note that the details for authorization

7.2.3.10.  sidebarByRefRequest and
   related policy are specified in a separate document [TBD].

   This attribute is optional only for an "userRequest" sidebarByRefResponse messages

   A "sidebarByRefRequest" message along with a
   "create" operation.  In this case, the request MUST include
   information about the user in the "user" element.  At REQUIRED 'operation'
   parameter, MAY contain a minimum, the
   request MUST include the "user" element with an "entity" attribute.
   For this case, 'sidebarByRefInfo' parameter describing the
   conference control server MUST create a new
   conference user and return object (compliant with the XCON data model) associated confUserID in the response,
   if
   with the allocation of a new XCON-USERID is succesful. sidebar.  In the case where there is a confUserID in of 'retrieve', 'delete', 'update' and
   'create' operations, the request that has
   already been allocated, this request may be 'confObjId' parameter representing the creation XCON-
   URI of a
   confUserID for the conference control client to take on an additional
   role.

   This attribute target sidebar MUST be included.  The 'sidebarByRefInfo'
   parameter is required NOT REQUIRED in the "userResponse" message first two cases ('retrieve' and
   'delete'), whereas in the case of an "operation" of "create" and for all other responses.

10.4.  ResponseCode Parameter

   The "responseCode" attribute is a mandatory 'update' the 'sidebarByRefInfo'
   parameter in all CCMP
   response messages. MUST contain the changes to be applied to the referenced
   sidebar.  The values 'sidebarByRefInfo' MUST NOT be included for each 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 "responseCode" values
   are detailed in Section 8.3 with sidebarByRefRequest and
                       sidebarByRefResponse messages

8.  A complete example of the associated processing described CCMP in Section 8.3.3.

10.5.  Blueprints Parameter

   The "blueprints" attribute is an optional parameter action

   In this section a typical scenario in which the CCMP
   blueprintsResponse message.  In comes into play
   is described, by showing the case actual composition of a "blueprintsRequest"
   message, the "blueprintsResponse" message with a "responseCode" various CCMP
   messages.  In the call flows of
   "success" SHOULD include the "blueprints" supported by example, the conference
   control server.  The "blueprints" attribute Conference Control
   Client is comprised of a list of
   blueprints supported by CCMP-enabled client, whereas the specific conference server and includes a
   conference system specific "blueprintName" and Conference Control
   Server is a "confObjID" in the
   form of an XCON-URI for each CCMP-enabled server.  The 'confUserId' of the blueprints.

10.6.  Conference-info Parameter

   The "conference-info" element client is optional in the CCMP confRequest
   "Alice" and
   confResponse messages. appears in all requests.  The "conference-info" element contains the data for the conference
   object that is the target for the "confRequest" sequence of operations for
   "create", "change" and "delete" operations.  It is returned in a
   "confResponse" if the "confResponse" contains a responseCode of
   "modified" or if
   as follows:

   1.  Alice retrieves from the original CCMP request for server the "create" operation
   did not contain a "conference-info" element.  The latter case occurs
   when a conference control client sends a "confRequest" containing any list of the following: - a "confObjID" associated with available blueprints
       (Section 8.1);

   2.  Alice asks for detailed information about a specific blueprint - a "confObjID associated with a specific active conference
   or conference reservation that was included in a "confsResponse"
   message - no "confObjID" (or "conference-info") element, in which
   case the request is
       (Section 8.2);

   3.  Alice decides to create a new conference object based on a default
   provided by cloning the retrieved
       blueprint (Section 8.3);

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

   5.  Alice specifies a conferencing system.

   The "conference-info" element list of users to be contacted when the
       conference is also returned in a "userResponse"
   message, in activated (Section 8.5);

   6.  Alice joins the case of conference (Section 8.6);

   7.  Alice lets a "change" new user (whose 'confUserId' is "Ciccio") join the
       conference (Section 8.7).

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

   In such case, in fact,
   the request contains the <user> element to be added to following sections we deal with each of the conference
   indicated in above mentioned
   actions separately.

8.1.  Alice retrieves the <confObjID> parameter; available blueprints

   This section illustrates the transaction associated answer SHOULD
   carry with retrieval of
   the updated conference object blueprints, together with a dump of the two messages exchanged
   ("blueprintsRequest" and "blueprintsResponse").  As it comes out from
   the figure, the "blueprintsResponse" message contains, in its body.

   The details on the
   'blueprintsInfo' parameter, information that may be included about the available
   blueprints, in the
   "conference-info" element MUST follow form of the rules as specified in standard XCON-URI of the
   XCON Data Model document [I-D.ietf-xcon-common-data-model].  The
   conference control client blueprint,
   plus additional (and optional) information, like its display-text and conference control
   purpose.

   Alice retrieves from the server MUST follow
   those rules in generating the "conference-info" in any list of the available blueprints:

     CCMP
   request 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>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 response messages.

   Note that the "conference-info" element 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 not explicitly shown in available,
                only one user can talk at the XML schema (Section 12) due to XML schema constraints.

10.7.  User Parameter

   The "user" element contains same time,
                and the data 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 video are available,
                 only one user that 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 available,
                 only one user can talk at the target for same time,
                 and the CCMP request operations.  It is REQUIRED requests for all
   "userRequest" messages.

   The details on the information that may AudioFloor MUST
                 be included accepted by a Chair.
            </info:purpose>
           </info:entry>
        </blueprintsInfo>
      </ccmp:blueprintsResponse>
     </ccmpResponse>
   </ccmp:ccmpResponse>

               Figure 16: Getting blueprints from the server

8.2.  Alice gets detailed information about a specific blueprint

   This section illustrates the second transaction in the "user"
   element MUST follow overall flow.
   In this case, Alice, who now knows the rules as specified XCON-URIs of the blueprints
   available at the server, makes a drill-down query, in the XCON Data Model
   document [I-D.ietf-xcon-common-data-model]. form of a
   CCMP "blueprintRequest" message, to get detailed information about
   one of them (the one called with XCON-URI
   "xcon:AudioRoom@meetecho.com").  The conference control
   client and conference control server MUST follow those rules in
   generating picture shows such transaction.
   Notice that the "user" response contains, in any of the 'blueprintInfo' parameter,
   a document compliant with the standard XCON data model.

   Alice retrieves detailed information about a specified blueprint:

     CCMP request and response
   messages.

   Note that Client                                             CCMP Server
          |                                                       |
          | CCMP blueprintRequest message                         |
          |   - confUserID: Alice                                 |
          |   - confObjId: bp123                                  |
          |   - Operation: retrieve                               |
          |   - blueprintInfo: (null)                             |
          |------------------------------------------------------>|
          |                                                       |
          |                        CCMP blueprintResponse message |
          |                          - confUserID: Alice          |
          |                          - confObjId: bp123           |
          |                          - 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>Alice</confUserID>
           <ccmp:blueprintRequest>
               <operation>retrieve</operation>
           </ccmp:blueprintRequest>
     </ccmpRequest>
   </ccmp:ccmpRequest>

   2. blueprintResponse 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-blueprint-response-message-type">
       <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
       <confUserID>Alice</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>
                </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 17: Getting info about a specific blueprint

8.3.  Alice creates a new conference through a cloning operation

   This section illustrates the "user" element is not explicitly shown third transaction in the XML
   schema Section 12 due overall flow.
   Alice decides to XML schema constraints.

10.8.  Users Parameter

   The "users" element contains the data for the create a new conference users that
   are by cloning the target blueprint
   having XCON-URI "xcon:AudioRoom@meetecho.com", for which she just
   retrieved detailed information through the CCMP request operations.  It "blueprintRequest"
   message.  This is REQUIRED for
   all "usersRequest" messages.

   The details on achieved by sending a "confRequest/create" message
   having the information that may be included blueprint's URI in the "users"
   element MUST follow 'confObjId' parameter.  The picture
   shows such transaction.  Notice that the rules as specified response contains, in the XCON Data Model
   'confInfo' parameter, the document [I-D.ietf-xcon-common-data-model].  The conference control
   client and conference control server MUST follow those rules in
   generating associated with the "users" newly created
   conference, which is compliant with the standard XCON data model.
   The 'confObjId' in any of the CCMP request and response
   messages.

   Note that the "users" element is not explicitly shown in the XML
   schema Section 12 due set to XML schema constraints.

10.9.  Sidebar Parameters

   The "sidebar" parameter contains the data for XCON-URI of the sidebar new
   conference (in this case, "xcon:8977794@meetecho.com").  We also
   notice that this value is equal to the
   target for value of the CCMP request operations.  It is REQUIRED for all
   "sidebarRequest" messages.  There are two elements associated with a
   sidebar: "sidebar-by-val" and "sidebar-by-ref".  The elements relate
   to whether "entity"
   attribute of the data for <conference-info> element of the sidebar is in 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: 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 the same 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 object
   for which it serves as a sidebar or whether 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 a new conference object
   is created for the sidebar.

   The details on the by cloning a blueprint

8.4.  Alice updates conference information that may be included

   This section illustrates the fourth transaction in the "sidebar-
   by-val" or "sidebar-by-ref" element MUST follow overall flow.
   Alice decides to modify some of the rules as
   specified in details associated with the XCON Data Model document
   [I-D.ietf-xcon-common-data-model].  The conference control client and
   conference control server MUST follow those rules in generating she just created.  More precisely, she changes the
   "sidebar-by-val" or "sidebar-by-ref"
   <display-text> element under the <conference-description> element in any of
   the CCMP
   request and response messages.

11.  Examples

   Examples on document representing the use conference.  This is achieved through a
   "confRequest/update" message carrying the fragment of HTTP as the CCP based on a RESTful
   implementation are provided conference
   document to which the required changes have to be applied.  As shown
   in Section 11.1.  The body of the HTTP
   methods contains picture, the CCMP operations and data.  Examples response contains a code of 'success', which
   acknowledges the modifications requested by the client.

   Alice updates information about the conference she just created:

     CCMP
   operations and related data are provided in section Section 11.2

11.1.  HTTP methods for realizing a RESTful Client                                             CCMP

   This section provides a series of examples using the HTTP methods for
   realization of Server
          |                                                       |
          | CCMP confRequest message                              |
          |   - confUserID: Alice                                 |
          |   - confObjId: xcon:8977794@meetecho.com              |
          |   - Operation: update                                 |
          |   - confInfo: conf456Updates                          |
          |------------------------------------------------------>|
          |                                                       |
          |                             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 CCMP.  The examples provide 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 conference information

8.5.  Alice inserts a sequence list of
   operations that a typical user might invoke in activating a
   conference, adding users to a conference, retrieving in the conference data
   and then deleting an active conference.  Note, object

   This section illustrates the examples do not
   include any details beyond fifth transaction in the basic operation.  For example, overall flow.
   Alice modifies the
   "Host" that would be <allowed-users-list> under the result of discovery of <users> element in
   the document associated with the conference server
   per Section 8.1 would be included in she created.  To the HTTP messages.
   purpose, she exploits the "usersRequest" message provided by the
   CCMP.  The picture below shows the transaction.

   Alice retrieves info updates information about active/scheduled the list of users to whom access to
   the conference is permitted:

   CCMP 'conferences': Client                                             CCMP client "Alice"                               ConfS Server
        |                                                       |
        | GET /confs CCMP usersRequest message                             |
        |   - confUserID: Alice                                 |
         |--------------------------------------------->|
        |                                              |--+ Prepare   - confObjId: xcon:8977794@meetecho.com              |
        |   - Operation: update                                 | formatted
        |                             200 OK (w/ body) |<-+ conf info
         |<---------------------------------------------|    (list of   - usersInfo: usersUpdates                               |
        |------------------------------------------------------>|
        |                                                       |
        |                            CCMP usersResponse message |
        |                              - confUserID: Alice      |
        |                              - confObjId: xcon:89..   |
        |                              - responseCode: success  |
        |                              - usersInfo: (null)      |     conf objs)
        |<------------------------------------------------------|
        |                                                       |
        .                                                       .
        .                                                       .

 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 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 3: Getting a List 20: Updating the list of Active Coferences allowed users for the conference
                        'xcon:8977794@meetecho.com'

8.6.  Alice is now able joins the conference

   This section illustrates the sixth transaction in the overall flow.
   Alice uses the CCMP to retrieve info add herself to the newly created conference.
   This is achieved through a "userRequest/create" message containing,
   in the 'userInfo' parameter, a <user> element compliant with the XCON
   data model representation.  Notice that such element includes
   information about the user's Address of Records, as well as her
   current end-point.  The picture below shows the transaction.  Notice
   how the 'confUserId' parameter is equal to the "entity" attribute of
   the <userInfo> element, which indicates that the request issued by
   the client is a specific conference: first-party one.

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

    CCMP client "Alice"                               ConfS
   |                                              |
   | GET /confs/confid-34fg67h                    |
   |--------------------------------------------->|
   |                                              |--+ Prepare
   | Client                                             CCMP Server
         |                                                       | formatted
         |                             200 OK (w/ body) |<-+ XML info
   |<---------------------------------------------| CCMP userRequest message                              |
         |

                  Figure 4: Getting a Specific Coference   - confUserID: Alice decides to add a new user to this conference:

    CCMP client "Alice"                               ConfS                                 |
         |   - confObjId: xcon:8977794@meetecho.com              | PUT /confs/confid-34fg67h/users/pippo876
         |   - Operation: create                                 | (w/ body=new user info)
         |
     |--------------------------------------------->|   - userInfo: AliceUserInfo                           |                                              |--+ Add new user
         |------------------------------------------------------>|
         |                                                       |
         | to data model                             CCMP userResponse message |                             200 OK (w/ body) |<-+ and update
     |<---------------------------------------------|   user in system
         |                               - confUserID: Alice     |
         |                               - confObjId: xcon:89..  |
         | (event triggered                               - responseCode: success |
         |  e.g. RFC4575)                               - 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 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 5: Adding 21: Alice joins the conference through the CCMP

8.7.  Alice adds a New User new user to an Active Conference
   Subsequent GETs on both the conference object as a whole

   This section illustrates the seventh and last transaction in the
   users portion reflect
   overall flow.  Alice uses the CCMP to add a new user to the
   conference.  This is achieved through a "userRequest/create" message
   containing, in the 'userInfo' parameter, a <user> element compliant
   with the XCON data model representation.  Notice that such element
   includes information about the addition user's Address of Records, as well as
   his current end-point.  The picture below shows 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 request
   issued by the New User:

    CCMP client "Alice"                               ConfS
          |                                              |
          | GET /confs/confid-34fg67h/users/pippo876     |
          |--------------------------------------------->|
          |                                              |--+ Prepare
          |                                              |  | formatted
          |                             200 OK (w/ body) |<-+ XML info
          |<---------------------------------------------|
          |                                              |
          | GET /users/pippo876                          |
          |--------------------------------------------->|
          |                                              |--+ Prepare
          |                                              |  | formatted
          |                             200 OK (w/ body) |<-+ XML info
          |<---------------------------------------------|
          |                                              |

       Figure 6: Getting is a Specific Conference Object after Changes 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 value of the newly created conference user id.

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

   CCMP client "Alice"                               ConfS
         |                                              |
         | POST /confs/confid-34fg67h/users/pippo876 Client                                             CCMP Server
        |                                                       | (w/ body=updated user info)
        |
         |--------------------------------------------->| CCMP userRequest message                              |                                              |--+ Update user
        |   - confUserID: Alice                                 |
        | in data   - confObjId: xcon:8977794@meetecho.com              |                             200 OK (w/ body) |<-+ and in
         |<---------------------------------------------|    system
        |   - Operation: create                                 |
        |                                              |Event trigger   - usersInfo: CiccioUserInfo                         |                                              |e.g. RFC4575
        |------------------------------------------------------>|
        |                                              |------------->                                                       |
        |
                  Figure 7: Updating a User's Information

   Alice destroys the running conference: when trying to access it, the
   server returns an error:                             CCMP client "Alice"                               ConfS
         |                                              |
         | DELETE /confs/confid-34fg67h                 |
         |--------------------------------------------->|
         |                                              |--+ Prepare
         |                                              | userresponse message | formatted
        |                             200 OK (w/ body) |<-+ XML info
         |<---------------------------------------------|                               - confUserID: Alice     |
        |                               - confObjId: xcon:89..  | GET /confs/confid-34fg67h
        |
         |--------------------------------------------->|                               - responseCode: success |                                              |--+ ConfS can't
        |                               - usersInfo: (not null!)|
        |<------------------------------------------------------|
        |                                                       | find
        .                                                       .
        .                                                       .

 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 the
         |                             200 OK (w/body:  |<-+ conference
         |<---------------------------------------------|
         |                 responseCode=objectNotFound  |
         |                                              | 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 8: Deleting an Active Coference

11.2.  CCMP Detailed Message Body Examples

   The examples below contain simply the <body> of the requests and
   responses.  In the case that HTTP serves as the transport, the HTTP
   methods as identified in Table 1 (and per 22: Alice adds a new user to the examples in
   Section 11.1) would include conference through the CCMP requests and Responses as the
   body of the HTTP methods.

11.2.1.  Creating

9.  Locating a New Conference

   The first example creates Control Server

   If a new conference.

          <confRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
          <operation>create</operation>
          <confUserID> userA-confxyz987 </confUserID>

          <conference-info
            xmlns="urn:ietf:params:xml:ns:conference-info"
            version="1">
            <conference-description>
             <parent>http://example.com/conf200</parent>
             <subject>Agenda: This month's goals</subject>
             <conf-uris>
               <entry>
                 <uri>sips:conf223@example.com</uri>
                 <purpose>participation</purpose>
               </entry>
             </conf-uris>
             <service-uris>
               <entry>
                <uri>http://sharep/salesgroup/</uri>
                <purpose>web-page</purpose>
               </entry>
               <entry>
                <uri>http://example.com/conf233</uri>
                <purpose>control</purpose>
               </entry>
              </service-uris>
             </conference-description>
          </conference-info>

        </confRequest>

                     Figure 9: Create Request Example

   The response to this request conference control client is shown below; it returns the object
   identifier as not pre-configured to use a URL and the final
   specific conference description, which may
   modify control server for the description offered by requests, the client MUST
   first discover the user.

    <confResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"
      <operation>create</operation>
      <responseCode> modified </responseCode>
      <confObjID> xcon:confxyz987@example.com </confObjID>
      <confUserID> userA-confxyz987 </confUserID>

      <conference-info
        xmlns="urn:ietf:params:xml:ns:conference-info"
        version="1">
        <entity> xcon:confxyz987@example.com </entity>
        <conference-description>
         <parent>http://example.com/conf200</parent>
         <subject>Agenda: This month's goals</subject>
         <conf-uris>
           <entry>
             <uri>sips:conf223@example.com</uri>
             <purpose>participation</purpose>
           </entry>
         </conf-uris>
         <service-uris>
           <entry>
            <uri>http://sharep/salesgroup/</uri>
            <purpose>web-page</purpose>
           </entry>
           <entry>
            <uri>http://example.com/conf233</uri>
            <purpose>control</purpose>
           </entry>
          </service-uris>

      <!-- Addt'l modified conference description including users alice,
           bob and userA... -->

          <allowed-users-list>
           <target uri="sip:alice@example.com" method="dial-out"/>
           <target uri="sip:bob@example.com" method="dial-out"/>
           <target uri="sip:userA@example.com" method="dial-in"/>
          </allowed-users-list>

         </conference-description>
      </conference-info>

      </confResponse>

                    Figure 10: Create Response Example

11.2.2.  Creating a New Conference User control server before it can send any
   requests.  The request below creates a new conference user, independent 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
   specific conference object.

       <userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
          <operation>create</operation>

          <user entity="sip:bob@example.com">
               <role>observer</role>
          </user>

       </userRequest>

                      Figure 11: Create User Example

   The response server.

   This document proposes the use of DNS to this request is shown below; it returns locate the
   conference user identifier.

      <userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
        <operation>create</operation>
        <responseCode> success </responseCode>
        <confUserID>userC-confxyz987</confUserID>
      </userResponse>

                    Figure 12: Create Response Example

11.2.3.  Adding conferencing
   server.  U-NAPTR resolution for conferencing takes a User domain name as
   input and produces a URI that identifies the 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 12.4.1 defines an Application Service tag of "XCON", which is
   used to identify the centralized conferencing (XCON) server for a Conference
   particular domain.  The request below adds a user Application Protocol tag "CCMP", defined in
   Section 12.4.2, is used to the conference identified by the
   XCON-URI.  Note identify an XCON server that understands
   the user CCMP protocol.

   The NAPTR records in "confUserID" element is the user
   requesting that following example Figure 23 demonstrate the user "sip:claire@example.com" be added
   use of the Application Service and Protocol tags.  Iterative NAPTR
   resolution is used to delegate responsibility for the
   conference.  The user may or may not be "claire" (i.e., a user, such
   as 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 the moderator, can add another user to "XCON" Application Service tag and the conference.

   Editor's note: Do we need to consider users adding users OBO of other
   users or "CCMP"
   Application Protocol tag are included in that case do we just change the conference object as a
   whole?
      <userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
          <operation>change</operation>
          <confObjID> xcon:confxyz987@example.com </confObjID>
          <confUserID> userC-confxyz987 </confUserID>

          <user entity="sip:claire@example.com">
            <role>participant</role>
            <type>dial-out</type>
          </user>

       </userRequest>

                        Figure 13: Add User Example

   The response to this request is shown below.

      <userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
        <operation>change</operation>
        <responseCode> success </responseCode>
        <confObjID> xcon:confxyz987@example.com </confObjID>
        <confUserID> userC-confxyz987 </confUserID>

                           <user entity="sip:claire@example.com">
                   <role>participant</role>
                   <type><dial-out/></type>
              </user>
            </users>
          </conference-info>

      </userResponse>

                   Figure 14: Add User Response Example

12. Section 12.4.

10.  XML Schema

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

   Editor's Note: the schema currently matches the prototype - it needs
   updating to include changes/additions to request names (e.g.,
   optionsRequest -> blueprintsRequest, addition of blueprintRequest and
   confsRequest.

  <?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">

          <!-- Import data model schema (as per the latest draft) -->

         <xs:import
           namespace="urn:ietf:params:xml:ns:xcon-conference-info"
              schemaLocation="DataModel-11.xsd"/>
           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:attribute name="xconURI" type="xs:string"
                                   use="optional" />
  </xs:complexType>

          <!-- CCMP response definition -->

  <xs:complexType name="ccmp-response-type"> 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" maxOccurs="1" />
       <xs:element name="confObjID" 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"/>

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

          <!-- usersRequestType -->
  <xs:element name="usersRequest" 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 name="ccmpResponse"
           type="ccmp-response-message-type" ref="userRequest" />
        </xs:sequence>
            <xs:attribute name="xconURI" type="xs:string"
                                   use="optional" />
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <!-- Definition of ccmp-request-message-type as an
                        abstract complex type userRequestType -->

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

  <xs:complexType abstract="true"
          name="ccmp-request-message-type"> name="userRequestType">
          <xs:sequence>
      <xs:element name="confObjID" type="xs:string"
                                       minOccurs="0" name="operation"
          type="operationType"
                            minOccurs="1" maxOccurs="1" />
            <xs:element name="confUserID" type="xs:string" name="userInfo"
          type="info:user-type"
          minOccurs="0" maxOccurs="1" />
          </xs:sequence>
  </xs:complexType>

                  <!-- blueprintsRequest sidebarsByValRequest -->

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

  <!-- confsRequest sidebarsByValRequestType -->

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

  <xs:complexType name="ccmp-confs-request-message-type">
        <xs:complexContent>
         <xs:extension base="tns:ccmp-request-message-type"/>
        </xs:complexContent> 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>

  <!-- 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>

  <!-- usersRequest sidebarsByRefRequestType -->

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

    <xs:complexType name="ccmp-users-request-message-type"> 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="usersRequest" ref="sidebarByValRequest" />
          </xs:sequence>
         </xs:extension>
      </xs:complexContent>
  </xs:complexType>

  <!-- userRequest sidebarByValRequestType -->

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

      <xs:complexType name="ccmp-user-request-message-type"> 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>

  <!-- sidebarByRefRequest -->

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

  <!-- [TODO: sidebarRequest 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="confObjID" name="confUserID" type="xs:string"
          minOccurs="0" maxOccurs="1" />
         <xs:element name="confUserID" name="confObjID" type="xs:string"
           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"/>
       </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>

          <!-- [TODO: sidebarResponse -->

      <!-- 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="operationNotAllowed"/>
               <xs:enumeration value="deleteFailedParent"/>
               <xs:enumeration value="modifyFailedProtected"/>
               <xs:enumeration value="requestTimeout"/>
               <xs:enumeration value="serverInternalError"/>
               <xs:enumeration value="notImplemented"/>
             </xs:restriction>
           </xs:simpleType>

     <!-- blueprintsResponse userResponseType -->

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

     <xs:complexType name="blueprintsResponseType"> name="userResponseType">
        <xs:sequence>
           <xs:element ref="namespace"
                                 minOccurs="1"
                                 maxOccurs="unbounded" /> 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 name="namespace">
                   <xs:simpleType>
                           <xs:restriction base="xs:string" ref="sidebarsByValResponse" />
                   </xs:simpleType>
           </xs:element>
          </xs:sequence>
         </xs:extension>
      </xs:complexContent>
  </xs:complexType>

          <!-- confsResponse sidebarsByValResponseType -->
  <xs:element name="confsResponse"
                      type="confsResponseType" name="sidebarsByValResponse"
              type="sidebarsByValResponseType" />

     <xs:complexType name="confsResponseType"> name="sidebarsByValResponseType">
         <xs:sequence>
            <xs:element ref="namespace"
                            minOccurs="1"
                            maxOccurs="unbounded" /> name="sidebarsByValInfo"
                   type="info:sidebars-by-val-type"/>
         </xs:sequence>
     </xs:complexType>

                  <!-- confRequest sidebarsByRefResponse -->

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

  <xs:complexType name="confRequestType"> name="ccmp-sidebarsByref-response-message-type">
      <xs:complexContent>
         <xs:extension base="tns:ccmp-response-message-type">
          <xs:sequence>
                  <xs:element name="operation"
                            type="operationType"
                            minOccurs="1"
                            maxOccurs="1" ref="sidebarsByRefResponse" />
                <xs:element name="confInfo"
                            type="dm:conference-info"
                            minOccurs="0"/>
          </xs:sequence>
         </xs:extension>
      </xs:complexContent>
  </xs:complexType>

          <!-- confResponse sidebarsByRefResponseType -->

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

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

                  <!-- userRequest sidebarByValResponse -->

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

  <xs:complexType name="userRequestType"> name="ccmp-sidebarByVal-response-message-type">
      <xs:complexContent>
         <xs:extension base="tns:ccmp-response-message-type">
          <xs:sequence>
                  <xs:element name="operation"
                            type="operationType"
                            minOccurs="1"
                            maxOccurs="1" ref="sidebarByValResponse" />
                <xs:element name="userInfo"
                            type="dm:user"
                            minOccurs="0"/>
          </xs:sequence>
         </xs:extension>
      </xs:complexContent>
  </xs:complexType>

          <!-- userResponse sidebarByValResponseType -->
  <xs:element name="userResponse"
                       type="userResponseType" name="sidebarByValResponse"
              type="sidebarByValResponseType" />

     <xs:complexType name="userResponseType"> name="sidebarByValResponseType">
        <xs:sequence>
            <xs:element name="operation"
                           type="operationType"
                           minOccurs="1"
                           axOccurs="1" />
               <xs:element name="userInfo"
                           type="dm:conference-info"
                           minOccurs="0"/> name="sidebarByValInfo"
                type="info:conference-type"/>
         </xs:sequence>
     </xs:complexType>

                  <!-- usersRequest sidebarByRefResponse -->

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

  <xs:complexType name="usersRequestType"> name="ccmp-sidebarByref-response-message-type">
      <xs:complexContent>
         <xs:extension base="tns:ccmp-response-message-type">
          <xs:sequence>
                  <xs:element name="operation"
                            type="operationType"
                            minOccurs="1"
                            maxOccurs="1" ref="sidebarByRefResponse" />
                <xs:element name="usersInfo"
                            type="dm:users"
                            minOccurs="0"/>
          </xs:sequence>
         </xs:extension>
      </xs:complexContent>
    </xs:complexType>

          <!-- confResponse sidebarByRefResponseType -->

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

     <xs:complexType name="usersResponseType"> name="sidebarByRefResponseType">
         <xs:sequence>
            <xs:element name="operation"
                           type="operationType"
                           minOccurs="1"
                           maxOccurs="1" />
               <xs:element name="usersInfo"
                           type="dm:users"
                           minOccurs="0"/> 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="change"/> value="update"/>
              <xs:enumeration value="delete"/>
            </xs:restriction>
          </xs:simpleType>
    </xs:schema>

                                 Figure 15

13. 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 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 provides the conference server with an and a server) by efficiently using multiple
   synchronous HTTP URL
   which request/response pairs without requiring the use of
   polling or asynchronous chunking."

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

12.  IANA Considerations

   This document registers a change occurs. new XML namespace, a new XML schema, and
   the MIME type for the schema.  This is apparently how most
   credit card shopping cards work, having implemented one. document also registers the
   "XCON" Application Service tag and the "CCMP" Application Protocol
   tag.  This works
   well document also defines registries for our scenario since a CCMP "client" is likely to be a web
   server that provides the graphical HTML user interface CCMP operation
   types and uses response codes.

12.1.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   ""urn:ietf:params:xml:ns:xcon:ccmp"".

      URI: "urn:ietf:params:xml:ns:xcon:ccmp"

      Registrant Contact: IETF, XCON working group, (xcon@ietf.org),
      Mary Barnes (mary.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.  XML Schema Registration

   This section registers an XML schema as per the backend to talk to 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 of this document.

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

   This section registers the conference server.  In that particular
   case, there doesn't seem to be a problem "application/ccmp+xml" MIME type.

   To:  ietf-types@iana.org

   Subject:  Registration of having both models.  PC-
   based clients behind NATs would provide a SIP event URI, web servers
   would probably find MIME media type application/ccmp+xml

   MIME media type name:  application

   MIME subtype name:  ccmp+xml

   Required parameters:  (none)

   Optional parameters:  charset
      Indicates the HTTP model much easier to program with.

   Another option being considered character encoding of enclosed XML.  Default is BOSH
   (http://xmpp.org/extensions/xep-0124.html),
      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 basically an
   extension to XMPP designed with the following aim: "...a transport to carry
      protocol that emulates a bidirectional stream between two entities
   (such as a client data related conference control.  Some of the data could
      be considered private and thus should be protected.

   Interoperability considerations:  This content type provides a server) by efficiently using multiple
   synchronous HTTP request/response pairs without requiring basis
      for a protocol

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

   Applications which use of
   polling or asynchronous chunking."

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

14.  Role based access control

   Editors' Note: this section is also under construction. 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 topic media type is planned to be described in a separate document that will be
   reference here.  XACML specialization of
      application/xml [RFC3023], and many of the considerations
      described there also apply to application/ccmp+xml.

12.4.  DNS Registrations

   Section 12.4.1 defines an Application Service tag of "XCON", which is
   used to identify the current proposed direction centralized conferencing (XCON) server for which a
   particular domain.  The Application Protocol tag "CCMP", defined in
   Section 12.4.2, is used to identify an XCON server that understands
   the authors would like feedback.

15.  IANA Considerations CCMP protocol.

12.4.1.  Registration  of a Location Server Application Service Tag

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

   Application Service Tag: XCON

   Intended usage: Identifies a new XML schema, and
   the MIME type server that supports centralized
   conferencing.

   Defining publication: RFCXXXX

   Contact information: The authors of this document

   Author/Change controller: The IESG

12.4.2.  Registration of a Location Server Application Protocol Tag for the schema.
         HELD

   This document also section registers the
   "XCON" a new S-NAPTR/U-NAPTR Application Service Protocol tag and
   for the "CCMP" 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.  CCMP Protocol
   tag. Registry

   This document also defines registries for requests that the CCMP operation
   types and response codes.

15.1.  URN Sub-Namespace Registration

   This section registers IANA create 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 registry for the
   CCMP Messages</h1>
               <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
   [[NOTE protocol including an initial registry for operation types and
   response codes.

12.5.1.  CCMP Message Types

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

   Related Registry:   CCMP Message Types Registry

   Defining RFC:  RFC XXXX [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

15.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:xcon:ccmp 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).
   Schema:

   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 XML 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 this schema can be found 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 entirety of
      Section 12 of this document.

15.3.  MIME Media Type Registration for 'application/ccmp+xml'
      allowed-users-list, join-handling, etc.

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

   To:  ietf-types@iana.org
   Subject:  Registration result 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 is
      UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on
      request to manipulate the character encoding used.  See RFC
      3023 [RFC3023], section 3.2.
   Security considerations: "users" element in the conference
      object.

   sidebarRequest:  This content type sidebarRequest is designed used to carry
      protocol data retrieve the
      information related conference control.  Some to a sidebar or to create, change or delete a
      specific sidebar.

   sidebarResponse:  This sidebarResponse indicates the result of the data could
      be considered private and thus should be protected.
   Interoperability considerations:  This content type provides a basis
      sidebarRequest.

12.5.2.  CCMP Response Codes

   The following summarizes the requested registry for a protocol
   Published specification: CCMP Response
   codes:

   Related Registry:   CCMP Response Code Registry

   Defining RFC:  RFC XXXX [[NOTE [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: 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>
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information: (mary.barnes@nortel.com).

   This media type is a specialization of
      application/xml [RFC3023], and many of section pre-registers the considerations following thirteen initial response
   codes as described there also apply to application/ccmp+xml.

15.4.  DNS Registrations

   Section 15.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 above in Section 15.4.2, is used to identify an XCON server 7:

   success:  This code indicates that understands the CCMP protocol.

15.4.1.  Registration  of a Location Server Application Service Tag request was successfully
      processed.

   modified:  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 code indicates that supports centralized
   conferencing.

   Defining publication: RFCXXXX

   Contact information: The authors of this document

   Author/Change controller: The IESG

15.4.2.  Registration of a Location Server Application Protocol Tag 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
         HELD the specific operation on the conference object.

   forbidden:  This section registers a new S-NAPTR/U-NAPTR Application Protocol tag code indicates that the specific operation is not
      valid for the CCMP protocol, as mandated by [RFC3958].

   Application Service Tag: CCMP

   Intended Usage: Identifies target conference object.

   objectNotFound:  This code indicates that 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

15.5.  CCMP Protocol Registry specific conference
      object was not found.

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

   deleteFailedParent:  This document requests code indicates that the IANA create a new registry for conferencing system
      cannot delete the
   CCMP protocol including an initial registry specific conference object because it is a
      parent for operation types and
   response codes.

15.5.1.  CCMP Message Types

   The CCMP messages are described in Section 8 and defined in another conference object.

   changeFailedProtected:  This code indicates that the XML
   schema in Section 12.  The following summarizes target
      conference object cannot be changed (e.g., due to policies, roles,
      privileges, etc.).

   requestTimeout:  This code indicates that the requested
   registry:

   Related Registry:   CCMP Message Types Registry
   Defining RFC:  RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX request could not be
      processed within a reasonable time, with the RFC number for this specification.]
   Registration/Assignment Procedures:  New CCMP message types are
      allocated on time specific to a specification required basis.
   Registrant Contact:  IETF, XCON working group, (xcon@ietf.org), Mary
      Barnes (mary.barnes@nortel.com).
      conferencing system implementation.

   serverInternalError:  This section pre-registers code indicates that the following initial CCMP message types:

   blueprintsRequest:  Used by a 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 client functionality needs to query a
      conferencing system for its capabilities, be tightly
   controlled to keep attackers from disrupting conferences, adding
   themselves to conferences or engaging in terms theft of available services.  In the
   case of a RESTful implementation of the CCMP, implementors need to
   deploy standard HTTP authentication and authorization mechanisms.
   Since conference blueprints.
   blueprintsResponse: information may contain secrets such as participant
   lists and dial-in codes, all conference control information SHOULD be
   carried over TLS (HTTPS).

14.  Acknowledgments

   The optionsResponse returns a list of Blueprints
      supported by authors appreciate the specific conference server.
   confsRequest:  Used feedback provided by a conference control client Dave Morgan, Pierre
   Tane, Lorenzo Miniero and Tobia Castaldi.  Special thanks go to query a
      conferencing system
   Roberta Presta for its scheduled/active conferences.
   confsResponse:  The confsResponse returns her invaluable contribution to this document.
   Roberta has worked on the list specification of the currently
      activated/scheduled conferences CCMP protocol at the server.
   confRequest:  The confRequest is
   University of Napoli for the preparation of her Master thesis.  She
   has also implemented the CCMP prototype used to create a conference object
      and/or to request an operation on for the conference object trials and from
   which the dumps provided in Section 8 have been extracted.

15.  Changes since last Version

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

   The confResponse indicates following summarizes the result of changes between the operation
      on WG 01 and the conference object 02:

   1.  Changed the basic approach from REST to HTTP as a whole.
   userRequest:  The userRequest transport.
       This impacted most of the document - i.e., a major rewrite - 02
       is used closer to request an operation on the
      "user" element in 00 than the conference object.
   userResponse: 01.

   2.  Added full example based on prototype.

   The userResponse indicates following summarizes the result of changes between the requested
      operation on WG 00 and the "user" element in 01:

   1.  Changed the conference object.
   usersRequest  This usersRequest is used basic approach from using SOAP to manipulate REST - the "users"
      element
       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 conference object, including parameters such as optionsRequest and the
      allowed-users-list, join-handling, etc.
   usersResponse:  This usersResponse indicates
       latter allows the result client to get a list of all active conferences.

   3.  Merged all requests into the
      request to manipulate basic operations table.  Added
       summary of RESTful examples (referenced by the "users" element in basic operations
       table.

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

   5.  Removed requestID from the conference
      object.

   sidebarRequest:  This sidebarRequest is used to retrieve schema (it should be handle by the
      information related
       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 a sidebar or
       informational section.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to create, change or delete a
      specific sidebar.
   sidebarResponse:  This sidebarResponse indicates the result of the
      sidebarRequest.

15.5.2.  CCMP Response Codes

   The following summarizes 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.

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

   [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 (work in progress),
              October 2008.

16.2.  Informative References

   [REST]     Fielding, "Architectural Styles and the requested registry 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 CCMP Response
   codes:

   Related Registry:   CCMP Response Code Registry
   Defining RFC: User Control of Internet
              Telephony Services", RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
      with 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 number 3958, January 2005.

   [RFC3966]  Schulzrinne, H., "The tel URI 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 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., Nielsen, H., and
              J. Moreau, "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]
              Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and
              J. Moreau, "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 following thirteen initial response
   codes objects can be implemented in at least two
   different ways, namely as remote procedure calls - using SOAP as
   described above in Section 8.3:

   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.
   operationNotAllowed:  This code indicates that the specific operation
      is not allowed for the target conference object (e.g.., due Appendix A.1 and by defining resources following a
   RESTful architecture Appendix A.2.

   In both approaches, servers will have to
      policies, etc.)
   deleteFailedParent:  This code indicates that the conferencing system
      cannot delete recreate their internal
   state representation of the specific conference object because it is a
      parent for another conference object.
   changeFailedProtected:  This code indicates that with each update request, checking
   parameters and triggering function invocations.  In the target
      conference object cannot SOAP
   approach, it would be changed (e.g., due possible to policies, roles,
      privileges, etc.).
   requestTimeout:  This code indicates describe a separate operation for
   each atomic element, but that would greatly increase the request could not be
      processed within a reasonable time, with complexity
   of the time specific protocol.  A coarser-grained approach to a
      conferencing system implementation.

   serverInternalError:  This code indicates the CCMP does require
   that the conferencing
      system experienced some sort of internal error.
   notImplemented:  This code indicates server process XML elements in updates that the specific operation is have not implemented on changed
   and that conferencing system.

16.  Security Considerations

   Access to conference control functionality needs to there can be tightly
   controlled to keep attackers from disrupting conferences, adding
   themselves to conferences or engaging multiple changes in theft of services.  In one update.

   For CCMP, the
   case of a RESTful implementation of resource (REST) model might appear more attractive,
   since the CCMP, implementors need to
   deploy standard HTTP authentication and authorization mechanisms.
   Since conference information may contain secrets such operations fit the CRUD approach.

   Neither of these approaches were considered ideal as participant
   lists and dial-in codes, all conference control information SHOULD SOAP was not
   considered to be
   carried over TLS (HTTPS).

17.  Acknowledgments

   The authors appreciate the feedback provided by Dave Morgan, Pierre
   Tane, Lorenzo Miniero and Tobia Castaldi

18.  Changes general purpose enough for use in a broad range of
   operational environments.  It is quite awkward to apply a RESTful
   approach since last Version

   NOTE TO THE RFC-Editor: Please remove this section prior the CCMP requires a more complex request/response
   protocol in order to
   publication as an RFC.

   The following summarizes maintain the changes between data both in the WG 00 server and at the 01:

   1.  Changed the basic approach from using SOAP
   client.  This doesn't map very elegantly 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/
   response model, whereby a response typically indicates whether the
   request types - blueprintsRequest, blueprintRequest and
       confsRequest.  The first replaces was successful or not, rather than providing additional data
   to maintain the optionsRequest synchronization between the client and server data.
   In addition, the
       latter allows CCMP clients may also receive the client to get a list of all active conferences.
   3.  Merged all requests into data in
   Notifications.  While the basic operations table.  Added
       summary of RESTful examples (referenced notification method or protocol used by
   some conferencing clients can be independent of the basic operations
       table.
   4.  Added examples showing RESTful approach - i.e., HTTP methods for
       message exchange.
   5.  Removed requestID from CCMP, the schema (it should be handle by same
   data in the
       transport - e.g., HTTP).  Updated schema (based on current
       prototype - it still needs another revision.

   6.  Added placeholders server is used for Notifications both the CCMP 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.

19.  References

19.1.  Normative References

   [RFC2119]  Bradner, S., "Key words Notifications - this
   requires a server application above the transport layer (e.g., HTTP)
   for use maintaining the data, which in RFCs the CCMP model is transparent 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.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework
   the transport protocol.

A.1.  Using SOAP for
              Centralized Conferencing", RFC 5239, June 2008.

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

19.2.  Informative References

   [REST]     Fielding, "Architectural Styles 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 Design 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 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 URI for each object, SOAP can use any
   token.

A.2.  A Language RESTful approach 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 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 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
   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 Format
              Extension Model
   for Centralized Conferencing  (XCON)",
              draft-ietf-xcon-event-package-01 (work in progress),
              September 2008.

   [I-D.royer-calsch-xcal]
              Royer, D., "iCalendar [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 Format (xCal-Basic)",
              draft-royer-calsch-xcal-03 (work in progress),
              October 2005.

   [W3C.REC-soap12-part1-20030624]
              Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
              Nielsen, "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]
              Moreau, J., Mendelsohn, N., Hadley, M., Nielsen, H., 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
              M. Gudgin, "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>.
   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
   Avaya
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA
   NS-Technologies

   Email: cboulton@avaya.com 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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.