From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6503.txt | 6667 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 6667 insertions(+) create mode 100644 doc/rfc/rfc6503.txt (limited to 'doc/rfc/rfc6503.txt') diff --git a/doc/rfc/rfc6503.txt b/doc/rfc/rfc6503.txt new file mode 100644 index 0000000..6f3f29b --- /dev/null +++ b/doc/rfc/rfc6503.txt @@ -0,0 +1,6667 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Barnes +Request for Comments: 6503 Polycom +Category: Standards Track C. Boulton +ISSN: 2070-1721 NS-Technologies + S. Romano + University of Napoli + H. Schulzrinne + Columbia University + March 2012 + + + Centralized Conferencing Manipulation Protocol + +Abstract + + The Centralized Conferencing Manipulation Protocol (CCMP) allows a + Centralized Conferencing (XCON) system client to create, retrieve, + change, and delete objects that describe a centralized conference. + CCMP is a means to control basic and advanced conference features + such as conference state and capabilities, participants, relative + roles, and details. CCMP is a stateless, XML-based, client server + protocol that carries, in its request and response messages, + conference information in the form of XML documents and fragments + conforming to the centralized conferencing data model schema. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6503. + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 1] + +RFC 6503 CCMP March 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Conventions and Terminology .....................................5 + 3. XCON Conference Control System Architecture .....................5 + 3.1. Conference Objects .........................................7 + 3.2. Conference Users ...........................................7 + 4. Protocol Overview ...............................................8 + 4.1. Protocol Operations ........................................9 + 4.2. Data Management ...........................................10 + 4.3. Data Model Compliance .....................................11 + 4.4. Implementation Approach ...................................12 + 5. CCMP Messages ..................................................13 + 5.1. CCMP Request Message Type .................................13 + 5.2. CCMP Response Message Type ................................15 + 5.3. Detailed Messages .........................................17 + 5.3.1. blueprintsRequest and blueprintsResponse ...........20 + 5.3.2. confsRequest and confsResponse .....................22 + 5.3.3. blueprintRequest and blueprintResponse .............24 + 5.3.4. confRequest and confResponse .......................26 + 5.3.5. usersRequest and usersResponse .....................30 + 5.3.6. userRequest and userResponse .......................32 + 5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37 + 5.3.8. sidebarByValRequest and sidebarByValResponse .......39 + 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42 + 5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44 + 5.3.11. extendedRequest and extendedResponse ..............47 + 5.3.12. optionsRequest and optionsResponse ................49 + 5.4. CCMP Response Codes .......................................53 + 6. A Complete Example of CCMP in Action ...........................57 + 6.1. Alice Retrieves the Available Blueprints ..................58 + 6.2. Alice Gets Detailed Information about a Specific + Blueprint .................................................60 + + + +Barnes, et al. Standards Track [Page 2] + +RFC 6503 CCMP March 2012 + + + 6.3. Alice Creates a New Conference through a Cloning + Operation .................................................62 + 6.4. Alice Updates Conference Information ......................65 + 6.5. Alice Inserts a List of Users into the Conference Object ..66 + 6.6. Alice Joins the Conference ................................68 + 6.7. Alice Adds a New User to the Conference ...................70 + 6.8. Alice Asks for the CCMP Server Capabilities ...............72 + 6.9. Alice Makes Use of a CCMP Server Extension ................75 + 7. Locating a Conference Server ...................................78 + 8. Managing Notifications .........................................79 + 9. HTTP Transport .................................................80 + 10. Security Considerations .......................................82 + 10.1. Assuring That the Proper Conference Server Has + Been Contacted ...........................................83 + 10.2. User Authentication and Authorization ....................84 + 10.3. Security and Privacy of Identity .........................85 + 10.4. Mitigating DoS Attacks ...................................86 + 11. XML Schema ....................................................87 + 12. IANA Considerations ..........................................105 + 12.1. URN Sub-Namespace Registration ..........................105 + 12.2. XML Schema Registration .................................106 + 12.3. MIME Media Type Registration for + 'application/ccmp+xml' ..................................106 + 12.4. DNS Registrations .......................................107 + 12.4.1. Registration of a Conference Server + Application Service Tag ..........................108 + 12.4.2. Registration of a Conference Server + Application Protocol Tag for CCMP ................108 + 12.5. CCMP Protocol Registry ..................................108 + 12.5.1. CCMP Message Types ...............................109 + 12.5.2. CCMP Response Codes ..............................111 + 13. Acknowledgments ..............................................113 + 14. References ...................................................113 + 14.1. Normative References ....................................113 + 14.2. Informative References ..................................114 + Appendix A. Evaluation of Other Protocol Models and + Transports Considered for CCMP ......................116 + A.1. Using SOAP for CCMP ......................................117 + A.2. A RESTful Approach for CCMP ..............................117 + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 3] + +RFC 6503 CCMP March 2012 + + +1. Introduction + + "A Framework for Centralized Conferencing" [RFC5239] (XCON framework) + defines a signaling-agnostic framework, naming conventions, and + logical entities required for building advanced conferencing systems. + The XCON framework introduces the conference object as a logical + representation of a conference instance, representing the current + state and capabilities of a conference. + + The Centralized Conferencing Manipulation Protocol (CCMP) defined in + this document allows authenticated and authorized users to create, + manipulate, and delete conference objects. Operations on conferences + include adding and removing participants, changing their roles, as + well as adding and removing media streams and associated endpoints. + + CCMP implements the client-server model within the XCON framework, + with the conferencing client and conference server acting as client + and server, respectively. CCMP uses HTTP [RFC2616] as the protocol + to transfer requests and responses, which contain the domain-specific + XML-encoded data objects defined in [RFC6501] "Conference Information + Data Model for Centralized Conferencing (XCON)". + + Section 2 clarifies the conventions and terminology used in the + document. Section 3 provides an overview of the conference control + functionality of the XCON framework, together with a description of + the main targets CCMP deals with, namely conference objects and + conference users. A general description of the operations associated + with protocol messages is given in Section 4 together with + implementation details. Section 5 delves into the details of + specific CCMP messages. A complete, non-normative, example of the + operation of CCMP, describing a typical call flow associated with + conference creation and manipulation, is provided in Section 6. A + survey of the methods that can be used to locate a conference server + is provided in Section 7, and Section 8 discusses potential + approaches to notifications management. CCMP transport over HTTP is + highlighted in Section 9. Security considerations are presented in + Section 10. Finally, Section 11 provides the XML schema. + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 4] + +RFC 6503 CCMP March 2012 + + +2. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + In addition to the terms defined in "A Framework for Centralized + Conferencing" [RFC5239], this document uses the following terms and + acronyms: + + XCON-aware client: An XCON conferencing system client that is able + to issue CCMP requests. + + First-Party Request: A request issued by the client to manipulate + its own conferencing data. + + Third-Party Request: A request issued by a client to manipulate the + conference data of another client. + +3. XCON Conference Control System Architecture + + CCMP supports the XCON framework. Figure 1 depicts a subset of the + "Conferencing System Logical Decomposition" architecture from the + XCON framework document. It illustrates the role that CCMP assumes + within the overall centralized architecture. + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 5] + +RFC 6503 CCMP March 2012 + + + ........................................................ + . Conferencing System . + . . + . +---------------------------------------+ . + . | C O N F E R E N C E O B J E C T | . + . +-+-------------------------------------+ | . + . | C O N F E R E N C E O B J E C T | | . + . +-+-------------------------------------+ | | . + . | C O N F E R E N C E O B J E C T | | | . + . | | |-+ . + . | |-+ . + . +---------------------------------------+ . + . ^ . + . | . + . v . + . +-------------------+ . + . | Conference Control| . + . | Server | . + . +-------------------+ . + . ^ . + .........................|.............................. + | + |Centralized + |Conferencing + |Manipulation + |Protocol + | + .........................|.............................. + . V . + . +----------------+ . + . | Conference | . + . | Control | . + . | Client | . + . +----------------+ . + . . + . Conferencing Client . + ........................................................ + + Figure 1: Conferencing Client Interaction + + The Centralized Conferencing Manipulation Protocol (CCMP) allows the + conference control client (conferencing client) to interface with the + conference object maintained by the conferencing system, as depicted + in Figure 1. Note that additional functionality of the conferencing + client and conferencing system is discussed in the XCON framework and + related documents. + + + + + +Barnes, et al. Standards Track [Page 6] + +RFC 6503 CCMP March 2012 + + + This section provides details of the identifiers REQUIRED to address + and manage the clients associated with a conferencing system using + CCMP. + +3.1. Conference Objects + + Conference objects feature a simple dynamic inheritance-and-override + mechanism. Conference objects are linked into a tree known as a + "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree + node inherits attributes from its parent node. The roots of these + inheritance trees are conference templates also known as + "blueprints". Nodes in the inheritance tree can be active + conferences or simply descriptions that do not currently have any + resources associated with them (i.e., conference reservations). An + object can mark certain of its properties as unalterable, so that + they cannot be overridden. Per the framework, a client may specify a + parent object (a conference or blueprint) from which to inherit + values when a conference is created using the conference control + protocol. + + Conference objects are uniquely identified by the XCON-URI within the + scope of the conferencing system. The XCON-URI is introduced in the + XCON framework and defined in the XCON common data model. + + Conference objects are comprehensively represented through XML + documents compliant with the XML schema defined in the XCON data + model [RFC6501]. The root element of such documents, called + , is of type "conference-type". It encompasses + other XML elements describing different conference features and users + as well. Using CCMP, conferencing clients can use these XML + structures to express their preferences in creating or updating a + conference. A conference server can convey conference information + back to the clients using the XML elements. + +3.2. Conference Users + + Each conference can have zero or more users. All conference + participants are users, but some users may have only administrative + functions and do not contribute or receive media. Users are added + one user at a time to simplify error reporting. When a conference is + cloned from a parent object, users are inherited as well, so that it + is easy to set up a conference that has the same set of participants + or a common administrator. The conference server creates individual + users, assigning them a unique conference user identifier (XCON- + USERID). The XCON-USERID as identifier of each conferencing system + client is introduced in the XCON framework and defined in the XCON + + + + + +Barnes, et al. Standards Track [Page 7] + +RFC 6503 CCMP March 2012 + + + common data model. Each CCMP request, with an exception pointed out + in Section 5.3.6 representing the case of a user at his first + entrance in the system as a conference participant, must carry the + XCON-USERID of the requestor in the proper parameter. + + The XCON-USERID acts as a pointer to the user's profile as a + conference actor, e.g., her signaling URI and other XCON protocol + URIs in general, her role (moderator, participant, observer, etc.), + her display text, her joining information, and so on. A variety of + elements defined in the common element as specified + in the XCON data model are used to describe the users related to a + conference including the element, as well as each + element included within it. For example, it is possible to determine + how a specific user expects and is allowed to join a conference by + looking at the in : each element + involved in such a list represents a user and shows a 'method' + attribute defining how the user is expected to join the conference, + i.e., "dial-in" for users that are allowed to dial, "dial-out" for + users that the conference focus will be trying to reach (with + "dial-in" being the default mode). If the conference is currently + active, dial-out users are contacted immediately; otherwise, they are + contacted at the start of the conference. CCMP, acting as the + conference control protocol, provides a means to manipulate these and + other kinds of user-related features. + + As a consequence of an explicit user registration to a specific XCON + conferencing system, conferencing clients are usually provided + (besides the XCON-USERID) with log-in credentials (i.e., username and + password). Such credentials can be used to authenticate the XCON- + aware client issuing CCMP requests. Thus, both username and password + should be carried in a CCMP request as part of the "subject" + parameter whenever a registered conferencing client wishes to contact + a CCMP server. CCMP does not maintain a user's subscriptions at the + conference server; hence, it does not provide any specific mechanism + allowing clients to register their conferencing accounts. The + "subject" parameter is just used for carrying authentication data + associated with pre-registered clients, with the specific + registration modality outside the scope of this document. + +4. Protocol Overview + + CCMP is a client-server, XML-based protocol for user creation, + retrieval, modification, and deletion of conference objects. CCMP is + a stateless protocol, such that implementations can safely handle + transactions independently from each other. CCMP messages are XML + documents or XML document fragments compliant with the XCON data + model representation [RFC6501]. + + + + +Barnes, et al. Standards Track [Page 8] + +RFC 6503 CCMP March 2012 + + + Section 4.1 specifies the basic operations that can create, retrieve, + modify, and delete conference-related information in a centralized + conference. The core set of objects manipulated by CCMP includes + conference blueprints, the conference object, users, and sidebars. + + Each operation in the protocol model, as summarized in Section 4.1, + is atomic and either succeeds or fails as a whole. The conference + server MUST ensure that the operations are atomic in that the + operation invoked by a specific conferencing client completes prior + to another client's operation on the same conference object. While + the details for this data locking functionality are out of scope for + the CCMP specification and are implementation specific for a + conference server, some core functionality for ensuring the integrity + of the data is provided by CCMP as described in Section 4.2. + + While the XML documents that are carried in CCMP need to comply with + the XCON data model, there are situations in which the values for + mandatory elements are unknown by the client. The mechanism for + ensuring compliance with the data model in these cases is described + in Section 4.3. + + CCMP is completely independent from underlying protocols, which means + that there can be different ways to carry CCMP messages from a + conferencing client to a conference server. The specification + describes the use of HTTP as a transport solution, including CCMP + requests in HTTP POST messages and CCMP responses in HTTP 200 OK + replies. This implementation approach is further described in + Section 4.4. + +4.1. Protocol Operations + + The main operations provided by CCMP belong in four general + categories: + + create: for the creation of a conference object, a conference user, + a sidebar, or a blueprint. + + retrieve: to get information about the current state of either a + conference object (be it an actual conference, a blueprint, or a + sidebar) or a conference user. A retrieve operation can also be + used to obtain the XCON-URIs of the current conferences (active or + registered) handled by the conferencing server and/or the + available blueprints. + + update: to modify the current features of a specified conference or + conference user. + + + + + +Barnes, et al. Standards Track [Page 9] + +RFC 6503 CCMP March 2012 + + + delete: to remove from the system a conference object or a + conference user. + + Thus, the main targets of CCMP operations are as follows: + + o conference objects associated with either active or registered + conferences, + + o conference objects associated with blueprints, + + o conference objects associated with sidebars, both embedded in the + main conference (i.e., elements in ) + and external to it (i.e., whose XCON-URIs are included in the + elements of ), + + o elements associated with conference users, and + + o the list of XCON-URIs related to conferences and blueprints + available at the server, for which only retrieval operations are + allowed. + +4.2. Data Management + + The XCON framework defines a model whereby the conference server + centralizes and maintains the conference information. Since multiple + clients can modify the same conference objects, a conferencing client + might not have the latest version of a specific conference object + when it initiates operations. To determine whether the client has + the most up-to-date conference information, CCMP defines a versioning + approach. Each conference object is associated with a version + number. All CCMP response messages containing a conference document + (or a fragment thereof) MUST contain a parameter. When a + client sends an update message to the server, which includes + modifications to a conference object, if the modifications are all + successfully applied, the server MUST return a response, with a + of "200", containing the version number of the + modified object. With this approach, a client working on version "X" + of a conference object that receives a response, with a of "200", with a version number that is "X+1" can be certain + that the version it manipulated was the most up to date. However, if + the response contains a version that is at least "X+2", the client + knows that the object modified by the server was more up to date than + the object the client was manipulating. In order to ensure that the + client always has the latest version of the modified object, the + client can send a request to the conference server to retrieve the + conference object. The client can then update the relevant data + elements in the conference object prior to invoking a specific + operation. Note that a client subscribed to the XCON event package + + + +Barnes, et al. Standards Track [Page 10] + +RFC 6503 CCMP March 2012 + + + [RFC6502] notifications about conference object modifications, will + receive the most up-to-date version of that object upon receipt of a + notification. + + The "version" parameter is OPTIONAL for requests, since it is not + needed by the server: as long as the required modifications can be + applied to the target conference object without conflicts, the server + does not care whether the client has stored an up-to-date view of the + information. In addition, to ensure the integrity of the data, the + conference server first checks all the parameters, before making any + changes to the internal representation of the conference object. For + example, it would be undesirable to change the of the + conference, but then detect an invalid URI in one of the and abort the remaining updates. + +4.3. Data Model Compliance + + The XCON data model [RFC6501] identifies some elements and attributes + as mandatory. Since the XML documents carried in the body of the + CCMP requests and responses need to be compliant with the XCON data + model, there can be a problem in cases of client-initiated + operations, such as the initial creation of conference objects and + cases whereby a client updates a conference object adding new + elements, such as a new user. In such cases, not all of the + mandatory data can be known in advance by the client issuing a CCMP + request. As an example, a client cannot know, at the time it issues + a conference creation request, the XCON-URI that the server will + assign to the yet-to-be-created conference; hence, it is not able to + populate the mandatory 'entity' attribute of the conference document + contained in the request with the correct value. To solve this + issue, the CCMP client fills all mandatory data model fields, for + which no value is available at the time the request is constructed, + with placeholder values in the form of a wildcard string, + AUTO_GENERATE_X (all uppercase), with X being a unique numeric index + for each data model field for which the value is unknown. This form + of wildcard string is chosen, rather than the use of random unique + strings (e.g., FOO_BAR_LA) or non-numeric values for X, to simplify + processing at the server. The values of AUTO_GENERATE_X are only + unique within the context of the specific request. The placeholder + AUTO_GENERATE_X values MUST be within the value part of an attribute + or element (e.g., ). + + + + + + + + + +Barnes, et al. Standards Track [Page 11] + +RFC 6503 CCMP March 2012 + + + When the server receives requests containing values in the form of + AUTO_GENERATE_X, the server does the following: + + (a) Generates the proper identifier for each instance of + AUTO_GENERATE_X in the document. If an instance of + AUTO_GENERATE_X is not within the value part of the attribute/ + element, the server MUST send a of "400 Bad + Request". In cases where AUTO_GENERATE_X appears only in the + user part of a URI (i.e., in the case of XCON-USERIDs or XCON- + URIs), the server needs to ensure that the domain name is one + that is within the server's domain of responsibility. If the + domain name is not within the server's domain of responsibility, + then the server MUST send a of "427 Invalid + Domain Name". The server MUST replace each instance of a + specific wildcard field (e.g., AUTO_GENERATE_1) with the same + identifier. The identifiers MUST be unique for each instance of + AUTO_GENERATE_X within the same XML document received in the + request; for example, the value that replaces AUTO_GENERATE_1 + MUST NOT be the same as the value that replaces AUTO_GENERATE_2. + Note that the values that replace the instances of + AUTO_GENERATE_X are not the same across all conference objects; + for example, different values can be used to replace + AUTO_GENERATE_1 in two different documents. + + (b) Sends a response in which all values of AUTO_GENERATE_X received + in the request have been replaced by the newly created one(s). + + With this approach, compatibility with the data model requirements is + maintained, while allowing for client-initiated manipulation of + conference objects at the server's side. Note that the use of this + mechanism could be avoided in come cases by using multiple + operations, such as creating a new user and then adding the new user + to an existing conference. However, the AUTO_GENERATE_X mechanism + allows a single operation to be used to effect the same change on the + conference object. + +4.4. Implementation Approach + + CCMP is implemented using HTTP, placing the CCMP request messages + into the body of an HTTP POST operation and placing the CCMP + responses into the body of the HTTP response messages. A non- + exhaustive summary of the other approaches that were considered and + the perceived advantages of the HTTP solution described in this + document are provided in Appendix A. + + Most CCMP commands can pend indefinitely, thus increasing the + potential that pending requests can continue to increase when a + server is receiving more requests than it can process within a + + + +Barnes, et al. Standards Track [Page 12] + +RFC 6503 CCMP March 2012 + + + specific time period. In this case, a server SHOULD return a + of "510" to the pending requests. In addition, to + mitigate the situation, clients MUST NOT wait indefinitely for a + response and MUST implement a timer such that when it expires, the + client MUST close the connection. Thirty seconds is RECOMMENDED as + the default value for this timer. Sixty seconds is considered a + reasonable upper range. Note that there may be cases where a + response message is lost and a request has been successful (e.g., + user added to a conference); yet, the client will be unaware and + close the connection. However, as described in Section 4.2, there is + a versioning mechanism for the conference objects; thus, there is a + mechanism for the conference object stored by the client to be + brought up to date. + + CCMP messages have a MIME-type of "application/ccmp+xml", which + appears inside the Content-Type and Accept header fields of HTTP + requests and responses. The XML documents in the CCMP messages MUST + be encoded in UTF-8. This specification follows the recommendations + and conventions described in [RFC3023], including the naming + convention of the type ('+xml' suffix) and the usage of the 'charset' + parameter. The 'charset' parameter MUST be included with the XML + document. Section 9 provides the complete requirements for an HTTP + implementation to support CCMP. + +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. + + + + + + +Barnes, et al. Standards Track [Page 13] + +RFC 6503 CCMP March 2012 + + + 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 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 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 + element in [RFC6501]). A CCMP 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. + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 14] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + +Barnes, et al. Standards Track [Page 15] + +RFC 6503 CCMP March 2012 + + + 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 + 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 of + "400". The details for the specialized messages and associated + parameters are provided in Section 5.3. + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 16] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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 + + + +Barnes, et al. Standards Track [Page 17] + +RFC 6503 CCMP March 2012 + + + 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 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 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. + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 18] + +RFC 6503 CCMP March 2012 + + + +---------------+------------+------------+------------+------------+ + | 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(**) | + | | | | | | + | ------------- | ---------- | ---------- | ---------- | ---------- | + | userRequest | Get | Add a | Change | Delete | + | | specified | to | specified | specified | + | | | a conf | | | + | | | (***) | | | + | ------------- | ---------- | ---------- | ---------- | ---------- | + | sidebarsByVal | Get | N/A | N/A | N/A | + | Request | | | | | + | ------------- | ---------- | ---------- | ---------- | ---------- | + | sidebarsByRef | Get | N/A | N/A | N/A | + | Request | | | | | + | ------------- | ---------- | ---------- | ---------- | ---------- | + | 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 + + + + + + +Barnes, et al. Standards Track [Page 19] + +RFC 6503 CCMP March 2012 + + + (**): These operations are not allowed for a usersRequest message, + since the 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 parameter and/or if + the entity field of the 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 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 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 and 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. + + + + + +Barnes, et al. Standards Track [Page 20] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 21] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + 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 + parameter MUST be included in every confsRequest/Response message and + reflect the XCON-USERID of the conferencing client issuing the + request. The 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 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. + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 22] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 23] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + 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 + parameter, the request MUST include the and + the parameters. Again, the parameter MUST + be included in every blueprintRequest/Response message and reflect + the XCON-USERID of the conferencing client issuing the request. The + 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 + parameter with a value other than "retrieve". An + 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 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 of "404". This also holds for + the case in which the mentioned 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. + + + + + + + +Barnes, et al. Standards Track [Page 24] + +RFC 6503 CCMP March 2012 + + + For a of "200" in a "retrieve" operation, the + parameter MUST be included in the blueprintResponse + message. The parameter contains the conference + document associated with the blueprint as identified by the + parameter specified in the blueprintRequest. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 25] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + 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 + 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 parameter. ConfResponse messages MUST return + to the requestor a and MAY contain a explaining it. Depending upon the type of operation, a + and parameter MAY be included in the + confRequest and response. For each type of operation, the text below + describes whether the and 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 parameter MUST + contain the XCON-URI of the blueprint or of the conference to be + cloned, while the 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 parameter MUST NOT be included in the + request and the CCMP client can describe the desired conference + to be created using the parameter. If no + parameter is provided in the request, the new conference will be + created as a clone of the system default blueprint. + + + +Barnes, et al. Standards Track [Page 26] + +RFC 6503 CCMP March 2012 + + + In both creation cases, the confResponse, for a successful completion + of a "create" operation, contains a of "200" and MUST + contain the XCON-URI of the newly created conference in the + parameter, in order to allow the conferencing client to + manipulate that conference through following CCMP requests. In + addition, the parameter containing the conference document + created MAY be included, at the discretion of the conferencing system + implementation, along with the REQUIRED parameter + initialized at "1", since, at creation time, the conference object is + at its first version. + + In the case of a confRequest with an parameter of + "retrieve", the parameter representing the XCON-URI of + the target conference MUST be included and the parameter + MUST NOT be included in the request. The conference server MUST + ignore any parameter that is received in a confRequest + "retrieve" operation. If the confResponse for the retrieve operation + contains a of "200", the parameter MUST be + included in the response. The 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 parameter of "update", + the and parameters MUST be included in the + request. The 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 + parameter. Note that, in such a case, though the + 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 parameter will be of the form: + + + + *** NEW CONFERENCE TITLE *** + + + + 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 parameter would + do the job. + + + +Barnes, et al. Standards Track [Page 27] + +RFC 6503 CCMP March 2012 + + + + + + + + + Figure 8: Updating a Conference Object: + Removing the Title of a Conference + + In the case of a confResponse/update with a of "200", + no additional information is REQUIRED in the response message, which + means the return of a 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 of "200" indicates that the conference object has been changed + according to the request by the conference server. The + 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 of + "409" indicates that the changes reflected in the + 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 of "409", the + 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 parameter of + "delete", the parameter representing the XCON-URI of the + target conference MUST be included while the parameter + MUST NOT be included in the request. The conference server MUST + ignore any parameter that is received within such a + request. The confResponse MUST contain the same value for the + parameter that was included in the confRequest. If the + confResponse/delete operation contains a of "200", + the conference indicated in the parameter has been + successfully deleted. A confResponse/delete with a + of "200" MUST NOT contain the parameter. The + parameter SHOULD NOT be returned in any confResponse/delete. If the + conference server cannot delete the conference referenced by the + parameter received in the confRequest because it is the + parent of another conference object that is in use, the conference + server MUST return a of "425". + + + + + +Barnes, et al. Standards Track [Page 28] + +RFC 6503 CCMP March 2012 + + + A confRequest with an parameter of "retrieve", "update", + or "delete" carrying a 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 of "404". This also holds for the case + in which the mentioned 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 29] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + Figure 9: Structure of the confRequest and confResponse Messages + +5.3.5. usersRequest and usersResponse + + The usersRequest message allows a client to manipulate the + element of the conference object represented by the + parameter. The element contains the list of elements + associated with conference participants, the list of the users to + which access to the conference is allowed/denied, conference + participation policies, etc. The parameter MUST be + included in a usersRequest message. + + A parameter MAY be included in a usersRequest message + depending upon the operation. If the parameter is + included in the usersRequest message, the parameter MUST be compliant + with the 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 + parameter, while the successful response MUST contain + the desired element in the parameter. The + + + +Barnes, et al. Standards Track [Page 30] + +RFC 6503 CCMP March 2012 + + + conference server MUST ignore a parameter if it is + received in a request with an parameter of + "retrieve". + + 2. "update": In this case, the parameter MUST contain + the modifications to be applied to the element indicated. + If the is "200", then the parameter + SHOULD NOT be returned. Any parameter that is + returned SHOULD be ignored. A of "426" indicates + that the conferencing client is not allowed to make the changes + reflected in the 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 of "403" MUST be included in the + usersResponse message. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 31] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + Figure 10: Structure of the usersRequest and usersResponse Messages + +5.3.6. userRequest and userResponse + + A userRequest message is used to manipulate elements inside a + conference document associated with a conference identified by the + 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 and the + parameters, and it MAY include a parameter + containing the detailed user's information depending upon the + operation and whether the 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. + + + +Barnes, et al. Standards Track [Page 32] + +RFC 6503 CCMP March 2012 + + + Conference users can be created in a number of different ways. In + each of these cases, the parameter MUST be set to + "create" in the userRequest message. Each of the userResponse + messages for these cases MUST include the , , + , and parameters. In the case of a + of "200", the userResponse message MAY include the + 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 parameter MAY be included + in the userRequest. The parameter MUST contain a + 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 of "200". + + o A conferencing client acts on behalf of another user whose XCON- + USERID is known: In this case, the parameter MUST be + included in the userRequest. The parameter MUST + contain a 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 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 + parameter of the response. This is the only case in + which a CCMP request can be valid though carrying a void + parameter. A 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 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: + + + + + + + + +Barnes, et al. Standards Track [Page 33] + +RFC 6503 CCMP March 2012 + + + Request fields: + + confUserID=null; + confObjID=confXYZ; + operation=create; + userInfo= + + + + ... + + + 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, , + is the sender's and the 'entity' attribute of the attached + 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 parameter, if + the 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 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 parameter of + "retrieve", the parameter representing the XCON-URI of + the target conference MUST be included. The , containing + the CCMP client's XCON-USERID, MUST also be included in the + + + +Barnes, et al. Standards Track [Page 34] + +RFC 6503 CCMP March 2012 + + + userRequest message. If the client wants to retrieve information + about her profile in the specified conference, no + 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 + parameter whose 'entity' attribute conveys the desired user's XCON- + USERID. If the userResponse for the retrieve operation contains a + of "200", the parameter MUST be included + in the response. + + In case of a userRequest with an parameter of "update", + the , , and parameters MUST be + included in the request. The parameter is of type "user- + type" and contains all the changes to be applied to a specific + element in the conference object identified by the + parameter in the userRequest message. The user to be modified is + identified through the 'entity' attribute of the parameter + included in the request. In the case of a userResponse with a + of "200", no additional information is required in + the userResponse message. A of "200" indicates that + the referenced element has been updated by the conference + server. A of "426" indicates that the conferencing + client is not allowed to make the changes reflected in the + 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 parameter of + "delete", the representing the XCON-URI of the target + conference MUST be included. The 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 + 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 + parameter whose 'entity' attribute conveys the XCON-USERID + of that participant. The userResponse MUST contain the same value + for the parameter that was included in the + parameter in the userRequest. The userResponse MUST contain a + of "200" if the target element has been + successfully deleted. If the userResponse for the delete operation + contains a of "200", the userResponse MUST NOT + contain the parameter. + + + + + + + + +Barnes, et al. Standards Track [Page 35] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 36] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + 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 field of the conference object + represented by the . The sidebarsByValRequest message is + of a retrieve-only type, so an 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 of "200" MUST contain a + parameter containing the desired element. A + sidebarsByValResponse message MUST return to the client a + element related to the current version of the main conference object + (i.e., the one whose identifier is contained in the field + of the request) with which the sidebars in question are associated. + The 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. + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 37] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 38] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + Figure 13: Structure of the sidebarsByValRequest and + sidebarsByValResponse Messages + +5.3.8. sidebarByValRequest and sidebarByValResponse + + A sidebarByValRequest message MUST contain the 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 parameter MUST + be included in the sidebyValRequest message. In this case, the + 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 parameter in the sidebarbyValRequest/create message + introducing the new sidebar object as a new in the proper + section . The newly created sidebar conference + object MAY be included in the sidebarByValResponse in the + parameter, if the is "200". The + XCON-URI of the newly created sidebar MUST appear in the + 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. + + + + + +Barnes, et al. Standards Track [Page 39] + +RFC 6503 CCMP March 2012 + + + In the case of a sidebarByValRequest message with an + 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 + parameter in the request. This retrieve operation is handled by the + conference server in the same manner as in the case of an + parameter of "retrieve" included in a confRequest message, as + described in Section 5.3.4. + + In the case of a sidebarByValRequest message with an + parameter of "update", the MUST also be included + in the request. The 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 + parameter is handled by the conference server in + the same manner as an update operation on the conference instance as + reflected by the parameter included in a confRequest + message as detailed in Section 5.3.4. A sidebarByValResponse message + MUST return to the client a element related to the current + version of the sidebar whose identifier is contained in the + field of the request. + + If an parameter of "delete" is included in the + sidebarByVal request, the parameter MUST NOT be + included in the request. Any 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 + parameter in the request. If the specific conferencing + user, as reflected by the parameter, in the request is + authorized to delete the conference, the conference server deletes + the conference object reflected by the 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 parameter of "retrieve", + "update", or "delete" carries a parameter which is not + associated with any existing sidebar-by-val, a confResponse message + containing a of "404" will be generated on the + server's side. This also holds for the case in which the mentioned + 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. + + + + + +Barnes, et al. Standards Track [Page 40] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 41] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + 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 element of the conference + object identified by the parameter. The + sidebarsByRefRequest message is of a retrieve-only type, so an + parameter MUST NOT be included in a sidebarsByRefRequest + message. In the case of a of "200", the + parameter, containing the + element of the conference object, MUST be included in the response. + The 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 element related to + the current version of the main conference object (i.e., the one + whose identifier is contained in the field of the + request) with which the sidebars in question are associated. + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 42] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 43] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + Figure 15: Structure of the sidebarsByRefRequest + and sidebarsByRefResponse Messages + +5.3.10. sidebarByRefRequest and sidebarByRefResponse + + A sidebarByValResponse message MUST return to the client a + element related to the current version of the sidebar whose + identifier is contained in the field of the request. + + In the case of a create operation, the parameter MUST be + included in the sidebyRefRequest message. In this case, the + parameter contains the XCON-URI of the main conference in + which the sidebar has to be created. If no + 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 parameter provided by the + requestor. If the creation of the sidebar is successful, the + conference server MUST update the element in the + conference object from which the sidebar was created (i.e., as + identified by the 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 + parameter with a of "200". The + URI for the conference object associated with the newly created + sidebar object MUST appear in the 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. + + + + + +Barnes, et al. Standards Track [Page 44] + +RFC 6503 CCMP March 2012 + + + In the case of a sidebarByRefRequest message with an + parameter of "retrieve", the URI for the conference object created + for the sidebar MUST be included in the parameter in the + request. A retrieve operation on the 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 + parameter of "update", the URI for the conference object created for + the sidebar MUST be included in the parameter in the + request. The MUST also be included in the request + in the case of an "update" operation. An update operation on the + is handled by the conference server in the same + manner as an update operation on the included in a + confRequest message as detailed in Section 5.3.4. A + sidebarByRefResponse message MUST carry back to the client a + element related to the current version of the sidebar whose + identifier is contained in the field of the request. + + If an parameter of "delete" is included in the + sidebarByRefRequest, the parameter MUST NOT be + included in the request. Any 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 + parameter in the request. If the specific conferencing user as + reflected by the parameter in the request is authorized + to delete the conference, the conference server SHOULD delete the + conference object reflected by the parameter and SHOULD + update the 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 parameter of "retrieve", + "update", or "delete" carries a parameter that is not + associated with any existing sidebar-by-ref, a confResponse message + containing a of "404" will be generated on the + server's side. This also holds for the case in which the value of + the mentioned 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. + + + + + + + +Barnes, et al. Standards Track [Page 45] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 46] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + Figure 16: Structure of the sidebarByRefRequest + and sidebarByRefResponse Messages + +5.3.11. extendedRequest and extendedResponse + + In order to allow specifying new request and response pairs for + conference control, CCMP defines the extendedRequest and + extendedResponse messages. Such messages constitute a CCMP skeleton + in which implementers can transport the information needed to realize + conference control mechanisms not explicitly envisioned in the CCMP + specification; these mechanisms are called, in this context, + "extensions". Each extension is assumed to be characterized by an + appropriate name that MUST be carried in the extendedRequest/ + extendedResponse pair in the provided field. + Extension-specific information can be transported in the form of + schema-defined XML elements inside the element present in both + extendedRequest and extendedResponse. + + The conferencing client SHOULD be able to determine the extensions + supported by a CCMP server and to recover the XML schema defining the + related specific elements by means of an optionsRequest/ + optionsResponse CCMP transaction (see Section 5.3.12). + + The meaning of the common CCMP parameters inherited by the + extendedRequest and extendedResponse from the basic CCMP request and + response messages SHOULD be preserved and exploited appropriately + while defining an extension. + + + + + + + + + +Barnes, et al. Standards Track [Page 47] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 48] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + Figure 17: Structure of the extendedRequest and + extendedResponse Messages + +5.3.12. optionsRequest and optionsResponse + + The optionsRequest message (Figure 18) retrieves general information + about conference server capabilities. These capabilities include the + standard CCMP messages (request/response pairs) and potential + extension messages supported by the conference server. As such, it + is a basic CCMP message, rather than a specialization of the general + CCMP request. + + The optionsResponse returns, in the appropriate field, a + list of the supported CCMP message pairs as defined in this + specification. These messages are in the form of a list: including each of the supported messages as reflected + by elements. The optionsResponse message also + allows for an , which is a list of additional + message types in the form of elements that + are currently undefined, to allow for future extensibility. The + following information is provided for both types of messages: + + o (REQUIRED): in case of standard messages, it can be one of + the 10 standard message names defined in this document (i.e., + "blueprintsRequest", "confsRequest", etc.). In case of + extensions, this element MUST carry the same value of the + inserted in the corresponding extendedRequest/ + extendedResponse message pair. + + o (OPTIONAL): this field is a list of + entries, each representing the Create, Read, Update, Delete (CRUD) + operation supported by the server for the message. If this + element is absent, the client SHOULD assume the server is able to + + + +Barnes, et al. Standards Track [Page 49] + +RFC 6503 CCMP March 2012 + + + handle the entire set of CRUD operations or, in case of standard + messages, all the operations envisioned for that message in this + document. + + o (OPTIONAL): since all CCMP messages can potentially + contain XML elements not envisioned in the CCMP schema (due to the + presence of elements and attributes), a reference to a + proper schema definition specifying such new elements/attributes + can also be sent back to the clients by means of such field. If + this element is absent, no new elements are introduced in the + messages other than those explicitly defined in the CCMP + specification. + + o (OPTIONAL): human-readable information about the + related message. + + The only parameter needed in the optionsRequest is the sender + confUserID, which is mirrored in the same parameter of the + corresponding optionsResponse. + + The CCMP server MUST include the containing + at least one element in the optionsResponse, since a CCMP + server is REQUIRED to be able to handle both the request and response + messages for at least one of the operations. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 50] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 51] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 52] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + Figure 18: Structure of the optionsRequest and + optionsResponse Messages + +5.4. CCMP Response Codes + + All CCMP response messages MUST include a . This + document defines an IANA registry for the CCMP response codes, as + described in Section 12.5.2. The following summarizes the CCMP + response codes: + + 200 Success: + + Successful completion of the requested operation. + + 400 Bad Request: + + Syntactically malformed request. + + 401 Unauthorized: + + User not allowed to perform the required operation. + + 403 Forbidden: + + Operation not allowed (e.g., cancellation of a blueprint). + + 404 Object Not Found: + + The target conference object does not exist at the server (The + object in the error message refers to the parameter in + the generic request message). + + 409 Conflict: + + A generic error associated with all those situations in which a + requested client operation cannot be successfully completed by the + server. An example of such a situation is when the modification + of an object cannot be applied due to conflicts arising at the + + + +Barnes, et al. Standards Track [Page 53] + +RFC 6503 CCMP March 2012 + + + server's side, e.g., because the client version of the object is + an obsolete one and the requested modifications collide with the + up-to-date state of the object stored at the server. Such code + would also be used if a client attempts to create an object + (conference or user) with an entity that already exists. + + 420 User Not Found: + + Target user missing at the server (it is related to the XCON- + USERID in the 'entity' attribute of the parameter when + it is included in userRequests). + + 421 Invalid confUserID: + + User does not exist at the server (This code is returned for + requests where the parameter is invalid). + + 422 Invalid Conference Password: + + The password for the target conference object contained in the + request is wrong. + + 423 Conference Password Required: + + "conference-password" missing in a request to access a password- + protected conference object. + + 424 Authentication Required: + + User's authentication information is missing or invalid. + + 425 Forbidden Delete Parent: + + Cancel operation failed since the target object is a parent of + child objects that depend on it, or because it affects, based on + the "parent-enforceable" mechanism, the corresponding element in a + child object. + + 426 Forbidden Change Protected: + + Update refused by the server because the target element cannot be + modified due to its implicit dependence on the value of a parent + object ("parent-enforceable" mechanism). + + 427 Invalid Domain Name: + + The domain name in an AUTO_GENERATE_X instance in the conference + object is not within the CCMP server's domain of responsibility. + + + +Barnes, et al. Standards Track [Page 54] + +RFC 6503 CCMP March 2012 + + + 500 Server Internal Error: + + The server cannot complete the required service due to a system + internal error. + + 501 Not Implemented: + + Operation defined by the protocol, but not implemented by this + server. + + 510 Request Timeout: + + The time required to serve the request has exceeded the configured + service threshold. + + 511 Resources Not Available: + + This code is used when the CCMP server cannot execute a command + because of resource issues, e.g., it cannot create a sub- + conference because the system has reached its limits on the number + of sub-conferences, or if a request for adding a new user fails + because the max number of users has been reached for the + conference or the max number of users has been reached for the + conferencing system. + + The handling of a of "404", "409", "420", "421", + "425", "426", or "427" is only applicable to specific operations for + specialized message responses and the details are provided in + Section 5.3. The following table summarizes these response codes and + the specialized message and operation to which they are applicable: + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 55] + +RFC 6503 CCMP March 2012 + + + +----------+-------------+--------------+-------------+-------------+ + | Response | Create | Retrieve | Update | Delete | + | code | | | | | + +----------+-------------+--------------+-------------+-------------+ + | 404 | userRequest | All retrieve | All update | All delete | + | | sidebarBy | requests | requests | requests | + | | ValRequest, | EXCEPT: | | | + | | sidebarsBy | blueprints | | | + | | RefRequest | Request, | | | + | | | confsRequest | | | + | -------- | ----------- | ------------ | ----------- | ----------- | + | 409 | N/A | N/A | All update | N/A | + | | | | requests | | + | -------- | ----------- | ----------- | ----------- | ----------- | + | 420 | userRequest | userRequest | userRequest | userRequest | + | | (third- | | | | + | | party | | | | + | | invite with | | | | + | | third-user | | | | + | | entity) (*) | | | | + | -------- | ----------- | ----------- | ----------- | ----------- | + | 421 | All create | All retrieve | All update | All delete | + | | requests | requests | requests | requests | + | | EXCEPT: | | | | + | | userRequest | | | | + | | with no | | | | + | | confUserID | | | | + | | (**) | | | | + | -------- | ----------- | ----------- | ----------- | ----------- | + | 425 | N/A | N/A | N/A | All delete | + | | | | | request | + | -------- | ----------- | ----------- | ----------- | ----------- | + | 426 | N/A | N/A | All update | N/A | + | | | | requests | | + | -------- | ----------- | ----------- | ----------- | ----------- | + | 427 | ConfRequest | N/A | All update | N/A | + | | UserRequest | | requests | | + +----------+-------------+--------------+-------------+-------------+ + + Table 2: Response Codes and Associated Operations + + (*) "420" in answer to a "userRequest/create" operation: In the case + of a third-party invite, this code can be returned if the + (contained in the 'entity' attribute of the + parameter) of the user to be added is unknown. In the case above, if + instead it is the parameter of the sender of the request + that is invalid, a of "421" is returned to the + client. + + + +Barnes, et al. Standards Track [Page 56] + +RFC 6503 CCMP March 2012 + + + (**) "421" is not sent in answer to userRequest/create messages + having a "null" confUserID, since this case is associated with a user + who is unaware of his own XCON-USERID, but wants to enter a known + conference. + + In the case of a of "510", a conferencing client MAY + re-attempt the request within a period of time that would be specific + to a conferencing client or conference server. + + A of "400" indicates that the conferencing client + sent a malformed request, which is indicative of an error in the + conferencing client or in the conference server. The handling is + specific to the conferencing client implementation (e.g., generate a + log, display an error message, etc.). It is NOT RECOMMENDED that the + client re-attempt the request in this case. + + A of "401" or "403" indicates the client does not + have the appropriate permissions, or there is an error in the + permissions: re-attempting the request would likely not succeed and + thus it is NOT RECOMMENDED. + + Any unexpected or unknown SHOULD be treated by the + client in the same manner as a of "500", the handling + of which is specific to the conferencing client implementation. + +6. A Complete Example of CCMP in Action + + In this section a typical, non-normative, scenario in which CCMP + comes into play is described, by showing the actual composition of + the various CCMP messages. In the call flows of the example, the + conferencing client is a CCMP-enabled client, and the conference + server is a CCMP-enabled server. The XCON-USERID of the client, + Alice, is "xcon-userid:alice@example.com" and it appears in the + parameter in all requests. The sequence of operations + is as follows: + + 1. Alice retrieves the list of available blueprints from the server + (Section 6.1); + + 2. Alice asks for detailed information about a specific blueprint + (Section 6.2); + + 3. Alice decides to create a new conference by cloning the retrieved + blueprint (Section 6.3); + + 4. Alice modifies information (e.g., XCON-URI, name, and + description) associated with the newly created blueprint + (Section 6.4); + + + +Barnes, et al. Standards Track [Page 57] + +RFC 6503 CCMP March 2012 + + + 5. Alice specifies a list of users to be contacted when the + conference is activated (Section 6.5); + + 6. Alice joins the conference (Section 6.6); + + 7. Alice lets a new user, Ciccio, (whose XCON-USERID is + "xcon-userid:Ciccio@example.com") join the conference + (Section 6.7). + + 8. Alice asks for the CCMP server capabilities (Section 6.8); + + 9. Alice exploits an extension of the CCMP server (Section 6.9). + + Note that the examples do not include any details beyond the basic + operation. + + In the following sections, we deal with each of the aforementioned + actions separately. + +6.1. Alice Retrieves the Available Blueprints + + This section illustrates the transaction associated with retrieval of + the blueprints, together with a dump of the two messages exchanged + (blueprintsRequest and blueprintsResponse). As shown in the figure, + the blueprintsResponse message contains, in the + parameter, information about the available blueprints, in the form of + the standard XCON-URI of the blueprint, plus additional (and + optional) information, like its display-text and purpose. + + Alice retrieves from the server the list of available blueprints: + + CCMP Client CCMP Server + | | + | CCMP blueprintsRequest message | + | - confUserID: Alice | + | - confObjID: (null) | + |------------------------------------------------------>| + | | + | CCMP blueprintsResponse message | + | - confUserID: Alice | + | - confObjID: (null) | + | - response-code: 200 | + | - blueprintsInfo: bp123,bp124,.. | + |<------------------------------------------------------| + | | + . . + . . + + + + +Barnes, et al. Standards Track [Page 58] + +RFC 6503 CCMP March 2012 + + + 1. blueprintsRequest message: + + + + + xcon-userid:alice@example.com + + + + + 2. blueprintsResponse message from the server: + + + + + xcon-userid:alice@example.com + 200 + + + + xcon:AudioRoom@example.com + AudioRoom + Simple Room: + conference room with public access, + where only audio is available, more users + can talk at the same time + and the requests for the AudioFloor + are automatically accepted. + + + + xcon:VideoRoom@example.com + VideoRoom + Video Room: + conference room with public access, + where both audio and video are available, + 8 users can talk and be seen at the same time, + and the floor requests are automatically accepted. + + + + +Barnes, et al. Standards Track [Page 59] + +RFC 6503 CCMP March 2012 + + + + + xcon:AudioConference1@example.com + AudioConference1 + Public Audio Conference: + conference with public access, + where only audio is available, + only one user can talk at the same time, + and the requests for the AudioFloor MUST + be accepted by a Chair. + + + + xcon:VideoConference1@example.com + VideoConference1 + Public Video Conference: conference + where both audio and video are available, + only one user can talk. + + + + xcon:AudioConference2@example.com + AudioConference2 + Basic Audio Conference: + conference with private access, + where only audio is available, + only one user can talk at the same time, + and the requests for the AudioFloor MUST + be accepted by a Chair. + + + + + + + + Figure 19: Getting Blueprints from the Server + +6.2. Alice Gets Detailed Information about a Specific Blueprint + + This section illustrates the second transaction in the overall flow. + In this case, Alice, who now knows the XCON-URIs of the blueprints + available at the server, makes a drill-down query, in the form of a + CCMP blueprintRequest message, to get detailed information about one + of them (the one called with XCON-URI "xcon:AudioRoom@example.com"). + The picture shows such a transaction. Notice that the response + contains, in the parameter, a document compliant with + the standard XCON data model. + + + +Barnes, et al. Standards Track [Page 60] + +RFC 6503 CCMP March 2012 + + + Alice retrieves detailed information about a specified blueprint: + + CCMP Client CCMP Server + | | + | CCMP blueprintRequest message | + | - confUserID: Alice | + | - confObjID: bp123 | + | - operation: retrieve | + | - blueprintInfo: (null) | + |------------------------------------------------------>| + | | + | CCMP blueprintResponse message | + | - confUserID: Alice | + | - confObjID: bp123 | + | - operation: retrieve | + | - response-code: 200 | + | - blueprintInfo: bp123Info | + |<------------------------------------------------------| + | | + . . + . . + + 1. blueprintRequest message: + + + + + xcon-userid:alice@example.com + xcon:AudioRoom@example.com + retrieve + + + + + 2. blueprintResponse message from the server: + + + + + xcon-userid:alice@example.com + + + +Barnes, et al. Standards Track [Page 61] + +RFC 6503 CCMP March 2012 + + + xcon:AudioRoom@example.com + retrieve + 200 + Success + + + + AudioRoom + + + audio stream + audio + + + + + allow + + + confirm + + + audioLabel + + + + + + + + + Figure 20: Getting Information about a Specific Blueprint + +6.3. Alice Creates a New Conference through a Cloning Operation + + This section illustrates the third transaction in the overall flow. + Alice decides to create a new conference by cloning the blueprint + having XCON-URI "xcon:AudioRoom@example.com", for which she just + retrieved detailed information through the blueprintRequest message. + This is achieved by sending a confRequest/create message having the + blueprint's URI in the parameter. The picture shows such + a transaction. Notice that the response contains, in the + parameter, the document associated with the newly created conference, + which is compliant with the standard XCON data model. The + parameter in the response is set to the XCON-URI of the + new conference (in this case, "xcon:8977794@example.com"). We also + + + + + +Barnes, et al. Standards Track [Page 62] + +RFC 6503 CCMP March 2012 + + + notice that this value is equal to the value of the 'entity' + attribute of the element of the document + representing the newly created conference object. + + Alice creates a new conference by cloning the + "xcon:AudioRoom@example.com" blueprint: + +CCMP Client CCMP Server + | | + | CCMP confRequest message | + | - confUserID: Alice | + | - confObjID: AudioRoom | + | - operation: create | + | - confInfo: (null) | + |------------------------------------------------------>| + | | + | CCMP confResponse message | + | - confUserID: Alice | + | - confObjID: newConfId | + | - operation: create | + | - response-code: 200 | + | - version: 1 | + | - confInfo: newConfInfo | + |<------------------------------------------------------| + | | + . . + . . + +1. confRequest message: + + + + + xcon-userid:alice@example.com + xcon:AudioRoom@example.com + create + + + + + + + + + + +Barnes, et al. Standards Track [Page 63] + +RFC 6503 CCMP March 2012 + + +2. confResponse message from the server: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + create + 200 + Success + 1 + + + + + New conference by Alice cloned from AudioRoom + + + + audio stream + audio + + + + + allow + + + confirm + + + 333 + + + + + + + + + Figure 21: Creating a New Conference by Cloning a Blueprint + + + + + + +Barnes, et al. Standards Track [Page 64] + +RFC 6503 CCMP March 2012 + + +6.4. Alice Updates Conference Information + + This section illustrates the fourth transaction in the overall flow. + Alice decides to modify some of the details associated with the + conference she just created. More precisely, she changes the + element under the element of + the document representing the conference. This is achieved through a + confRequest/update message carrying the fragment of the conference + document to which the required changes have to be applied. As shown + in the picture, the response contains a code of "200", which + acknowledges the modifications requested by the client, while also + updating the conference version number from 1 to 2, as reflected in + the "version" parameter. + + Alice updates information about the conference she just created: + + CCMP Client CCMP Server + | | + | CCMP confRequest message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: update | + | - confInfo: confUpdates | + |------------------------------------------------------>| + | | + | CCMP confResponse message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: update | + | - response-code: 200 | + | - version: 2 | + | - confInfo: (null) | + |<------------------------------------------------------| + | | + . . + . . + + 1. confRequest message: + + + + + xcon-userid:alice@example.com + + + +Barnes, et al. Standards Track [Page 65] + +RFC 6503 CCMP March 2012 + + + xcon:8977794@example.com + update + + + + + Alice's conference + + + + + + + + 2. confResponse message from the server: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + update + 200 + Success + 2 + + + + + Figure 22: Updating Conference Information + +6.5. Alice Inserts a List of Users into the Conference Object + + This section illustrates the fifth transaction in the overall flow. + Alice modifies the under the element in + the document associated with the conference she created. To achieve + this, she makes use of the usersRequest message provided by CCMP. + + Alice updates information about the list of users to whom access to + the conference is permitted: + + + + + + + +Barnes, et al. Standards Track [Page 66] + +RFC 6503 CCMP March 2012 + + + CCMP Client CCMP Server + | | + | CCMP usersRequest message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: update | + | - usersInfo: usersUpdates | + |------------------------------------------------------>| + | | + | CCMP usersResponse message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: update | + | - response-code: 200 | + | - version: 3 | + | - usersInfo: (null) | + |<------------------------------------------------------| + | | + . . + . . + + 1. usersRequest message: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + update + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 67] + +RFC 6503 CCMP March 2012 + + + 2. usersResponse message from the server: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + retrieve + 200 + Success + 3 + + + + + Figure 23: Updating the List of Allowed Users for the + Conference 'xcon:8977794@example.com' + +6.6. Alice Joins the Conference + + This section illustrates the sixth transaction in the overall flow. + Alice uses CCMP to add herself to the newly created conference. This + is achieved through a userRequest/create message containing, in the + parameter, a element compliant with the XCON data + model representation. Notice that such an element includes + information about the user's Addresses of Record, as well as her + current endpoint. The picture below shows the transaction. Notice + how the parameter is equal to the 'entity' attribute of + the element, which indicates that the request issued by + the client is a first-party one. + + Alice joins the conference by issuing a userRequest/create message + with her own ID to the server: + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 68] + +RFC 6503 CCMP March 2012 + + + CCMP Client CCMP Server + | | + | CCMP userRequest message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: create | + | - userInfo: AliceUserInfo | + |------------------------------------------------------>| + | | + | CCMP userResponse message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: create | + | - response-code: 200 | + | - version: 4 | + | - userInfo: (null) | + |<------------------------------------------------------| + | | + . . + . . + + 1. userRequest message: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + create + + + + + + mailto:Alice83@example.com + + email + + + + + + + + + + +Barnes, et al. Standards Track [Page 69] + +RFC 6503 CCMP March 2012 + + + 2. userResponse message from the server: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + create + 200 + Success + 4 + + + + + Figure 24: Alice Joins the Conference through CCMP + +6.7. Alice Adds a New User to the Conference + + This section illustrates the seventh and last transaction in the + overall flow. Alice uses CCMP to add a new conferencing system user, + Ciccio, to the conference. This "third-party" request is realized + through a userRequest/create message containing, in the + parameter, a element compliant with the XCON data model + representation. Notice that such an element includes information + about Ciccio's Addresses of Record, as well as his current endpoint, + but has a placeholder 'entity' attribute, + "AUTO_GENERATE_1@example.com" as discussed in Section 4.3, since the + XCON-USERID is initially unknown to Alice. Thus, the conference + server is in charge of generating a new XCON-USERID for the user + Alice indicates (i.e., Ciccio), and returning it in the 'entity' + attribute of the parameter carried in the response, as + well as adding the user to the conference. The picture below shows + the transaction. + + Alice adds user "Ciccio" to the conference by issuing a third-party + userRequest/create message to the server: + + + + + + + + + + +Barnes, et al. Standards Track [Page 70] + +RFC 6503 CCMP March 2012 + + + CCMP Client CCMP Server + | | + | CCMP userRequest message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: create | + | - userInfo: dummyUserID, CiccioUserInfo | + |------------------------------------------------------>| + | | + | CCMP optionsResponse message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: create | + | - response-code: 200 | + | - version: 5 | + | - userInfo: userIDCiccio, | + | CiccioUserInfo | + | | + |<------------------------------------------------------| + | | + . . + . . + + +1. "third-party" userRequest message from Alice: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + create + + + + + + mailto:Ciccio@example.com + + email + + + + + + + +Barnes, et al. Standards Track [Page 71] + +RFC 6503 CCMP March 2012 + + + + + + +2. "third-party" userResponse message from the server: + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + create + 200 + 5 + + + + + + mailto:Ciccio@example.com + + email + + + + + + + + + Figure 25: Alice Adds a New User to the Conference through CCMP + +6.8. Alice Asks for the CCMP Server Capabilities + + This section illustrates how Alice can discover which standard CCMP + messages and what extensions are supported by the CCMP server with + which she interacts through an optionsRequest/optionsResponse + transaction. + + To prepare the optionsRequest, Alice just puts her XCON-USERID in the + parameter. Looking at the element in the + received optionsResponse, Alice infers the following server + capabilities as regards standard CCMP messages: + + + + +Barnes, et al. Standards Track [Page 72] + +RFC 6503 CCMP March 2012 + + + o the server doesn't support sidebarsByValRequest nor the + sidebarByValRequest messages, since they do not appear in the + ; + + o the only implemented operation for the blueprintRequest message is + "retrieve", since no other entries are included in the + related field. + + By analyzing the , Alice discovers the server + implements a bluePrint extension, referred to as "confSummaryRequest" + in this example. This extension allows Alice to recover via CCMP a + brief description of a specific conference; the XML elements involved + in this extended conference control transaction are available at the + URL indicated in the element, and the only operation + provided by this extension is "retrieve". To better understand how + Alice can exploit the "confSummaryRequest" extension via CCMP, see + Section 6.9. + + The figure below shows the optionsRequest/optionsResponse message + exchange between Alice and the CCMP server. + + CCMP Client CCMP Server + | | + | CCMP optionsRequest message | + | - confUserID: Alice | + |------------------------------------------------------>| + | | + | CCMP userResponse message | + | - confUserID: Alice | + | - response-code: 200 | + | - options (list of both | + | standard and extended | + | supported messages) | + |<------------------------------------------------------| + | | + . . + . . + + 1. optionsRequest (Alice asks for CCMP server capabilities) + + + + + xcon-userid:alice@example.com + + + +Barnes, et al. Standards Track [Page 73] + +RFC 6503 CCMP March 2012 + + + + + + 2. optionsResponse (the server returns the list of its conference + control capabilities) + + + + + xcon-userid:alice@example.com + 200 + success + + + + + blueprintsRequest + + + blueprintRequest + + retrieve + + + + confsRequest + + + confRequest + + + usersRequest + + + userRequest + + + sidebarsByRefRequest + + + sidebarByRefRequest + + + + + + +Barnes, et al. Standards Track [Page 74] + +RFC 6503 CCMP March 2012 + + + + confSummaryRequest + + retrieve + + + http://example.com/ccmp-extension-schema.xsd + + + confSummaryRequest is intended + to allow the requestor to retrieve + a brief description + of the conference indicated in the + confObjID request parameter + + + + + + + + + Figure 26: Alice Asks for the Server Control Capabilities + +6.9. Alice Makes Use of a CCMP Server Extension + + In this section, a very simple example of CCMP extension support is + provided. Alice can recover information about this and other server- + supported extensions by issuing an optionsRequest (see Section 6.8). + + The extension in question is named "confSummaryRequest" and allows a + CCMP client to obtain from the CCMP server synthetic information + about a specific conference. The conference summary is carried in + the form of an XML element as follows: + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 75] + +RFC 6503 CCMP March 2012 + + + + + + + + Figure 27: Example of XML Schema defining an extension + parameter (ccmp-extension-schema.xsd) + + As can be inferred from the schema file, the element + contains conference information related to the following: + + o title + + o status (active or registered) + + o participation modality (if everyone is allowed to participate, the + boolean element is set to "true") + + o involved media + + In order to retrieve a conference summary related to the conference + she participates in, Alice sends to the CCMP server an + extendedRequest with a "confSummaryRequest" , + specifying the conference XCON-URI in the confObjID request + parameter, as depicted in the figure below. + + CCMP Client CCMP Server + | | + | CCMP extendedRequest message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: retrieve | + | - extensionName: confSummaryRequest | + |------------------------------------------------------>| + | | + | CCMP extendedResponse message | + | - confUserID: Alice | + | - confObjID: 8977794 | + | - operation: retrieve | + | - response-code: 200 | + | - extensionName: | + | confSummaryRequest | + | - confSummary | + |<------------------------------------------------------| + | | + . . + . . + + + + +Barnes, et al. Standards Track [Page 76] + +RFC 6503 CCMP March 2012 + + +1. extendedRequest (Alice makes use of the "confSummaryRequest") + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + retrieve + + confRequestSummary + + + + +2. extendedResponse (the server provides Alice with a brief description + of the desired conference) + + + + + xcon-userid:alice@example.com + xcon:8977794@example.com + retrieve + 200 + success + + confSummaryRequest + + Alice's conference + active + true + audio + + + + + + Figure 28: Alice Exploits the 'confSummaryRequest' Extension + + + + + +Barnes, et al. Standards Track [Page 77] + +RFC 6503 CCMP March 2012 + + +7. Locating a Conference Server + + If a conferencing client is not pre-configured to use a specific + conference server for the requests, the client MUST first discover + the conference server before it can send any requests. The result of + the discovery process, is the address of the server supporting + conferencing. In this document, the result is an http: or https: + URI, which identifies a conference server. + + DNS is RECOMMENDED to be used to locate a conference server in the + case that the client is not pre-configured to use a specific + conference server. URI-Enabled NAPTR (U-NAPTR) resolution for + conferencing takes a domain name as input and produces a URI that + identifies the conference server. This process also requires an + Application Service tag and an Application Protocol tag, which + differentiate conferencing-related NAPTR records from other records + for that domain. + + Section 12.4.1 defines an Application Service tag of "XCON", which is + used to identify the centralized conferencing (XCON) server for a + particular domain. The Application Protocol tag "CCMP", defined in + Section 12.4.2, is used to identify an XCON server that understands + CCMP. + + The NAPTR records in the following example (Figure 29) demonstrate + the use of the Application Service and Application Protocol tags. + Iterative NAPTR resolution is used to delegate responsibility for the + conferencing service from "zonea.example.com." and + "zoneb.example.com." to "outsource.example.com.". + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 78] + +RFC 6503 CCMP March 2012 + + + zonea.example.com. + ;; order pref flags + IN NAPTR 100 10 "" "XCON-CCMP" ( ; service + "" ; regex + outsource.example.com. ; replacement + ) + zoneb.example.com. + ;; order pref flags + IN NAPTR 100 10 "" "XCON-CCMP" ( ; service + "" ; regex + outsource.example.com. ; replacement + ) + outsource.example.com. + ;; order pref flags + IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service + "!*.!https://confs.example.com/!" ; regex + . ; replacement + ) + + Figure 29: Sample XCON-CCMP Service NAPTR Records + + Details for the "XCON" Application Service tag and the "CCMP" + Application Protocol tag are included in Section 12.4. + +8. Managing Notifications + + As per [RFC5239], CCMP is one of the following four protocols, which + have been formally identified within the XCON framework: + + Conference Control Protocol: + + mediates between conference and media control client (conferencing + client) and conference server. This document describes such a + protocol. + + Binary floor Control Protocol: + + operates between the floor control client and the floor control + server. An example of such a protocol is the Binary Floor Control + Protocol (BFCP), specified in [RFC4582]. + + Call Signaling Protocol: + + operates between the Call Signaling Client and the focus. + Examples of call signaling protocols include SIP, H.323 and IAX. + Such protocols are capable of negotiating a conferencing session. + + + + + +Barnes, et al. Standards Track [Page 79] + +RFC 6503 CCMP March 2012 + + + Notification Protocol: + + operates between the Notification Client and the XCON Notification + Service. This specification does not define a new notification + protocol. For clients that use SIP as the call signaling + protocol, the XCON event package [RFC6502] MUST be used by the + client for notifications of changes in the conference data as + described below. + + The protocol specified in this document is a proactive one and is + used by a conferencing client to send requests to a conference server + in order to retrieve information about the conference objects stored + by the server and to possibly manipulate them. However, a complete + conferencing solution is not prohibited from providing clients with a + means for receiving asynchronous updates about the status of the + objects available at the server. The notification protocol, while + conceptually independent of all the mentioned companion protocols, + can nonetheless be chosen in a way that is consistent with the + overall protocol architecture characterizing a specific deployment, + as discussed in the following. + + When the conferencing control client uses SIP [RFC3261] as the + signaling protocol to participate in the conference, SIP event + notification can be used. In such a case, the conferencing control + client MUST implement the conference event package for XCON + [RFC6502]. This is the default mechanism for conferencing clients as + is SIP for signaling per the XCON framework [RFC5239]. + + In the case where the interface to the conference server is entirely + web based, there is a common mechanism for web-based systems that + could be used -- a "call back". With this mechanism, the + conferencing client provides the conference server with an HTTP URL + that is invoked when a change occurs. This is a common + implementation mechanism for e-commerce. This works well in the + scenarios whereby the conferencing client is a web server that + provides the graphical HTML user interface and uses CCMP as the back- + end interface to the conference server. This model can coexist with + the SIP event notification model. PC-based clients behind NATs could + provide a SIP event URI, whereas web-based clients using CCMP in the + back end would probably find the HTTP call back approach much easier. + The details of this approach are out of scope for CCMP; thus, we + expect a future specification will document this solution. + +9. HTTP Transport + + This section describes the use of HTTP [RFC2616] and HTTP over TLS + [RFC2818] as transport mechanisms for CCMP, which a conforming + conference server and conferencing client MUST support. + + + +Barnes, et al. Standards Track [Page 80] + +RFC 6503 CCMP March 2012 + + + Although CCMP uses HTTP as a transport, it uses a strict subset of + HTTP features, and due to the restrictions of some features, a + conferencing server might not be a fully compliant HTTP server. It + is intended that a conference server can easily be built using an + HTTP server with extensibility mechanisms, and that a conferencing + client can trivially use existing HTTP libraries. This subset of + requirements helps implementers avoid ambiguity with the many options + the full HTTP protocol offers. + + Support of HTTP authentication [RFC2617] and cookies [RFC6265] is + OPTIONAL for a conferencing client that conforms to this + specification. These mechanisms are unnecessary because CCMP + requests carry their own authentication information (in the "subject" + field; see Section 5.1). A conferencing client SHOULD include + support for HTTP proxy authentication. + + A CCMP request is carried in the body of an HTTP POST request. The + conferencing client MUST include a Host header in the request. + + The MIME type of CCMP request and response bodies is "application/ + ccmp+xml". The conference server and conferencing client MUST + provide this value in the HTTP Content-Type and Accept header fields. + If the conference server does not receive the appropriate Content- + Type and Accept header fields, the conference server SHOULD fail the + request, returning a 406 (Not Acceptable) response. CCMP responses + SHOULD include a Content-Length header. + + Conferencing clients MUST NOT use the Expect header or the Range + header in CCMP requests. The conference server MAY return 501 (Not + Implemented) errors if either of these HTTP features are used. In + the case that the conference server receives a request from the + conferencing client containing an If-* (conditional) header, the + conference server SHOULD return a 412 (precondition failed) response. + + The POST method is the only method REQUIRED for CCMP. If a + conference server chooses to support GET or HEAD, it SHOULD consider + the kind of application doing the GET. Since a conferencing client + only uses a POST method, the GET or HEAD MUST be either a URL that + was found outside its normal context (e.g., somebody found a URL in + protocol traces or log files and fed it into their browser) or + somebody is testing or debugging a system. The conference server + could provide information in the CCMP response indicating that the + URL corresponds to a conference server and only responds to CCMP POST + requests or the conference server could instead try to avoid any leak + of information by returning a very generic HTTP error message such as + 405 (Method Not Allowed). + + + + + +Barnes, et al. Standards Track [Page 81] + +RFC 6503 CCMP March 2012 + + + The conference server populates the HTTP headers of responses so that + they are consistent with the contents of the message. In particular, + the CacheControl header SHOULD be set to disable caching of any + conference information by HTTP intermediaries. Otherwise, there is + the risk of stale information and/or the unauthorized disclosure of + the information. The HTTP status code MUST indicate a 2xx series + response for all CCMP Response and Error messages. + + The conference server MAY redirect a CCMP request. A conference + server MUST NOT include CCMP responses in a 3xx response. A + conferencing client MUST handle redirects by using the Location + header provided by the server in a 3xx response. When redirecting, + the conferencing client MUST observe the delay indicated by the + Retry-After header. The conferencing client MUST authenticate the + server that returns the redirect response before following the + redirect. A conferencing client SHOULD authenticate the conference + server indicated in a redirect. + + The conference server SHOULD support persistent connections and + request pipelining. If pipelining is not supported, the conference + server MUST NOT allow persistent connections. The conference server + MUST support termination of a response by the closing of a + connection. + + Implementations of CCMP that implement HTTP transport MUST implement + transport over TLS [RFC2818]. TLS provides message integrity and + confidentiality between the conferencing client and the conference + server. The conferencing client MUST implement the server + authentication method described in HTTPS [RFC2818]. The device uses + the URI obtained during conference server discovery to authenticate + the server. The details of this authentication method are provided + in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the + conferencing client SHOULD fail a request if server authentication + fails. + +10. Security Considerations + + As identified in the XCON framework [RFC5239], there are a wide + variety of potential attacks related to conferencing, due to the + natural involvement of multiple endpoints and the capability to + manipulate the data on the conference server using CCMP. Examples of + attacks include the following: an endpoint attempting to listen to + conferences in which it is not authorized to participate, an endpoint + attempting to disconnect or mute other users, and an endpoint theft + of service in attempting to create conferences it is not allowed to + create. + + + + + +Barnes, et al. Standards Track [Page 82] + +RFC 6503 CCMP March 2012 + + + The following summarizes the security considerations for CCMP: + + 1. The client MUST determine the proper conference server. The + conference server discovery is described in Section 7. + + 2. The client MUST connect to the proper conference server. The + mechanisms for addressing this security consideration are + described in Section 10.1. + + 3. The protocol MUST support a confidentiality and integrity + mechanism. As described in Section 9, implementations of CCMP + MUST implement the HTTP transport over TLS [RFC2818]. + + 4. There are security issues associated with the authorization to + perform actions on the conferencing system to invoke specific + capabilities. A conference server SHOULD ensure that only + authorized entities can manipulate the conference data. The + mechanisms for addressing this security consideration are + described in Section 10.2. + + 5. The privacy and security of the identity of a user in the + conference MUST be assured. The mechanisms to ensure the + security and privacy of identity are discussed in Section 10.3. + + 6. A final issue is related to Denial-of-Service (DoS) attacks on + the conference server itself. The recommendations to minimize + the potential and impact of DoS attacks are discussed in + Section 10.4. + + Of the considerations listed above, items 1 and 3 are addressed + within the referenced sections earlier in this document. The + remaining security considerations are addressed in detail in the + following sections. + +10.1. Assuring That the Proper Conference Server Has Been Contacted + + Section 7 describes a mechanism using DNS by which a conferencing + client discovers a conference server. A primary concern is spoofed + DNS replies; thus, the use of DNS Security (DNSSEC) is RECOMMENDED to + ensure that the client receives a valid response from the DNS server + in cases where this is a concern. + + When the CCMP transaction is conducted using TLS [RFC5246], the + conference server can authenticate its identity, either as a domain + name or as an IP address, to the conferencing client by presenting a + certificate containing that identifier as a subjectAltName (i.e., as + an iPAddress or dNSName, respectively). Any implementation of CCMP + MUST be capable of being transacted over TLS so that the client can + + + +Barnes, et al. Standards Track [Page 83] + +RFC 6503 CCMP March 2012 + + + request the above authentication. Note that, in order for the + presented certificate to be valid at the client, the client MUST be + able to validate the certificate following the procedures in + [RFC2818] in the case of HTTP as a transport. In particular, the + validation path of the certificate must end in one of the client's + trust anchors, even if that trust anchor is the conference server + certificate itself. If the client has external information as to the + expected identity or credentials of the proper conference server, the + authentication checks described above MAY be omitted. + +10.2. User Authentication and Authorization + + Many policy authorization decisions are based on the identity of the + user or the role that a user may have. The conference server MUST + implement mechanisms for authentication of users to validate their + identity. There are several ways that a user might authenticate its + identity to the system. For users joining a conference using one of + the call signaling protocols, the user authentication mechanisms for + the specific protocol can be used. For example, in the case of a + user joining the conference using SIP signaling, the user + authentication as defined in [RFC3261] MUST be used. For the case of + users joining the conference using CCMP, the CCMP Request messages + provide a subject field that contains a username and password, which + can be used for authentication. Since the CCMP messages are + RECOMMENDED to be carried over TLS, this information can be sent + securely. + + The XCON framework [RFC5239] provides an overview of other + authorization mechanisms. In the cases where a user is authorized + via multiple mechanisms, it is RECOMMENDED that the conference server + associate the authorization of the CCMP interface with other + authorization mechanisms; for example, Public Switched Telephone + Network (PSTN) users that join with a PIN and control the conference + using CCMP. When a conference server presents the identity of + authorized users, it MAY provide information about the way the + identity was proven or verified by the system. A conference server + can also allow a completely unauthenticated user into the system -- + this information SHOULD also be communicated to interested parties. + + Once a user is authenticated and authorized through the various + mechanisms available on the conference server, the conference server + MUST allocate a conference user identifier (XCON-USERID) and SHOULD + associate the XCON-USERID with any signaling specific user + identifiers that were used for authentication and authorization. + This XCON-USERID can be provided to a specific user through the + conference notification interface and MUST be provided to users that + interact with the conferencing system using CCMP (i.e., in the + appropriate CCMP response messages). The XCON-USERIDs for each user/ + + + +Barnes, et al. Standards Track [Page 84] + +RFC 6503 CCMP March 2012 + + + participant in the conference are contained in the 'entity' attribute + in the element in the conference object. The XCON-USERID is + REQUIRED for any subsequent operations by the user on the conference + object and is carried in the confUserID parameter in the CCMP + requests and responses. + + Note that the policy management of an XCON-compliant conferencing + system is out of the scope of this document, as well as of the XCON + working group (WG). However, the specification of a policy + management framework is realizable with the overall XCON + architecture, in particular with regard to a Role-Based Access + Control (RBAC) approach. In RBAC, the following elements are + identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; + (v) Permissions. For all of the above elements, a direct mapping + exists onto the main XCON entities. As an example, RBAC objects map + onto XCON data model objects and RBAC operations map onto CCMP + operations. + + Future documents can define an RBAC framework for XCON, by first + focusing on the definition of roles and then specifying the needed + permission policy sets and role policy sets (used to associate policy + permission sets with specific roles). With these policies in place, + access to a conference object compliant with the XCON data model can + be appropriately controlled. As far as assigning users to roles, the + Users in the RBAC model relate directly to the element in the + conference object. The element is comprised of + elements representing a specific user in the conferencing system. + + Each element contains an 'entity' attribute with the XCON- + USERID and a element. Thus, each authorized user (as + represented by an XCON-USERID) can be associated with a + element. + +10.3. Security and Privacy of Identity + + An overview of the required privacy and anonymity for users of a + conferencing system are provided in the XCON framework [RFC5239]. + The security of the identity in the form of the XCON-USERID is + provided in CCMP through the use of TLS. + + The conference server SHOULD support the mechanism to ensure the + privacy of the XCON-USERID. The conferencing client indicates the + desired level of privacy by manipulation of the + element defined in the XCON data model [RFC6501]. The element controls the degree to which a user reveals their + identity. The following summarizes the values for the element that the client includes in their requests: + + + + +Barnes, et al. Standards Track [Page 85] + +RFC 6503 CCMP March 2012 + + + "hidden": Ensures that other participants are not aware that there + is an additional participant (i.e., the user issuing the request) + in the conference. This could be used in cases of users that are + authorized with a special role in a conference (e.g., a supervisor + in a call center environment). + + "anonymous": Ensures that other participants are aware that there + is another participant (i.e., the user issuing the request); + however, the other participants are not provided information as to + the identity of the user. + + "semi-private": Ensures that the user's identity is only to be + revealed to other participants or users that have a higher-level + authorization (e.g., a conferencing system can be configured such + that a human administrator can see all users). + + If the client desires privacy, the conferencing client SHOULD include + the element in the parameter in a CCMP + confRequest message with an parameter of "update" or + "create" or in the parameter in a CCMP userRequest message + with an parameter of "update" or "create". If the + element is not included in the conference object, + then other users can see the participant's identity. Participants + are made aware of other participants that are "anonymous" or "semi- + private" when they perform subsequent operations on the conference + object or retrieve the conference object or when they receive + subsequent notifications. + + Note that independent of the level of anonymity requested by the + user, the identity of the user is always known by the conferencing + system as that is required to perform the necessary authorization as + described in Section 10.2. The degree to which human administrators + can see the information can be controlled using policies (e.g., some + information in the data model can be hidden from human + administrators). + +10.4. Mitigating DoS Attacks + + [RFC4732] provides an overview of possible DoS attacks. In order to + minimize the potential for DoS attacks, it is RECOMMENDED that + conferencing systems require user authentication and authorization + for any client participating in a conference. This can be + accomplished through the use of the mechanisms described in + Section 10.2, as well as by using the security mechanisms associated + with the specific signaling (e.g., Session Initiation Protocol Secure + (SIPS)) and media protocols (e.g., Secure Realtime Transport Protocol + (SRTP)). In addition, Section 4.4 describes the use of a timer + mechanism to alleviate the situation whereby CCMP messages pend + + + +Barnes, et al. Standards Track [Page 86] + +RFC 6503 CCMP March 2012 + + + indefinitely, thus increasing the potential that pending requests + continue to increase when is a server is receiving more requests than + it can process. + +11. XML Schema + + This section gives the XML schema definition + [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the + "application/ccmp+xml" format. This is presented as a formal + definition of the "application/ccmp+xml" format. A new XML + namespace, a new XML schema, and the MIME type for this schema are + registered with IANA as described in Section 12. Note that this XML + Schema Definition is not intended to be used with on-the-fly + validation of the presence XML document. Whitespaces are included in + the schema to conform to the line length restrictions of the RFC + format without having a negative impact on the readability of the + document. Any conforming processor should remove leading and + trailing white spaces. + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 87] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 88] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 89] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 90] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 91] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 92] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 93] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 94] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 95] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 97] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 98] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 99] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 100] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 101] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 102] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 103] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 104] + +RFC 6503 CCMP March 2012 + + + + + + + + + + + + Figure 30: CCMP XML Schema + +12. IANA Considerations + + This document registers a new XML namespace, a new XML schema, and + the MIME type for the schema. This document also registers the + "XCON" Application Service tag and the "CCMP" Application Protocol + tag and defines registries for the CCMP operation types and response + codes. + +12.1. URN Sub-Namespace Registration + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:xcon-ccmp". + + URI: urn:ietf:params:xml:ns:xcon-ccmp + + Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary + Barnes (mary.ietf.barnes@gmail.com). + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 105] + +RFC 6503 CCMP March 2012 + + + XML: + + BEGIN + + + + + CCMP Messages + + +

Namespace for CCMP Messages

+

urn:ietf:params:xml:ns:xcon-ccmp

+

See + RFC 6503.

+ + + END + + +12.2. XML Schema Registration + + This section registers an XML schema per the guidelines in [RFC3688]. + + URI: urn:ietf:params:xml:schema:xcon-ccmp + + Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary + Barnes (mary.ietf.barnes@gmail.com). + + Schema: The XML for this schema can be found as the entirety of + Section 11 of this document. + +12.3. MIME Media Type Registration for 'application/ccmp+xml' + + This section registers the "application/ccmp+xml" MIME type. + + To: ietf-types@iana.org + + Subject: Registration of MIME media type application/ccmp+xml + + MIME media type name: application + + MIME subtype name: ccmp+xml + + Required parameters: (none) + + + + + + +Barnes, et al. Standards Track [Page 106] + +RFC 6503 CCMP March 2012 + + + Optional parameters: charset + Same as the charset parameter of "application/xml" as specified in + [RFC3023], Section 3.2. + + Encoding considerations: Same as the encoding considerations of + "application/xml" as specified in [RFC3023], Section 3.2. + + Security considerations: This content type is designed to carry + protocol data related to conference control. Some of the data + could be considered private. This media type does not provide any + protection and thus other mechanisms such as those described in + Section 10 are required to protect the data. This media type does + not contain executable content. + + Interoperability considerations: None. + + Published specification: RFC 6503. + + Applications that use this media type: Centralized Conferencing + control clients and servers. + + Additional Information: Magic Number(s): (none) + File extension(s): .ccmp + Macintosh File Type Code(s): TEXT + + Person & email address to contact for further information: Mary + Barnes + + Intended usage: LIMITED USE + + Author/Change controller: The IETF + + Other information: This media type is a specialization of + application/xml [RFC3023], and many of the considerations + described there also apply to application/ccmp+xml. + +12.4. DNS Registrations + + Section 12.4.1 defines an Application Service tag of "XCON", which is + used to identify the centralized conferencing (XCON) server for a + particular domain. The Application Protocol tag "CCMP", defined in + Section 12.4.2, is used to identify an XCON server that understands + CCMP. + + + + + + + + +Barnes, et al. Standards Track [Page 107] + +RFC 6503 CCMP March 2012 + + +12.4.1. Registration of a Conference Server Application Service Tag + + This section registers a new S-NAPTR/U-NAPTR Application Service tag + for XCON, as mandated by [RFC3958]. + + Application Service Tag: XCON + + Intended usage: Identifies a server that supports centralized + conferencing. + + Defining publication: RFC 6503 + + Contact information: The authors of this document + + Author/Change controller: The IESG + +12.4.2. Registration of a Conference Server Application Protocol Tag + for CCMP + + This section registers a new S-NAPTR/U-NAPTR Application Protocol tag + for CCMP, as mandated by [RFC3958]. + + Application Service Tag: CCMP + + Intended Usage: Identifies the Centralized Conferencing (XCON) + Manipulation Protocol. + + Applicable Service Tag(s): XCON + + Terminal NAPTR Record Type(s): U + + Defining Publication: RFC 6503 + + Contact Information: The authors of this document + + Author/Change Controller: The IESG + +12.5. CCMP Protocol Registry + + The IANA has created a new registry for CCMP: + http://www.iana.org/assignments/ccmp-parameters. The document + creates initial sub-registries for CCMP operation types and response + codes. + + + + + + + + +Barnes, et al. Standards Track [Page 108] + +RFC 6503 CCMP March 2012 + + +12.5.1. CCMP Message Types + + The following summarizes the registry for CCMP messages: + + Related Registry: CCMP Message Types Registry + + Defining RFC: RFC 6503. + + Registration/Assignment Procedures: Following the policies outlined + in [RFC5226], the IANA policy for assigning new values for the + CCMP message types for CCMP is Specification Required. + + Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary + Barnes (mary.ietf.barnes@gmail.com). + + This specification establishes the Message sub-registry under + http://www.iana.org/assignments/ccmp-messages. The initial Message + table is populated using the CCMP messages described in Section 4.1 + and defined in the XML schema in Section 11. + + Message Description Reference + ------- ----------- --------- + optionsRequest Used by a conferencing client [RFC6503] + to query a conference server for + its capabilities, in terms of + supported messages. + + optionsResponse Returns a list of CCMP messages [RFC6503] + supported by the specific + conference server. + + blueprintsRequest Used by a conferencing client [RFC6503] + to query a conference server for + its capabilities, in terms of + available conference blueprints. + + blueprintsResponse Returns a list of blueprints supported [RFC6503] + by the specific conference server. + + blueprintRequest Sent to retrieve the conference object [RFC6503] + associated with a specific blueprint. + + blueprintResponse Returns the conference object [RFC6503] + associated with a specific blueprint. + + confsRequest Used by a conferencing client [RFC6503] + to query a conference server for + its scheduled/active conferences. + + + +Barnes, et al. Standards Track [Page 109] + +RFC 6503 CCMP March 2012 + + + confsResponse Returns the list of the currently [RFC6503] + activated/scheduled conferences + at the server. + + confRequest Used to create a conference object [RFC6503] + and/or to request an operation on + the conference object as a whole. + + confResponse Indicates the result of the operation [RFC6503] + on the conference object as a whole. + + userRequest Used to request an operation on the [RFC6503] + element in the conference object. + + userResponse Indicates the result of the requested [RFC6503] + operation on the element in + the conference object. + + usersRequest Used to manipulate the element [RFC6503] + in the conference object, including + parameters such as the , + , etc. + + usersResponse Indicates the result of the request [RFC6503] + to manipulate the element in + the conference object. + + sidebarsByValRequest Used to retrieve the [RFC6503] + element of the target conference object. + + sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503] + conferences within the target + conference object. + + sidebarsByRefRequest Used to retrieve the [RFC6503] + element of the target conference + object. + + sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503] + conferences associated with the target + conference object. + + sidebarByValRequest Used to request an operation on a [RFC6503] + sidebar-by-val conference. + + sidebarByValResponse Indicates the result of the request to [RFC6503] + manipulate a sidebar-by-val conference. + + + + +Barnes, et al. Standards Track [Page 110] + +RFC 6503 CCMP March 2012 + + + sidebarByRefRequest Used to request an operation on a [RFC6503] + sideber-by-ref conference. + + sidebarByRefResponse Indicates the result of the request to [RFC6503] + manipulate a sidebar-by-ref conference. + +12.5.2. CCMP Response Codes + + The following summarizes the requested registry for CCMP response + codes: + + Related Registry: CCMP Response Code Registry + + Defining RFC: RFC 6503. + + Registration/Assignment Procedures: Following the policies outlined + in [RFC5226], the IANA policy for assigning new values for the + Response codes for CCMP shall be Specification Required. + + Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary + Barnes (mary.ietf.barnes@gmail.com). + + This specification establishes the Response-code sub-registry under + http://www.iana.org/assignments/ccmp-parameters. The initial + Response-code table is populated using the Response codes defined in + Section 5.4 as follows: + + Default + Response + Number String Description Reference + ------ ------------- ------------ --------- + 200 Success The request was successfully [RFC6503] + processed. + + 400 Bad Request The request was badly formed in [RFC6503] + some fashion. + + 401 Unauthorized The user was not authorized for [RFC6503] + the specific operation on the + conference object. + + 403 Forbidden The specific operation is not [RFC6503] + valid for the target conference + object. + + 404 Object Not Found The specific conference object [RFC6503] + was not found. + + + + +Barnes, et al. Standards Track [Page 111] + +RFC 6503 CCMP March 2012 + + + 409 Conflict A requested operation cannot be [RFC6503] + successfully completed by the + server. For example, the + modification of an object + cannot be applied because + the client version of the object + is obsolete and the requested + modifications collide with the + up-to-date state of the object + stored at the server. + + 420 User Not Found The user who is the target of the [RFC6503] + requested operation is unknown. + + 421 Invalid confUserID The parameter of the [RFC6503] + sender in the request is invalid. + + + 422 Invalid Conference A request to access/manipulate [RFC6503] + Password a password-protected conference + object contained an invalid + parameter. + + 423 Conference Password A request to access/manipulate [RFC6503] + Required a password-protected conference + object did not contain a + parameter. + + 424 Authentication The server wants to authenticate [RFC6503] + Required the request through the + parameter but the parameter is + not provided in the request. + + 425 Forbidden Delete The conferencing system cannot [RFC6503] + Parent delete the specific conference + object because it is a + parent for another conference object. + + 426 Forbidden Change The target conference object [RFC6503] + Protected cannot be changed (e.g., due to + policies, roles or privileges). + + 427 Invalid Domain Name The domain name in an [RFC6503] + AUTO_GENERATE_X + instance in the conference object + is not within the conference + server's domain of responsibility. + + + + +Barnes, et al. Standards Track [Page 112] + +RFC 6503 CCMP March 2012 + + + 500 Server Internal The conference server experienced [RFC6503] + Error some sort of internal error. + + 501 Not Implemented The specific operation is not [RFC6503] + implemented on the conferencing + system. + + 510 Request Timeout The request could not be [RFC6503] + processed within a reasonable + time (as specified by the + conferencing system). + + 511 Resources Not The conference server cannot [RFC6503] + Available execute a command because of + resource issues, e.g., it cannot + create a conference because + the system has reached its limits + on the number of conferences. + +13. Acknowledgments + + The authors appreciate the feedback provided by Dave Morgan, Pierre + Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean + Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage, + Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian + Carpenter (genart review), and Mykyta Yevstifeyev (IANA + considerations). Special thanks go to Roberta Presta for her + invaluable contribution to this document. Roberta has worked on the + specification of CCMP at the University of Napoli for the preparation + of her Master thesis. She has also implemented the CCMP prototype + used for the trials and from which the dumps provided in Section 6 + have been extracted. + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A., and L. Stewart, "HTTP + Authentication: Basic and Digest Access Authentication", + RFC 2617, June 1999. + + + +Barnes, et al. Standards Track [Page 113] + +RFC 6503 CCMP March 2012 + + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for + Centralized Conferencing", RFC 5239, June 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + + [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, + "Conference Information Data Model for Centralized + Conferencing (XCON)", RFC 6501, March 2012. + + [W3C.REC-xmlschema-1-20041028] + Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, + "XML Schema Part 1: Structures Second Edition", World Wide + Web Consortium Recommendation REC-xmlschema-1-20041028, + October 2004, + . + + [W3C.REC-xmlschema-2-20041028] + Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes + Second Edition", World Wide Web Consortium + Recommendation REC-xmlschema-2-20041028, October 2004, + . + +14.2. Informative References + + [REST] Fielding, "Architectural Styles and the Design of Network- + based Software Architectures", 2000. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, January 2005. + + + + +Barnes, et al. Standards Track [Page 114] + +RFC 6503 CCMP March 2012 + + + [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor + Control Protocol (BFCP)", RFC 4582, November 2006. + + [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- + Service Considerations", RFC 4732, December 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. + Urpalainen, "Conference Event Package Data Format + Extension for Centralized Conferencing (XCON)", RFC 6502, + March 2012. + + [W3C.REC-soap12-part1-20070427] + Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M., + Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2 + Part 1: Messaging Framework (Second Edition)", World Wide + Web Consortium Recommendation REC-soap12-part1-20070427, + April 2007, + . + + [W3C.REC-soap12-part2-20070427] + Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N., + Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2 + Part 2: Adjuncts (Second Edition)", World Wide Web + Consortium Recommendation REC-soap12-part2-20070427, + April 2007, + . + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 115] + +RFC 6503 CCMP March 2012 + + +Appendix A. Evaluation of Other Protocol Models and Transports + Considered for CCMP + + This section provides some background as to the selection of HTTP as + the transport for the CCMP requests/responses. In addition to HTTP, + the operations on the objects can be implemented in at least two + different ways, namely as remote procedure calls -- using SOAP as + described in Appendix A.1 and by defining resources following a + RESTful architecture Appendix A.2. + + In both the SOAP and RESTFUL approaches, servers will have to + recreate their internal state representation of the object with each + update request, checking parameters and triggering function + invocations. In the SOAP approach, it would be possible to describe + a separate operation for each atomic element, but that would greatly + increase the complexity of the protocol. A coarser-grained approach + to CCMP does require that the server process XML elements in updates + that have not changed and that there can be multiple changes in one + update. For CCMP, the resource (REST) model might appear more + attractive, since the conference operations fit the CRUD approach. + + However, neither of these approaches were considered ideal. SOAP was + considered to bring additional overhead. It is quite awkward to + apply a RESTful approach since CCMP requires a more complex request/ + response protocol in order to maintain the data both in the server + and at the client. This doesn't map very elegantly to the basic + request/response model, whereby a response typically indicates + whether the request was successful or not, rather than providing + additional data to maintain the synchronization between the client + and server data. In addition, the CCMP clients may also receive the + data in notifications. While the notification method or protocol + used by some conferencing clients can be independent of CCMP, the + same data in the server is used for both CCMP and notifications - + this requires a server application above the transport layer (e.g., + HTTP) for maintaining the data, which in the CCMP model is + transparent to the transport protocol. + + Thus, the solution for CCMP defined in this document is viewed as a + good compromise amongst the most notable past candidates and is + referred to as "HTTP single-verb transport plus CCMP body". With + this approach, CCMP is able to take advantage of existing HTTP + functionality. As with SOAP, CCMP uses a "single HTTP verb" for + transport (i.e., a single transaction type for each request/response + pair); this allows decoupling CCMP messages from HTTP messages. + Similarly, as with any RESTful approach, CCMP messages are inserted + directly in the body of HTTP messages, thus avoiding any unnecessary + processing and communication burden associated with further + intermediaries. With this approach, no modification to the CCMP + + + +Barnes, et al. Standards Track [Page 116] + +RFC 6503 CCMP March 2012 + + + messages/operations is required to use a different transport + protocol. + +A.1. Using SOAP for CCMP + + A remote procedure call (RPC) mechanism for CCMP could use SOAP + (Simple Object Access Protocol [W3C.REC-soap12-part1-20070427] + [W3C.REC-soap12-part2-20070427]), where conferences and the other + objects are modeled as services with associated operations. + Conferences and other objects are selected by their own local + identifiers, such as email-like names for users. This approach has + the advantage that it can easily define atomic operations that have + well-defined error conditions. + + All SOAP operations would use a single HTTP verb. While the RESTful + approach requires the use of a URI for each object, SOAP can use any + token. + +A.2. A RESTful Approach for CCMP + + Conference objects can also be modeled as resources identified by + URIs, with the basic CRUD operations mapped to the HTTP methods POST/ + PUT for creating objects, GET for reading objects, PATCH/POST/PUT for + changing objects, and DELETE for deleting them. Many of the objects, + such as conferences, already have natural URIs. + + CCMP can be mapped into the CRUD (Create, Read, Update, Delete) + design pattern. The basic CRUD operations are used to manipulate + conference objects, which are XML documents containing the + information characterizing a specified conference instance, be it an + active conference or a conference blueprint used by the conference + server to create new conference instances through a simple clone + operation. + + Following the CRUD approach, CCMP could use a general-purpose + protocol such as HTTP [RFC2616] to transfer domain-specific XML- + encoded data objects defined in the "Conference Information Data + Model for Centralized Conferencing" [RFC6501]. + + Following on the CRUD approach, CCMP could follow the well-known REST + (REpresentational State Transfer) architectural style [REST]. CCMP + could map onto the REST philosophy, by specifying resource URIs, + resource formats, methods supported at each URI and status codes that + have to be returned when a certain method is invoked on a specific + URI. A REST-style approach must ensure sure that all operations can + be mapped to HTTP operations. + + + + + +Barnes, et al. Standards Track [Page 117] + +RFC 6503 CCMP March 2012 + + + The following summarizes the specific HTTP method that could be used + for each of the CCMP Requests: + + Retrieve: HTTP GET could be used on XCON-URIs, so that clients can + obtain data about conference objects in the form of XML data model + documents. + + Create: HTTP PUT could be used to create a new object as identified + by the XCON-URI or XCON-USERID. + + Change: Either HTTP PATCH or HTTP POST could be used to change the + conference object identified by the XCON-URI. + + Delete: HTTP DELETE could be used to delete conference objects and + parameters within conference objects identified by the XCON-URI. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 118] + +RFC 6503 CCMP March 2012 + + +Authors' Addresses + + Mary Barnes + Polycom + TX + USA + + EMail: mary.ietf.barnes@gmail.com + + + Chris Boulton + NS-Technologies + + EMail: chris@ns-technologies.com + + + Simon Pietro Romano + University of Napoli + Via Claudio 21 + Napoli 80125 + Italy + + EMail: spromano@unina.it + + + Henning Schulzrinne + Columbia University + Department of Computer Science + 450 Computer Science Building + New York, NY 10027 + + EMail: hgs+xcon@cs.columbia.edu + + + + + + + + + + + + + + + + + + + +Barnes, et al. Standards Track [Page 119] + -- cgit v1.2.3