Centralized Conferencing Manipulation Protocol
Extracted elements (30)
CCMP uses a versioning mechanism for conference objects so that clients can detect whether their locally cached copy is stale. If a client receives a version of X+2 in a response, it knows the server had a more recent version than what was submitted, and can issue a retrieve to resync. This design avoids requiring the server to reject stale updates outright.
HTTP was chosen as the CCMP transport over SOAP and REST alternatives. HTTP POST was preferred because it allows arbitrary XML payload in the body without constraining the data model to URI path hierarchies, and avoids SOAP's processing overhead. The stateless HTTP model aligns with CCMP's stateless design.
The AUTO_GENERATE_X form (all-uppercase with a numeric suffix) was chosen over random unique strings or non-numeric values so that server processing is simplified: the numeric index makes each distinct placeholder unambiguous without requiring string comparison across arbitrary identifiers.
Users are added to conferences one at a time via individual userRequest/create messages rather than in bulk. This design simplifies error reporting: if adding one user fails, the failure is unambiguous and the remaining users are unaffected. Bulk addition via the usersRequest/update is still possible for updating the <users> element as a whole.
A <conference-password> MUST be inserted in all CCMP requests whose target conference object is password-protected. If required but absent, the server MUST return a response-code of '423'.
A conferencing client with no XCON-USERID who wishes to join a known conference MAY send a userRequest/create with a void <confUserID>; this is the only valid case for a CCMP request with a null confUserID. A <userInfo> parameter with at least a contact URI MUST be included, and the 'entity' attribute MUST use an AUTO_GENERATE_X placeholder. The server returns the newly assigned XCON-USERID in the <confUserID> of the response.
All CCMP response messages containing a conference document (or a fragment thereof) MUST contain a <version> parameter reflecting the current version number of the referenced conference object.
AUTO_GENERATE_X placeholder values MUST appear only within the value part of an attribute or element. If a server receives AUTO_GENERATE_X outside the value part, it MUST return a response-code of '400 Bad Request'. Each distinct wildcard index (e.g., AUTO_GENERATE_1 vs. AUTO_GENERATE_2) MUST be replaced with a different generated identifier within the same document.
Clients MUST NOT wait indefinitely for a CCMP response and MUST implement a timer; when the timer expires, the client MUST close the connection. Thirty seconds is RECOMMENDED as the default; sixty seconds is a reasonable upper range. A server that cannot process pending requests in time SHOULD return a response-code of '510'.
Create and delete operations are not applicable to usersRequest messages and MUST NOT be processed by the server; a response-code of '403' MUST be returned in those cases, since the <users> section is created and removed only in conjunction with creation and deletion of the parent conference document.
For a confRequest create operation via explicit cloning, the <confObjID> MUST contain the XCON-URI of the blueprint or conference to clone, and <confInfo> MUST NOT be included. For direct creation, <confObjID> MUST NOT be present and the client MAY provide <confInfo>; if absent, the system default blueprint is cloned. The confResponse MUST include the XCON-URI of the newly created conference in <confObjID>.
For blueprintsRequest and confsRequest messages, the <confObjID> and <operation> parameters MUST NOT be included, as these are retrieve-only operations for listing available blueprints or conferences. The <confUserID> MUST be included in every such message.
If a conference server cannot delete a conference because it is the parent of another conference object currently in use, the server MUST return a response-code of '425'.
The conference server MUST ensure that operations are atomic: the operation invoked by a specific conferencing client must complete prior to another client's operation on the same conference object.
The <response-code> in a CCMP response is REQUIRED and MUST be chosen from the codes listed in Section 5.4. The <version> parameter is REQUIRED in CCMP response messages and SHOULD NOT be included in CCMP request messages.
CCMP messages may carry identity information including XCON-USERIDs, signaling URIs, display names, and role information. To protect the privacy of conference participants, CCMP traffic SHOULD be protected with TLS, and conference servers SHOULD NOT include sensitive data such as passwords in blueprint responses accessible to unauthorized users.
A CCMP request message contains: optional <subject> (username/password), optional <confUserID> (XCON-USERID, REQUIRED except for a first-time user entry), optional <confObjID> (XCON-URI of target object), optional <operation> (REQUIRED in all requests except blueprintsRequest and confsRequest), optional <conference-password>, and a REQUIRED specialized request message element.
A CCMP response message contains: REQUIRED <confUserID>, optional <confObjID>, optional <operation> (REQUIRED except for blueprintsResponse and confsResponse), REQUIRED <response-code>, optional <response-string>, optional <version> (REQUIRED in responses per Section 5.2), and a SHOULD-included specialized response message element.
CCMP defines a set of numeric response codes analogous to HTTP status codes: 200 (success), 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 409 (conflict), 420 (user not found), 421 (invalid confObjID), 422 (invalid userID), 423 (password required), 424 (authentication required), 425 (cloning tree conflict), 426 (permission denied), 427 (invalid domain), 500 (server error), 510 (server too busy).
CCMP defines twelve specialized request/response message pairs: blueprintsRequest/Response, confsRequest/Response, blueprintRequest/Response, confRequest/Response, usersRequest/Response, userRequest/Response, sidebarsByValRequest/Response, sidebarsByRefRequest/Response, sidebarByValRequest/Response, sidebarByRefRequest/Response, extendedRequest/Response, and optionsRequest/Response.
CCMP is a stateless, XML-based client-server protocol that allows authenticated and authorized clients to create, retrieve, update, and delete conference objects. Requests are carried in HTTP POST bodies and responses in HTTP 200 OK replies. CCMP messages conform to the XCON data model schema defined in RFC 6501.
Conference servers are located using DNS S-NAPTR lookup with the application service tag 'XCON' and the application protocol tag 'XCON:CCMP'. Clients may also use provisioning, configuration, or SIP signaling mechanisms to discover the conference server URI.
The optionsRequest/optionsResponse message pair allows a client to discover the capabilities supported by the CCMP server, including which message types and operations are supported. The optionsResponse SHOULD contain a <optionsInfo> element listing supported features.
When mandatory data model fields are unknown at request construction time (e.g., the XCON-URI of a not-yet-created conference), clients fill those fields with AUTO_GENERATE_X wildcard strings (uppercase, with a unique numeric index X). The server replaces each occurrence with a proper generated identifier and echoes the replacements in the response.
IANA maintains a 'CCMP Message Types' registry (Section 12.5.1) listing the twelve defined request/response message type pairs (e.g., blueprintsRequest/Response, confRequest/Response). New entries require IETF Review. A separate 'CCMP Response Codes' registry (Section 12.5.2) lists all defined numeric response codes with their descriptions.
IANA registers the MIME media type 'application/ccmp+xml' (Section 12.3), a URN sub-namespace 'urn:ietf:params:xml:ns:xcon-ccmp' (Section 12.1), and an XML schema (Section 12.2). DNS application service tag 'XCON' and application protocol tag 'XCON:CCMP' are also registered for S-NAPTR server discovery (Section 12.4).
CCMP requests carry username/password credentials in the <subject> parameter and the XCON-USERID in <confUserID>. Implementations MUST use TLS or equivalent transport security to protect these credentials. The conference server is responsible for authentication and authorization of all CCMP requests before executing operations.
Clients MUST verify they have contacted the correct conference server using TLS server certificate validation, or an equivalent mechanism, to prevent man-in-the-middle attacks and ensure that sensitive conference data and credentials are not disclosed to an impersonating server.
To mitigate DoS attacks, clients MUST implement a connection timeout (30 seconds recommended, 60 seconds maximum) and close connections when the timer expires. Servers SHOULD return response-code '510' when overloaded rather than holding connections open indefinitely.
CCMP messages use the MIME type 'application/ccmp+xml', which MUST appear in the Content-Type and Accept header fields of HTTP requests and responses. XML documents MUST be encoded in UTF-8 and the 'charset' parameter MUST be included with the XML document.