Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6503

Centralized Conferencing Manipulation Protocol

Pages: 119
Proposed Standard
Errata
Part 2 of 4 – Pages 13 to 47
First   Prev   Next

Top   ToC   RFC6503 - Page 13   prevText

5. CCMP Messages

CCMP messages are either requests or responses. The general CCMP request message is defined in Section 5.1. The general CCMP response message is defined in Section 5.2. The details of the specific message type that is carried in the CCMP request and response messages are described in Section 5.3. CCMP response codes are listed in Section 5.4.

5.1. CCMP Request Message Type

A CCMP request message is comprised of the following parameters: subject: An OPTIONAL parameter containing the username and password of the client registered at the conferencing system. Each user who subscribes to the conferencing system is assumed to be equipped with those credentials and SHOULD enclose them in each CCMP request she issues. These fields can be used to control that the user sending the CCMP request has the authority to perform the requested operation. The same fields can also be used for other authorization and authentication procedures.
Top   ToC   RFC6503 - Page 14
   confUserID:  An OPTIONAL parameter containing the XCON-USERID of the
      client.  The XCON-USERID is used to identify any conferencing
      client within the context of the conferencing system and it is
      assigned by the conference server for each conferencing client who
      interacts with it.  The <confUserID> parameter is REQUIRED in the
      CCMP request and response messages with the exception of the case
      of a user who has no XCON-USERID and who wants to enter, via CCMP,
      a conference whose identifier is known.  In such case, a side
      effect of the request is that the user is provided with an
      appropriate XCON-USERID.  An example of the aforementioned case
      will be provided in Section 5.3.6.

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

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

   conference-password:  The parameter is OPTIONAL except that it MUST
      be inserted in all requests whose target conference object is
      password-protected i.e., contains the <conference-password>
      element in [RFC6501]).  A CCMP <response-code> of "423" MUST be
      returned if a conference-password is not included in the request
      when required.

   specialized request message:  This is a specialization of the generic
      request message (e.g., blueprintsRequest), containing parameters
      that are dependent on the specific request sent to the server.  A
      specialized request message MUST be included in the CCMP request
      message.  The details for the specialized messages and associated
      parameters are provided in Section 5.3.
Top   ToC   RFC6503 - Page 15
   <!-- Definition of CCMP Request -->

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

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

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

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

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

               Figure 2: Structure of CCMP Request Messages

5.2. CCMP Response Message Type

A CCMP response message is comprised of the following parameters: confUserID: A REQUIRED parameter in CCMP response messages containing the XCON-USERID of the conferencing client that issued the CCMP request message. confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
Top   ToC   RFC6503 - Page 16
   operation:  An OPTIONAL parameter for CCMP response messages.  This
      parameter is REQUIRED in all responses except for the
      "blueprintsResponse" and "confsResponse" specialized messages.

   response-code:  A REQUIRED parameter containing the response code
      associated with the request.  The response code MUST be chosen
      from the codes listed in Section 5.4.

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

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

   specialized response message:  This is specialization of the generic
      response message, containing parameters that are dependent on the
      specific request sent to the server (e.g., "blueprintsResponse").
      A specialized response message SHOULD be included in the CCMP
      response message, except in an error situation where the CCMP
      request message did not contain a valid specialized message.  In
      this case, the conference server MUST return a <response-code> of
      "400".  The details for the specialized messages and associated
      parameters are provided in Section 5.3.
Top   ToC   RFC6503 - Page 17
   <!-- Definition of CCMP Response -->

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

   <!-- Definition of ccmp-response-type -->

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

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

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

               Figure 3: Structure of CCMP Response Message

5.3. Detailed Messages

Based on the request and response message structures described in Sections 5.1 and 5.2, the following summarizes the specialized CCMP request and response types described in this document: 1. blueprintsRequest/blueprintsResponse 2. confsRequest/confsResponse
Top   ToC   RFC6503 - Page 18
   3.   blueprintRequest/blueprintResponse

   4.   confRequest/confResponse

   5.   usersRequest/usersResponse

   6.   userRequest/userResponse

   7.   sidebarsByValRequest/sidebarsByValResponse

   8.   sidebarsByRefRequest/sidebarsByRefResponse

   9.   sidebarByValRequest/sidebarByValResponse

   10.  sidebarByRefRequest/sidebarByRefResponse

   11.  extendedRequest/extendedResponse

   12.  optionsRequest/optionsResponse

   These CCMP request/response pairs use the fundamental CCMP operations
   as defined in Section 4.1 to manipulate the conference data.  These
   request/response pairs are included in an IANA registry as defined in
   Section 12.5.  Table 1 summarizes the remaining CCMP operations and
   corresponding actions that are valid for a specific CCMP request
   type, noting that neither the blueprintsRequest/blueprintsResponse
   nor confsRequest/confsResponse require an <operation> parameter.  An
   entity MUST support the response message for each of the request
   messages that is supported.  The corresponding response message MUST
   contain the same <operation> parameter.  Note that some entries are
   labeled "N/A", indicating that the operation is invalid for that
   request type.  In the case of an "N/A*" label, the operation MAY be
   allowed for specific privileged users or system administrators but is
   not part of the functionality included in this document.
Top   ToC   RFC6503 - Page 19
   +---------------+------------+------------+------------+------------+
   | Operation     |  Retrieve  |   Create   |   Update   |   Delete   |
   | ------------- |            |            |            |            |
   | Request Type  |            |            |            |            |
   +---------------+------------+------------+------------+------------+
   | blueprints    |  Get list  |     N/A    |     N/A    |     N/A    |
   | Request       |     of     |            |            |            |
   |               | blueprints |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | blueprint     |     Get    |    N/A*    |    N/A*    |    N/A*    |
   | Request       |  blueprint |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | confsRequest  |  Get list  |     N/A    |     N/A    |     N/A    |
   |               |  of confs  |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | confRequest   |     Get    |   Create   |   Change   |   Delete   |
   |               | conference | conference | conference | conference |
   |               |   object   |   object   |   object   |   object   |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | usersRequest  |     Get    |   N/A(**)  |   Change   |   N/A(**)  |
   |               |   <users>  |            |   <users>  |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | userRequest   |     Get    |    Add a   |   Change   |   Delete   |
   |               |  specified |  <user> to |  specified |  specified |
   |               |   <user>   |   a conf   |   <user>   |   <user>   |
   |               |            |    (***)   |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarsByVal |     Get    |     N/A    |     N/A    |     N/A    |
   | Request       | <sidebars- |            |            |            |
   |               |   by-val>  |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarsByRef |     Get    |     N/A    |     N/A    |     N/A    |
   | Request       | <sidebars- |            |            |            |
   |               |   by-ref>  |            |            |            |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarByValR |     Get    |   Create   |   Change   |   Delete   |
   | equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
   |               |   by-val   |   by-val   |   by-val   |   by-val   |
   | ------------- | ---------- | ---------- | ---------- | ---------- |
   | sidebarByRefR |     Get    |   Create   |   Change   |   Delete   |
   | equest        |  sidebar-  |  sidebar-  |  sidebar-  |  sidebar-  |
   |               |   by-ref   |   by-ref   |   by-ref   |   by-ref   |
   +---------------+------------+------------+------------+------------+

            Table 1: Request Type Operation-Specific Processing
Top   ToC   RFC6503 - Page 20
   (**): These operations are not allowed for a usersRequest message,
   since the <users> section, which is the target element of such a
   request, is created and removed in conjunction with the creation and
   deletion, respectively, of the associated conference document.  Thus,
   "update" and "retrieve" are the only semantically correct operations
   for such message.

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

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

5.3.1. blueprintsRequest and blueprintsResponse

A blueprintsRequest (Figure 4) message is sent to request the list of XCON-URIs associated with the available blueprints from the conference server. These XCON-URIs can be subsequently used by the client to access detailed information about a specified blueprint with a specific blueprintRequest message per Section 5.3.3. The <confUserID> parameter MUST be included in every blueprintsRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. Since a blueprintsRequest message is not targeted to a specific conference instance and is a "retrieve-only" request, the <confObjID> and <operation> parameters MUST NOT be included in the blueprintsRequest/Response messages. In order to obtain a specific subset of the available blueprints, a client may specify a selection filter providing an appropriate xpath query in the OPTIONAL "xpathFilter" parameter of the request. The information in the blueprints typically represents general capabilities and characteristics. For example, to select blueprints having both audio and video stream support, a possible xpathFilter value could be: "/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']". A conference server SHOULD NOT provide any sensitive information (e.g., passwords) in the blueprints. The associated blueprintsResponse message SHOULD contain, as shown in Figure 4, a "blueprintsInfo" parameter containing the above mentioned XCON-URI list.
Top   ToC   RFC6503 - Page 21
 <!-- blueprintsRequest -->
 <xs:complexType name="ccmp-blueprints-request-message-type">
     <xs:complexContent>
         <xs:extension base="tns:ccmp-request-message-type">
             <xs:sequence>
                 <xs:element ref="blueprintsRequest" />
             </xs:sequence>
         </xs:extension>
     </xs:complexContent>
 </xs:complexType>

 <!-- blueprintsRequestType -->

 <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>

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

 <!-- blueprintsResponse -->

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

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

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

             Figure 4: Structure of the blueprintsRequest and
                        blueprintsResponse Messages

5.3.2. confsRequest and confsResponse

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

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

 <!-- confsRequestType -->

 <xs:element name="confsRequest" type="confsRequestType" />

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

 <!-- confsResponse -->

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

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

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

    Figure 5: Structure of the confsRequest and confsResponse Messages

5.3.3. blueprintRequest and blueprintResponse

Through a blueprintRequest, a client can manipulate the conference object associated with a specified blueprint. Along with the <confUserID> parameter, the request MUST include the <confObjID> and the <operation> parameters. Again, the <confUserID> parameter MUST be included in every blueprintRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. The <confObjID> parameter MUST contain the XCON-URI of the blueprint, which might have been previously retrieved through a blueprintsRequest message. The blueprintRequest message SHOULD NOT contain an <operation> parameter with a value other than "retrieve". An <operation> parameter with a value of "create", "update", or "delete" SHOULD NOT be included in a blueprintRequest message except in the case of privileged users (e.g., the conference server administration staff), who might authenticate themselves by the mean of the "subject" request parameter. A blueprintRequest/retrieve carrying a <confObjID> parameter whose value is not associated with one of the available system's blueprints, will generate, on the server's side, a blueprintResponse message containing a <response-code> of "404". This also holds for the case in which the mentioned <confObjID> parameter value is related to an existing conference document stored at the server, but associated with an actual conference (be it active or registered) or with a sidebar rather than a blueprint.
Top   ToC   RFC6503 - Page 25
   For a <response-code> of "200" in a "retrieve" operation, the
   <blueprintInfo> parameter MUST be included in the blueprintResponse
   message.  The <blueprintInfo> parameter contains the conference
   document associated with the blueprint as identified by the
   <confObjID> parameter specified in the blueprintRequest.

   <!--  blueprintRequest -->

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

   <!-- blueprintRequestType -->

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

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

   <!-- blueprintResponse -->

   <xs:complexType name="ccmp-blueprint-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintResponse" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>
Top   ToC   RFC6503 - Page 26
   <!-- blueprintResponseType -->

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

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

              Figure 6: Structure of the blueprintRequest and
                        blueprintResponse Messages

5.3.4. confRequest and confResponse

With a confRequest message, CCMP clients can manipulate conference objects associated with either active or registered conferences. The <confUserID> parameter MUST be included in every confRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. confRequest and confResponse messages MUST also include an <operation> parameter. ConfResponse messages MUST return to the requestor a <response-code> and MAY contain a <response- string> explaining it. Depending upon the type of operation, a <confObjID> and <confInfo> parameter MAY be included in the confRequest and response. For each type of operation, the text below describes whether the <confObjID> and <confInfo> parameters need to be included in the confRequest and confResponse messages. The creation case deserves care. To create a new conference through a confRequest message, two approaches can be considered: 1. Creation through explicit cloning: the <confObjID> parameter MUST contain the XCON-URI of the blueprint or of the conference to be cloned, while the <confInfo> parameter MUST NOT be included in the confRequest. Note that cloning of an active conference is only done in the case of a sidebar operation per the XCON framework and as described in Section 5.3.8. 2. Creation through implicit cloning (also known as "direct creation"): the <confObjID> parameter MUST NOT be included in the request and the CCMP client can describe the desired conference to be created using the <confInfo> parameter. If no <confInfo> parameter is provided in the request, the new conference will be created as a clone of the system default blueprint.
Top   ToC   RFC6503 - Page 27
   In both creation cases, the confResponse, for a successful completion
   of a "create" operation, contains a <response-code> of "200" and MUST
   contain the XCON-URI of the newly created conference in the
   <confObjID> parameter, in order to allow the conferencing client to
   manipulate that conference through following CCMP requests.  In
   addition, the <confInfo> parameter containing the conference document
   created MAY be included, at the discretion of the conferencing system
   implementation, along with the REQUIRED <version> parameter
   initialized at "1", since, at creation time, the conference object is
   at its first version.

   In the case of a confRequest with an <operation> parameter of
   "retrieve", the <confObjID> parameter representing the XCON-URI of
   the target conference MUST be included and the <confInfo> parameter
   MUST NOT be included in the request.  The conference server MUST
   ignore any <confInfo> parameter that is received in a confRequest
   "retrieve" operation.  If the confResponse for the retrieve operation
   contains a <response-code> of "200", the <confInfo> parameter MUST be
   included in the response.  The <confInfo> parameter MUST contain the
   entire conference document describing the target conference object in
   its current state.  The current state of the retrieved conference
   object MUST also be reported in the proper "version" response
   parameter.

   In case of a confRequest with an <operation> parameter of "update",
   the <confInfo> and <confObjID> parameters MUST be included in the
   request.  The <confInfo> represents an object of type
   "conference-type" containing all the changes to be applied to the
   conference whose identifier has the same value as the <confObjID>
   parameter.  Note that, in such a case, though the <confInfo>
   parameter indeed has to follow the rules indicated in the XCON data
   model, it does not represent the entire updated version of the target
   conference, since it conveys just the modifications to apply to that
   conference.  For example, in order to change the conference title,
   the <confInfo> parameter will be of the form:

   <confInfo entity="xcon:8977777@example.com">
     <conference-description>
       <display-text> *** NEW CONFERENCE TITLE *** </display-text>
     </conference-description>
   </confInfo>

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

   Similarly, to remove the title of an existing conference, a
   confRequest/update carrying the following <confInfo> parameter would
   do the job.
Top   ToC   RFC6503 - Page 28
   <confInfo entity="xcon:8977777@example.com">
     <conference-description>
       <display-text/>
     </conference-description>
   </confInfo>

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

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

   In the case of a confRequest with an <operation> parameter of
   "delete", the <confObjID> parameter representing the XCON-URI of the
   target conference MUST be included while the <confInfo> parameter
   MUST NOT be included in the request.  The conference server MUST
   ignore any <confInfo> parameter that is received within such a
   request.  The confResponse MUST contain the same value for the
   <confObjID> parameter that was included in the confRequest.  If the
   confResponse/delete operation contains a <response-code> of "200",
   the conference indicated in the <confObjID> parameter has been
   successfully deleted.  A confResponse/delete with a <response-code>
   of "200" MUST NOT contain the <confInfo> parameter.  The <version>
   parameter SHOULD NOT be returned in any confResponse/delete.  If the
   conference server cannot delete the conference referenced by the
   <confObjID> parameter received in the confRequest because it is the
   parent of another conference object that is in use, the conference
   server MUST return a <response-code> of "425".
Top   ToC   RFC6503 - Page 29
   A confRequest with an <operation> parameter of "retrieve", "update",
   or "delete" carrying a <confObjID> parameter which is not associated
   with one of the conferences (active or registered) that the system is
   holding will generate, on the server's side, a confResponse message
   containing a <response-code> of "404".  This also holds for the case
   in which the mentioned <confObjID> parameter is related to an
   existing conference object stored at the server, but associated with
   a blueprint or with a sidebar rather than an actual conference.

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

   <!-- confRequest -->

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

   <!-- confRequestType -->

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

   <xs:complexType name="confRequestType">
       <xs:sequence>
           <xs:element name="confInfo" type="info:conference-type"
                       minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
Top   ToC   RFC6503 - Page 30
   <!-- confResponse -->

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

   <!-- confResponseType -->

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

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

     Figure 9: Structure of the confRequest and confResponse Messages

5.3.5. usersRequest and usersResponse

The usersRequest message allows a client to manipulate the <users> element of the conference object represented by the <confObjID> parameter. The <users> element contains the list of <user> elements associated with conference participants, the list of the users to which access to the conference is allowed/denied, conference participation policies, etc. The <confObjID> parameter MUST be included in a usersRequest message. A <usersInfo> parameter MAY be included in a usersRequest message depending upon the operation. If the <usersInfo> parameter is included in the usersRequest message, the parameter MUST be compliant with the <users> field of the XCON data model. Two operations are allowed for a usersRequest message: 1. "retrieve": In this case the request MUST NOT include a <usersInfo> parameter, while the successful response MUST contain the desired <users> element in the <usersInfo> parameter. The
Top   ToC   RFC6503 - Page 31
       conference server MUST ignore a <usersInfo> parameter if it is
       received in a request with an <operation> parameter of
       "retrieve".

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

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

   <!-- usersRequest -->

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

   <!-- usersRequestType -->

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

   <xs:complexType name="usersRequestType">
       <xs:sequence>
           <xs:element name="usersInfo"
                       type="info:users-type" minOccurs="0" />
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
Top   ToC   RFC6503 - Page 32
   <!-- usersResponse -->

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

   <!-- usersResponseType -->

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

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

    Figure 10: Structure of the usersRequest and usersResponse Messages

5.3.6. userRequest and userResponse

A userRequest message is used to manipulate <user> elements inside a conference document associated with a conference identified by the <confObjID> parameter. Besides retrieving information about a specific conference user, the message is used to request that the conference server either create, modify, or delete information about a user. A userRequest message MUST include the <confObjID> and the <operation> parameters, and it MAY include a <userInfo> parameter containing the detailed user's information depending upon the operation and whether the <userInfo> has already been populated for a specific user. Note that a user may not necessarily be a conferencing control client (i.e., some participants in a conference are not "XCON aware"). An XCON-USERID SHOULD be assigned to each and every user subscribed to the system. In such a way, a user who is not a conference participant can make requests (provided she has successfully passed authorization and authentication checks), like creating a conference or retrieving conference information.
Top   ToC   RFC6503 - Page 33
   Conference users can be created in a number of different ways.  In
   each of these cases, the <operation> parameter MUST be set to
   "create" in the userRequest message.  Each of the userResponse
   messages for these cases MUST include the <confObjID>, <confUserID>,
   <operation>, and <response-code> parameters.  In the case of a
   <response-code> of "200", the userResponse message MAY include the
   <userInfo> parameter depending upon the manner in which the user was
   created:

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

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

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

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

   <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
           <endpoint entity="sip:GHIL345@example.com">
           ...


   Response fields (in case of success):

   confUserID=user345;
   confObjID=confXYZ;
   operation=create;
   response-code=200;
   userInfo=null; //or the entire userInfo object

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

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

   In the case of a userRequest with an <operation> parameter of
   "retrieve", the <confObjID> parameter representing the XCON-URI of
   the target conference MUST be included.  The <confUserID>, containing
   the CCMP client's XCON-USERID, MUST also be included in the
Top   ToC   RFC6503 - Page 35
   userRequest message.  If the client wants to retrieve information
   about her profile in the specified conference, no <userInfo>
   parameter is needed in the retrieve request.  On the other hand, if
   the client wants to obtain someone else's info within the given
   conference, she MUST include in the userRequest/retrieve a <userInfo>
   parameter whose 'entity' attribute conveys the desired user's XCON-
   USERID.  If the userResponse for the retrieve operation contains a
   <response-code> of "200", the <userInfo> parameter MUST be included
   in the response.

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

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

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

   <!-- userRequestType -->

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

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

   <!-- userResponse -->

   <xs:complexType name="ccmp-user-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                   <xs:element ref="userResponse" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>
Top   ToC   RFC6503 - Page 37
   <!-- userResponseType -->

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

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

     Figure 12: Structure of the userRequest and userResponse Messages

5.3.7. sidebarsByValRequest and sidebarsByValResponse

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

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

 <!-- sidebarsByValRequestType -->

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

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


 <!-- sidebarsByValResponse -->

 <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
         <xs:complexContent>
          <xs:extension base="tns:ccmp-response-message-type">
                 <xs:sequence>
            <xs:element ref="sidebarsByValResponse"/>
           </xs:sequence>
          </xs:extension>
         </xs:complexContent>
 </xs:complexType>
Top   ToC   RFC6503 - Page 39
 <!-- sidebarsByValResponseType -->

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

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

           Figure 13: Structure of the sidebarsByValRequest and
                      sidebarsByValResponse Messages

5.3.8. sidebarByValRequest and sidebarByValResponse

A sidebarByValRequest message MUST contain the <operation> parameter, which distinguishes among retrieval, creation, modification, and deletion of a specific sidebar. The other required parameters depend upon the type of operation. In the case of a "create" operation, the <confObjID> parameter MUST be included in the sidebyValRequest message. In this case, the <confObjID> parameter contains the XCON-URI of the main conference in which the sidebar has to be created. If no "sidebarByValInfo" parameter is included, the sidebar is created by cloning the main conference, as envisioned in the XCON framework [RFC5239] following the implementation specific cloning rules. Otherwise, similar to the case of direct creation, the sidebar conference object is built on the basis of the "sidebarByValInfo" parameter provided by the requestor. As a consequence of a sidebar-by-val creation, the conference server MUST update the main conference object reflected by the <confObjID> parameter in the sidebarbyValRequest/create message introducing the new sidebar object as a new <entry> in the proper section <sidebars-by-val>. The newly created sidebar conference object MAY be included in the sidebarByValResponse in the <sidebarByValInfo> parameter, if the <response-code> is "200". The XCON-URI of the newly created sidebar MUST appear in the <confObjID> parameter of the response. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the addition of the sidebar to the conference.
Top   ToC   RFC6503 - Page 40
   In the case of a sidebarByValRequest message with an <operation>
   parameter of "retrieve", the URI for the conference object created
   for the sidebar (received in response to a create operation or in a
   sidebarsByValResponse message) MUST be included in the <confObjID>
   parameter in the request.  This retrieve operation is handled by the
   conference server in the same manner as in the case of an <operation>
   parameter of "retrieve" included in a confRequest message, as
   described in Section 5.3.4.

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

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

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

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

   <!-- sidebarByValRequestType -->

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

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


   <!-- sidebarByValResponse -->

   <xs:complexType name="ccmp-sidebarByVal-response-message-type">
    <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
            <xs:sequence>
                   <xs:element ref="sidebarByValResponse"/>
            </xs:sequence>
     </xs:extension>
    </xs:complexContent>
   </xs:complexType>
Top   ToC   RFC6503 - Page 42
   <!-- sidebarByValResponseType -->

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

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

            Figure 14: Structure of the sidebarByValRequest and
                       sidebarByValResponse Messages

5.3.9. sidebarsByRefRequest and sidebarsByRefResponse

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

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

   <!-- sidebarsByRefRequestType -->

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

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

   <!-- sidebarsByRefResponse -->

   <xs:complexType name="ccmp-sidebarsByref-response-message-type">
           <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
                    <xs:sequence>
                           <xs:element ref="sidebarsByRefResponse"/>
                    </xs:sequence>
            </xs:extension>
     </xs:complexContent>
   </xs:complexType>
Top   ToC   RFC6503 - Page 44
   <!-- sidebarsByRefResponseType -->

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

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

             Figure 15: Structure of the sidebarsByRefRequest
                    and sidebarsByRefResponse Messages

5.3.10. sidebarByRefRequest and sidebarByRefResponse

A sidebarByValResponse message MUST return to the client a <version> element related to the current version of the sidebar whose identifier is contained in the <confObjID> field of the request. In the case of a create operation, the <confObjID> parameter MUST be included in the sidebyRefRequest message. In this case, the <confObjID> parameter contains the XCON-URI of the main conference in which the sidebar has to be created. If no <sidebarByRefInfo> parameter is included, following the XCON framework [RFC5239], the sidebar is created by cloning the main conference, observing the implementation-specific cloning rules. Otherwise, similar to the case of direct creation, the sidebar conference object is built on the basis of the <sidebarByRefInfo> parameter provided by the requestor. If the creation of the sidebar is successful, the conference server MUST update the <sidebars-by-ref> element in the conference object from which the sidebar was created (i.e., as identified by the <confObjID> in the original sidebarByRefRequest), with the URI of the newly created sidebar. The newly created conference object MAY be included in the response in the <sidebarByRefInfo> parameter with a <response-code> of "200". The URI for the conference object associated with the newly created sidebar object MUST appear in the <confObjID> parameter of the response. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the addition of the sidebar to the conference.
Top   ToC   RFC6503 - Page 45
   In the case of a sidebarByRefRequest message with an <operation>
   parameter of "retrieve", the URI for the conference object created
   for the sidebar MUST be included in the <confObjID> parameter in the
   request.  A retrieve operation on the <sidebarByRefInfo> is handled
   by the conference server in the same manner as a retrieve operation
   on the confInfo included in a confRequest message as detailed in
   Section 5.3.4.

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

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

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

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

   <!-- sidebarByRefRequestType -->

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

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

   <!-- sidebarByRefResponse -->

   <xs:complexType name="ccmp-sidebarByRef-response-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-response-message-type">
               <xs:sequence>
                   <xs:element ref="sidebarByRefResponse"/>
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>
Top   ToC   RFC6503 - Page 47
   <!-- sidebarByRefResponseType -->

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

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

              Figure 16: Structure of the sidebarByRefRequest
                     and sidebarByRefResponse Messages



(page 47 continued on part 3)

Next Section