RFC 6503
Centralized Conferencing Manipulation Protocol
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.
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.
<!-- 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 Messages5.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.
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.
<!-- 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 Message5.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
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.
+---------------+------------+------------+------------+------------+ | 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
(**): 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.
<!-- 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>
<!-- 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 Messages5.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.
<!-- 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>
<!-- 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 Messages5.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.
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>
<!-- 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 Messages5.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.
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.
<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".
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>
<!-- 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 Messages5.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
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>
<!-- 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 Messages5.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.
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:
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
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.
<!-- 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>
<!-- 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 Messages5.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.
<!-- 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>
<!-- 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 Messages5.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.
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.
<!-- 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>
<!-- 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 Messages5.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.
<!-- 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>
<!-- 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 Messages5.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.
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.
<!-- 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>
<!-- 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)
