tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6503

 
 
 

Centralized Conferencing Manipulation Protocol

Part 3 of 4, p. 47 to 82
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 47 
5.3.11.  extendedRequest and extendedResponse

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

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

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

Top      Up      ToC       Page 48 
   <!-- extendedRequest -->

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

   <!-- extendedRequestType -->

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

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

   <!-- extendedResponse -->

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

Top      Up      ToC       Page 49 
   <!-- extendedResponseType -->

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

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

              Figure 17: Structure of the extendedRequest and
                         extendedResponse Messages

5.3.12.  optionsRequest and optionsResponse

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

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

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

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

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

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

   o  <description> (OPTIONAL): human-readable information about the
      related message.

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

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

   <!-- optionsRequest -->

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

   <!-- optionsResponse -->

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

Top      Up      ToC       Page 51 
   <!-- optionsResponseType -->

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

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

   <!-- options-type -->

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

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

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

Top      Up      ToC       Page 52 
   <!-- standard-message-type -->

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

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

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

Top      Up      ToC       Page 53 
   <!-- operations-type -->

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

              Figure 18: Structure of the optionsRequest and
                         optionsResponse Messages

5.4.  CCMP Response Codes

   All CCMP response messages MUST include a <response-code>.  This
   document defines an IANA registry for the CCMP response codes, as
   described in Section 12.5.2.  The following summarizes the CCMP
   response codes:

   200 Success:

      Successful completion of the requested operation.

   400 Bad Request:

      Syntactically malformed request.

   401 Unauthorized:

      User not allowed to perform the required operation.

   403 Forbidden:

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

   404 Object Not Found:

      The target conference object does not exist at the server (The
      object in the error message refers to the <confObjID> parameter in
      the generic request message).

   409 Conflict:

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

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

   420 User Not Found:

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

   421 Invalid confUserID:

      User does not exist at the server (This code is returned for
      requests where the <confUserID> parameter is invalid).

   422 Invalid Conference Password:

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

   423 Conference Password Required:

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

   424 Authentication Required:

      User's authentication information is missing or invalid.

   425 Forbidden Delete Parent:

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

   426 Forbidden Change Protected:

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

   427 Invalid Domain Name:

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

Top      Up      ToC       Page 55 
   500 Server Internal Error:

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

   501 Not Implemented:

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

   510 Request Timeout:

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

   511 Resources Not Available:

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

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

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

             Table 2: Response Codes and Associated Operations

   (*) "420" in answer to a "userRequest/create" operation: In the case
   of a third-party invite, this code can be returned if the
   <confUserID> (contained in the 'entity' attribute of the <userInfo>
   parameter) of the user to be added is unknown.  In the case above, if
   instead it is the <confUserID> parameter of the sender of the request
   that is invalid, a <response-code> of "421" is returned to the
   client.

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

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

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

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

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

6.  A Complete Example of CCMP in Action

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

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

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

   3.  Alice decides to create a new conference by cloning the retrieved
       blueprint (Section 6.3);

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

Top      Up      ToC       Page 58 
   5.  Alice specifies a list of users to be contacted when the
       conference is activated (Section 6.5);

   6.  Alice joins the conference (Section 6.6);

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

   8.  Alice asks for the CCMP server capabilities (Section 6.8);

   9.  Alice exploits an extension of the CCMP server (Section 6.9).

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

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

6.1.  Alice Retrieves the Available Blueprints

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

   Alice retrieves from the server the list of available blueprints:

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

Top      Up      ToC       Page 59 
  1. blueprintsRequest message:

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

  2. blueprintsResponse message from the server:

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

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

               Figure 19: Getting Blueprints from the Server

6.2.  Alice Gets Detailed Information about a Specific Blueprint

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

Top      Up      ToC       Page 61 
   Alice retrieves detailed information about a specified blueprint:

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

 1. blueprintRequest message:

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

 2. blueprintResponse message from the server:

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

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

         Figure 20: Getting Information about a Specific Blueprint

6.3.  Alice Creates a New Conference through a Cloning Operation

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

Top      Up      ToC       Page 63 
   notice that this value is equal to the value of the 'entity'
   attribute of the <conference-info> element of the document
   representing the newly created conference object.

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

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

1. confRequest message:

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

Top      Up      ToC       Page 64 
2. confResponse message from the server:

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

        Figure 21: Creating a New Conference by Cloning a Blueprint

Top      Up      ToC       Page 65 
6.4.  Alice Updates Conference Information

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

   Alice updates information about the conference she just created:

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

 1. confRequest message:

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

Top      Up      ToC       Page 66 
     <confObjID>xcon:8977794@example.com</confObjID>
     <operation>update</operation>
     <ccmp:confRequest>
          <confInfo entity="xcon:8977794@example.com">
             <info:conference-description>
               <info:display-text>
                  Alice's conference
               </info:display-text>
             </info:conference-description>
          </confInfo>
       </ccmp:confRequest>
   </ccmpRequest>
 </ccmp:ccmpRequest>

 2. confResponse message from the server:

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

                Figure 22: Updating Conference Information

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

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

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

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

 1. usersRequest message:

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

Top      Up      ToC       Page 68 
 2. usersResponse message from the server:

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

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

6.6.  Alice Joins the Conference

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

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

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

 1. userRequest message:

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

Top      Up      ToC       Page 70 
 2. userResponse message from the server:

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

            Figure 24: Alice Joins the Conference through CCMP

6.7.  Alice Adds a New User to the Conference

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

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

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


1. "third-party" userRequest message from Alice:

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

Top      Up      ToC       Page 72 
        </ccmp:userRequest>
    </ccmpRequest>
</ccmp:ccmpRequest>

2. "third-party" userResponse message from the server:

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

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

6.8.  Alice Asks for the CCMP Server Capabilities

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

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

Top      Up      ToC       Page 73 
   o  the server doesn't support sidebarsByValRequest nor the
      sidebarByValRequest messages, since they do not appear in the
      <standard-message-list>;

   o  the only implemented operation for the blueprintRequest message is
      "retrieve", since no other <operation> entries are included in the
      related <operations> field.

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

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

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

 1. optionsRequest (Alice asks for CCMP server capabilities)

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

Top      Up      ToC       Page 74 
     </ccmpRequest>
   </ccmp:ccmpRequest>

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

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

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

         Figure 26: Alice Asks for the Server Control Capabilities

6.9.  Alice Makes Use of a CCMP Server Extension

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

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

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

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

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

Top      Up      ToC       Page 76 
         </xs:sequence>
       </xs:complexType>

     </xs:schema>

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

   As can be inferred from the schema file, the <confSummary> element
   contains conference information related to the following:

   o  title

   o  status (active or registered)

   o  participation modality (if everyone is allowed to participate, the
      boolean <public> element is set to "true")

   o  involved media

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

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

Top      Up      ToC       Page 77 
1. extendedRequest (Alice makes use of the "confSummaryRequest")

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

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

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

       Figure 28: Alice Exploits the 'confSummaryRequest' Extension

Top      Up      ToC       Page 78 
7.  Locating a Conference Server

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

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

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

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

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

             Figure 29: Sample XCON-CCMP Service NAPTR Records

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

8.  Managing Notifications

   As per [RFC5239], CCMP is one of the following four protocols, which
   have been formally identified within the XCON framework:

   Conference Control Protocol:

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

   Binary floor Control Protocol:

      operates between the floor control client and the floor control
      server.  An example of such a protocol is the Binary Floor Control
      Protocol (BFCP), specified in [RFC4582].

   Call Signaling Protocol:

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

Top      Up      ToC       Page 80 
   Notification Protocol:

      operates between the Notification Client and the XCON Notification
      Service.  This specification does not define a new notification
      protocol.  For clients that use SIP as the call signaling
      protocol, the XCON event package [RFC6502] MUST be used by the
      client for notifications of changes in the conference data as
      described below.

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

   When the conferencing control client uses SIP [RFC3261] as the
   signaling protocol to participate in the conference, SIP event
   notification can be used.  In such a case, the conferencing control
   client MUST implement the conference event package for XCON
   [RFC6502].  This is the default mechanism for conferencing clients as
   is SIP for signaling per the XCON framework [RFC5239].

   In the case where the interface to the conference server is entirely
   web based, there is a common mechanism for web-based systems that
   could be used -- a "call back".  With this mechanism, the
   conferencing client provides the conference server with an HTTP URL
   that is invoked when a change occurs.  This is a common
   implementation mechanism for e-commerce.  This works well in the
   scenarios whereby the conferencing client is a web server that
   provides the graphical HTML user interface and uses CCMP as the back-
   end interface to the conference server.  This model can coexist with
   the SIP event notification model.  PC-based clients behind NATs could
   provide a SIP event URI, whereas web-based clients using CCMP in the
   back end would probably find the HTTP call back approach much easier.
   The details of this approach are out of scope for CCMP; thus, we
   expect a future specification will document this solution.

9.  HTTP Transport

   This section describes the use of HTTP [RFC2616] and HTTP over TLS
   [RFC2818] as transport mechanisms for CCMP, which a conforming
   conference server and conferencing client MUST support.

Top      Up      ToC       Page 81 
   Although CCMP uses HTTP as a transport, it uses a strict subset of
   HTTP features, and due to the restrictions of some features, a
   conferencing server might not be a fully compliant HTTP server.  It
   is intended that a conference server can easily be built using an
   HTTP server with extensibility mechanisms, and that a conferencing
   client can trivially use existing HTTP libraries.  This subset of
   requirements helps implementers avoid ambiguity with the many options
   the full HTTP protocol offers.

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

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

   The MIME type of CCMP request and response bodies is "application/
   ccmp+xml".  The conference server and conferencing client MUST
   provide this value in the HTTP Content-Type and Accept header fields.
   If the conference server does not receive the appropriate Content-
   Type and Accept header fields, the conference server SHOULD fail the
   request, returning a 406 (Not Acceptable) response.  CCMP responses
   SHOULD include a Content-Length header.

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

   The POST method is the only method REQUIRED for CCMP.  If a
   conference server chooses to support GET or HEAD, it SHOULD consider
   the kind of application doing the GET.  Since a conferencing client
   only uses a POST method, the GET or HEAD MUST be either a URL that
   was found outside its normal context (e.g., somebody found a URL in
   protocol traces or log files and fed it into their browser) or
   somebody is testing or debugging a system.  The conference server
   could provide information in the CCMP response indicating that the
   URL corresponds to a conference server and only responds to CCMP POST
   requests or the conference server could instead try to avoid any leak
   of information by returning a very generic HTTP error message such as
   405 (Method Not Allowed).

Top      Up      ToC       Page 82 
   The conference server populates the HTTP headers of responses so that
   they are consistent with the contents of the message.  In particular,
   the CacheControl header SHOULD be set to disable caching of any
   conference information by HTTP intermediaries.  Otherwise, there is
   the risk of stale information and/or the unauthorized disclosure of
   the information.  The HTTP status code MUST indicate a 2xx series
   response for all CCMP Response and Error messages.

   The conference server MAY redirect a CCMP request.  A conference
   server MUST NOT include CCMP responses in a 3xx response.  A
   conferencing client MUST handle redirects by using the Location
   header provided by the server in a 3xx response.  When redirecting,
   the conferencing client MUST observe the delay indicated by the
   Retry-After header.  The conferencing client MUST authenticate the
   server that returns the redirect response before following the
   redirect.  A conferencing client SHOULD authenticate the conference
   server indicated in a redirect.

   The conference server SHOULD support persistent connections and
   request pipelining.  If pipelining is not supported, the conference
   server MUST NOT allow persistent connections.  The conference server
   MUST support termination of a response by the closing of a
   connection.

   Implementations of CCMP that implement HTTP transport MUST implement
   transport over TLS [RFC2818].  TLS provides message integrity and
   confidentiality between the conferencing client and the conference
   server.  The conferencing client MUST implement the server
   authentication method described in HTTPS [RFC2818].  The device uses
   the URI obtained during conference server discovery to authenticate
   the server.  The details of this authentication method are provided
   in Section 3.1 of HTTPS [RFC2818].  When TLS is used, the
   conferencing client SHOULD fail a request if server authentication
   fails.



(page 82 continued on part 4)

Next RFC Part