idnits 2.17.1 draft-ietf-xcon-ccmp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2011) is 4816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 4422, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-23 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4582 (Obsoleted by RFC 8855) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Polycom 4 Intended status: Standards Track C. Boulton 5 Expires: August 20, 2011 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 February 16, 2011 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-12 15 Abstract 17 The Centralized Conferencing Manipulation Protocol (CCMP) allows an 18 XCON conferencing system client to create, retrieve, change, and 19 delete objects that describe a centralized conference. CCMP is a 20 means to control basic and advanced conference features such as 21 conference state and capabilities, participants, relative roles, and 22 details. CCMP is a state-less, XML-based, client server protocol 23 that carries, in its request and response messages, conference 24 information in the form of XML documents and fragments conforming to 25 the centralized conferencing data model schema. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 20, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 3. XCON Conference Control System Architecture . . . . . . . . . 5 64 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7 65 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 68 4.2. Data Management . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. Data Model Compliance . . . . . . . . . . . . . . . . . . 11 70 4.4. Implementation Approach . . . . . . . . . . . . . . . . . 12 71 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13 73 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 15 74 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17 75 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20 76 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 22 77 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 23 78 5.3.4. confRequest and confResponse . . . . . . . . . . . . 25 79 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 80 5.3.6. userRequest and userResponse . . . . . . . . . . . . 31 81 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36 82 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38 83 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40 84 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42 85 5.3.11. extendedRequest and extendedResponse . . . . . . . . 45 86 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47 87 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50 88 6. A complete example of the CCMP in action . . . . . . . . . . 53 89 6.1. Alice retrieves the available blueprints . . . . . . . . 54 90 6.2. Alice gets detailed information about a specific 91 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57 92 6.3. Alice creates a new conference through a cloning 93 operation . . . . . . . . . . . . . . . . . . . . . . . . 59 94 6.4. Alice updates conference information . . . . . . . . . . 61 95 6.5. Alice inserts a list of users in the conference object . 63 96 6.6. Alice joins the conference . . . . . . . . . . . . . . . 65 97 6.7. Alice adds a new user to the conference . . . . . . . . . 67 98 6.8. Alice asks for the CCMP server capabilities . . . . . . . 69 99 6.9. Alice exploits a CCMP server extension . . . . . . . . . 72 100 7. Locating a Conference Control Server . . . . . . . . . . . . 74 101 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76 102 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 104 10.1. Assuring that the Proper Conferencing Server has been 105 contacted . . . . . . . . . . . . . . . . . . . . . . . . 80 106 10.2. User Authentication and Authorization . . . . . . . . . . 80 107 10.3. Security and Privacy of Identity . . . . . . . . . . . . 81 108 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 82 109 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100 110 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 100 111 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 101 112 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 101 113 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 102 114 12.4.1. Registration of a Conference Control Server 115 Application Service Tag . . . . . . . . . . . . . . . 103 116 12.4.2. Registration of a Conference Control Server 117 Application Protocol Tag for CCMP . . . . . . . . . . 103 118 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 103 119 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 103 120 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 105 121 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 123 14.1. Normative References . . . . . . . . . . . . . . . . . . 107 124 14.2. Informative References . . . . . . . . . . . . . . . . . 108 125 Appendix A. Appendix A: Other protocol models and transports 126 considered for CCMP . . . . . . . . . . . . . . . . 109 127 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 109 128 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 110 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 131 1. Introduction 133 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 134 defines a signaling-agnostic framework, naming conventions and 135 logical entities required for building advanced conferencing systems. 136 The XCON Framework introduces the conference object as a logical 137 representation of a conference instance, representing the current 138 state and capabilities of a conference. 140 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 141 this document allows authenticated and authorized users to create, 142 manipulate and delete conference objects. Operations on conferences 143 include adding and removing participants, changing their roles, as 144 well as adding and removing media streams and associated end points. 146 The CCMP implements the client-server model within the XCON 147 Framework, with the Conference Control Client and Conference Control 148 Server acting as client and server, respectively. The CCMP uses HTTP 149 [RFC2616] as the protocol to transfer requests and responses, which 150 contain the domain-specific XML-encoded data objects defined in 151 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 152 for Centralized Conferencing (XCON Data Model). 154 Section 2 clarifies the conventions and terminology used in the 155 document. Section 3 provides an overview of the Conference Control 156 functionality of the XCON framework, together with a description of 157 the main targets CCMP deals with, namely conference objects and 158 conference users. A general description of the operations associated 159 with protocol messages is given in Section 4 together with 160 implementation details. Section 5 delves into the details of the 161 specific CCMP messages. A complete, not normative, example of the 162 operation of the CCMP, describing a typical call flow associated with 163 conference creation and manipulation, is provided in Section 6. A 164 survey of the methods that can be used to locate a Conference Control 165 Server is provided in Section 7, whereas Section 8 discusses 166 potential approaches to notifications management. CCMP transport 167 over HTTP is highlighted in Section 9. Security considerations are 168 presented in Section 10. Finally, Section 11 provides the XML 169 schema. 171 2. Conventions and Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 In additon to the terms defined in the Framework for Centralized 178 Conferencing [RFC5239], this document uses the following terms and 179 acronyms: 181 XCON aware client: An XCON conferencing system client which is able 182 to issue CCMP requests. 184 First-Party: A request issued by the client to manipulate their own 185 conferencing data. 187 Third-Party: A request issued by a client to manipulate the 188 conference data of another client. 190 3. XCON Conference Control System Architecture 192 CCMP supports the XCON framework . Figure 1 depicts a subset of the 193 "Conferencing System Logical Decomposition" architecture from the 194 XCON framework document. It illustrates the role that CCMP assumes 195 within the overall centralized architecture. 197 ........................................................ 198 . Conferencing System . 199 . . 200 . +---------------------------------------+ . 201 . | C O N F E R E N C E O B J E C T | . 202 . +-+-------------------------------------+ | . 203 . | C O N F E R E N C E O B J E C T | | . 204 . +-+-------------------------------------+ | | . 205 . | C O N F E R E N C E O B J E C T | | | . 206 . | | |-+ . 207 . | |-+ . 208 . +---------------------------------------+ . 209 . ^ . 210 . | . 211 . v . 212 . +-------------------+ . 213 . | Conference Control| . 214 . | Server | . 215 . +-------------------+ . 216 . ^ . 217 .........................|.............................. 218 | 219 |Centralized 220 |Conferencing 221 |Manipulation 222 |Protocol 223 | 224 .........................|.............................. 225 . V . 226 . +----------------+ . 227 . | Conference | . 228 . | Control | . 229 . | Client | . 230 . +----------------+ . 231 . . 232 . Conferencing Client . 233 ........................................................ 235 Figure 1: Conference Client Interaction 237 CCMP serves as the Conference Control Protocol, allowing the 238 conference control client to interface with the conference object 239 maintained by the conferencing system, as represented in Figure 1. 240 Conference Control is one part of functionality for advanced 241 conferencing supported by a conferencing client. Other functions are 242 discussed in the XCON framework and related documents. 244 Conference object and conference users do represent key elements 245 involved in Conference Control Protocol operations. Their 246 identifiers, respectively the conference XCON-URI and the 247 conferencing client XCON-USERID, and their XML representations 248 compliant with the XML Schema defined in the XCON data model are 249 widely used for creating the CCMP requests and responses. The main 250 conference objects and users features envisioned by the XCON 251 framework are briefly described in the following subsections. 253 3.1. Conference Objects 255 Conference objects feature a simple dynamic inheritance-and-override 256 mechanism. Conference objects are linked into a tree known as 257 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 258 node inherits attributes from its parent node. The roots of these 259 inheritance trees are conference templates also known as 260 "blueprints". Nodes in the inheritance tree can be active 261 conferences or simply descriptions that do not currently have any 262 resources associated with them (i.e., conference reservations). An 263 object can mark certain of its properties as unalterable, so that 264 they cannot be overridden. Per the framework, a client may specify a 265 parent object (a conference or blueprint) from which to inherit 266 values when a conference is created using the Conference Control 267 Protocol. 269 Conference objects are uniquely identified by the XCON-URI within the 270 scope of the conferencing system. The XCON-URI is introduced in the 271 XCON framework and defined in the XCON common data model. 273 Conference objects are comprehensively represented through XML 274 documents compliant with the XML Schema defined in the XCON data 275 model [I-D.ietf-xcon-common-data-model]. The root element of such 276 documents, called "", is of type "conference-type". 277 It encompasses other XML elements describing different conference 278 features and users as well. Using the CCMP, conferencing clients can 279 use these XML structures to express their preferences in creating or 280 updating a conference. A conferencing server can convey conference 281 information using the XML elements back to the clients. 283 3.2. Conference Users 285 Each conference can have zero or more users. All conference 286 participants are users, but some users may have only administrative 287 functions and do not contribute or receive media. Users are added 288 one user at a time to simplify error reporting. When a conference is 289 cloned from a parent object, users are inherited as well, so that it 290 is easy to set up a conference that has the same set of participants 291 or a common administrator. The Conference Control Server creates 292 individual users, assigning them a unique Conference User Identifier 293 (XCON-USERID). The XCON-USERID as identifier of each conferencing 294 system client is introduced in the XCON framework and defined in the 295 XCON common data model. Each CCMP request, with an exception pointed 296 out in Section 5.3.6 representing the case of a user at his first 297 entrance in the system as a conference participant, must carry the 298 XCON-USERID of the requestor in the proper "confUserID" parameter. 300 The XCON-USERID acts as a pointer to the user's profile as a 301 conference actor, e.g. her signalling URI and other XCON protocol 302 URIs in general, her role (moderator, participant, observer, etc.), 303 her display text, her joining information and so on. A variety of 304 elements defined in the common element as specified 305 in the XCON data model are used to describe the users related to a 306 conference including the element, as well as each 307 element included within it. For example, it is possible to determine 308 how a specific user expects and is allowed to join a conference by 309 looking at the in : each element 310 involved in such a list represents a user and shows a "method" 311 attribute defining how the user is expected to join the conference, 312 i.e. "dial-in" for users that are allowed to dial, "dial-out" for 313 users that the conference focus will be trying to reach (with 314 "dial-in" being the default mode). If the conference is currently 315 active, dial-out users are contacted immediately; otherwise, they are 316 contacted at the start of the conference. The CCMP, acting as the 317 Conference Control Protocol, provides a means to manipulate these and 318 other kinds of user-related features. 320 As a consequence of an explicit user registration to a specific XCON 321 conferencing system, conferencing clients are usually provided 322 (besides the XCON-USERID) with log-in credentials (i.e. username and 323 password). Such credentials can be used to authenticate the XCON 324 aware client issuing CCMP requests. Thus, both username and password 325 should be carried in a CCMP request as part of the "subject" 326 parameter whenever a registered conferencing client wishes to contact 327 a CCMP server. The CCMP does not maintain user's subscriptions at 328 the conference server; hence, it does not provide any specific 329 mechanism allowing clients to register their conferencing accounts. 330 The "subject" parameter is just used for carrying authentication data 331 associated with pre-registered clients, with the specific 332 registration modality outside the scope of this document. 334 4. Protocol Overview 336 CCMP is a client-server, XML-based protocol, which has been 337 specifically conceived to provide users with the necessary means for 338 the creation, retrieval, modification and deletion of conference 339 objects. CCMP is also state-less, which means implementations can 340 safely handle transactions independently from each other. 341 Conference-related information is encapsulated into CCMP messages in 342 the form of XML documents or XML document fragments compliant with 343 the XCON data model representation. 345 Section 4.1 specifies the basic operations that can create, retrieve, 346 modify and delete conference-related information in a centralized 347 conference. The core set of objects manipulated in the CCMP includes 348 conference blueprints, the conference object, users, and sidebars. 350 Each operation in the protocol model, as summarized in Section 4.1 is 351 atomic and either succeeds or fails as a whole. The conference 352 server must ensure that the operations are atomic in that the 353 operation invoked by a specific conference client completes prior to 354 another client's operation on the same conference object. While the 355 details for this data locking functionality are out of scope for the 356 CCMP protocol specification and are implementation specific for a 357 conference server, some core functionality for ensuring the integrity 358 of the data is provided by the CCMP as described in Section 4.2. 360 While the XML documents that are carried in the CCMP need to comply 361 with the XCON data model, there are situations in which the values 362 for mandatory elements are unknown by the client. The mechanism for 363 ensuring compliance with the data model in these cases is described 364 in Section 4.3. 366 CCMP has been conceived as completely independent from underlying 367 protocols, which means that there can be different ways to carry CCMP 368 messages across the network, from a conferencing client to a 369 conferencing server. The specification recommends the use of HTTP as 370 a transport solution, including CCMP requests in HTTP POST messages 371 and CCMP responses in HTTP 200 OK replies. This implementation 372 approach is further described in Section 4.4. 374 4.1. Protocol Operations 376 The main operations provided by CCMP belong in four general 377 categories: 379 create: for the creation of a conference, a conference user, a 380 sidebar, or a blueprint. 382 retrieve: to get information about the current state of either a 383 conference object (be it an actual conference or a blueprint, or a 384 sidebar) or a conference user. A retrieve operation can also be 385 used to obtain the XCON-URIs of the current conferences (active or 386 registered) handled by the conferencing server and/or the 387 available blueprints. 389 update: to modify the current features of a specified conference or 390 conference user. 392 delete: to remove from the system a conference object or a 393 conference user. 395 Thus, the main targets of CCMP operations are: 397 o conference objects associated with either active or registered 398 conferences, 400 o conference objects associated with blueprints, 402 o conference objects associated with sidebars, both embedded in the 403 main conference (i.e. elements in ) and 404 external to it (i.e. whose xcon-uris are included in the 405 elements of ), 407 o elements associated with conference users, 409 o the list of XCON-URIs related to conferences and blueprints 410 available at the server, for which only retrieval operations are 411 allowed. 413 4.2. Data Management 415 In order to ensure the integrity of the data, the conference server 416 first checks all the parameters, before making any changes to the 417 internal representation of the conference object. For example, it 418 would be undesirable to change the of the conference, but 419 then detect an invalid URI in one of the and abort the 420 remaining updates. Also, since multiple clients can modify the same 421 conference objects, conference clients should first obtain the 422 current object from the conference server and then update the 423 relevant data elements in the conference object prior to invoking a 424 specific operation on the conference server. 426 In order to effectively manage modifications to conference data, a 427 versioning approach is provided by the CCMP. Specifically, each 428 conference object is associated with a version number indicating the 429 most up to date view of the conference at the server's side. The 430 version number is reported to the clients when answering their 431 requests. A client willing to make modifications to a conference 432 object has to send an update message to the server. If the 433 modifications are all successfully applied, the server sends back to 434 the client a "200" response which also carries information about the 435 current server-side version of the modified object. With this 436 approach, a client working on version "X" of a conference object that 437 finds a "200" response with a version number which is "X+1" can be 438 sure that the version it was aware of was the most up to date. On 439 the other hand, if the "200" response contains a version which is at 440 least "X+2", the client can detect that the object that has been 441 modified at the server's side was more up to date than the one it was 442 working upon. This is clearly due to the effect of concurrent 443 modification requests issued by independent clients. Hence, for the 444 sake of having available the latest version of the modified object, 445 the client can send to the conference server a further "retrieve" 446 request. In the case that a copy of the conference object is not 447 returned to the client as part of the update response message, the 448 client can always obtain a copy through an ad-hoc "retrieve" message. 450 Based on the above considerations, all CCMP response messages 451 containing a conference document (or a fragment of it) MUST contain a 452 "version" parameter. The "version" parameter is not REQUIRED for 453 requests, since it represents useless information for the server: as 454 long as the required modifications can be applied to the target 455 conference object with no conflicts, the server does not care whether 456 the client has stored an up to date view of the information. 457 However, a client subscribed to the XCON event package 458 [I-D.ietf-xcon-event-package] notifications about conference object 459 modifications, will always have the most up to date version of that 460 object. 462 4.3. Data Model Compliance 464 The XCON data model identifies some elements/attributes as mandatory. 465 Since the XML documents carried in the CCMP need to be compliant with 466 the XCON data model, there can be a problem in cases of client- 467 initiated operations, like the creation/update of conference objects. 468 In such cases, not all of the mandatory data can be known in advance 469 to the client issuing a CCMP request. As an example, a client has no 470 means to know, at the time it issues a conference creation request, 471 the XCON-URI that the server will assign to the yet-to-be-created 472 conference and hence it is not able to appropriately fill with that 473 value the mandatory "entity" attribute of the conference document 474 contained in the request. To solve this issue, the CCMP client fills 475 all mandatory data model fields, for which no value is available at 476 the time the request is constructed, with fake values in the form of 477 a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a 478 unique numeric index for each data model field for which the value is 479 unknown. This form of wildcard string is chosen, rather than the use 480 of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for 481 X, to simplify processing at the server. The values of 482 AUTO_GENERATE_X are only unique within the context of the specific 483 request. The fake AUTO_GENERATE_X values MUST be within the value 484 part of an attribute/element (e.g., ). 487 When the server receives requests containing values in the form of 488 AUTO_GENERATE_X, the server does the following: 490 (a) Generates the proper identifier for each instance of 491 AUTO_GENERATE_X in the document. If an instance of 492 AUTO_GENERATE_X is not within the value part of the attribute/ 493 element, the server MUST respond with an error of 400 Bad 494 Request. In cases where AUTO_GENERATE_X appears only in the 495 user part of a URI (i.e., in the case of XCON-USERIDs or XCON- 496 URIs), the server needs to ensure that the domain name is one 497 that is within the server's domain of responsibility. If the 498 domain name is NOT within the server's domain of responsibility, 499 then the server MUST return a 500 Server Internal Error. The 500 server MUST replace each instance of a specific wildcard field 501 (e.g., AUTO_GENERATE_1) with the same identifier. The 502 identifiers MUST be unique for each instance of AUTO_GENERATE_X 503 within the same XML document received in the request - e.g., the 504 value that replaces AUTO_GENERATE_1 MUST NOT be the same as the 505 value that replaces AUTO_GENERATE_2. Note that the values that 506 replace the instances of AUTO_GENERATE_X are not the same across 507 all conference objects - e.g., different values can be used to 508 replace AUTO_GENERATE_1 in two different documents. 510 (b) Sends a response in which all values of AUTO_GENERATE_X received 511 in the request has (have) been replaced by the newly created 512 one(s). 514 With this approach compatibility with the data model requirements is 515 maintained, while allowing for client-initiated manipulation of 516 conference objects at the server's side which is one of the main 517 goals of the CCMP protocol. 519 4.4. Implementation Approach 521 There have been a number of different proposals as to the most 522 suitable implementation solution for the CCMP. A non-exhaustive 523 summary of the most interesting ones is provided in Appendix A. The 524 solution for the CCMP defined in this document is viewed as a good 525 compromise amongst the most notable past candidates and is referred 526 to as "HTTP single-verb transport plus CCMP body". With this 527 approach, CCMP is able to take advantage of existing HTTP 528 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 529 transport (i.e. a single transaction type for each request/response 530 pair); this allows decoupling CCMP messages from HTTP messages. 532 Similarly, as with any RESTful approach, CCMP messages are inserted 533 directly in the body of HTTP messages, thus avoiding any unnecessary 534 processing and communication burden associated with further 535 intermediaries. With this approach, no modification to the CCMP 536 messages/operations is required to use a different transport 537 protocol. 539 The remainder of this document focuses on the selected approach. The 540 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 541 POST operations and retrieves responses from the body of HTTP "200 542 OK" messages. CCMP messages have a MIME-type of "application/ 543 ccmp+xml", which appears inside the "Content-Type" and "Accept" 544 fields of HTTP requests and responses. The XML documents in the CCMP 545 messages MUST be encoded in UTF-8. This specification follows the 546 recommendations and conventions described in [RFC3023], including the 547 naming convention of the type ('+xml' suffix) and the usage of the 548 'charset' parameter. The 'charset' parameter MUST be included with 549 the XML document. Section 9 provides the complete requirements for 550 an HTTP implementation to support the CCMP. 552 5. CCMP messages 554 CCMP messages are either requests or responses. The general CCMP 555 request message is defined in Section 5.1. The general CCMP response 556 message is defined in Section 5.2. The details of the specific 557 message type which is carried in the CCMP request and response 558 messages are described in Section 5.3. CCMP response codes are 559 listed in Section 5.4 561 5.1. CCMP Request Message Type 563 A CCMP request message is comprised of the following parameters: 565 subject: An optional parameter containing username and password of 566 the client registered at the conferencing system. Each user who 567 subscribes to the conferencing system is assumed to be equipped 568 with those credentials and SHOULD enclose them in each CCMP 569 request she issues. These fields can be used to control that the 570 user sending the CCMP request has the authority to perform the 571 entailed operation. The same fields can also be exploited to 572 carry out other Authorization, Authentication and Accounting (AAA) 573 procedures. 575 confUserID: An optional parameter containing the XCON-USERID of the 576 client. The XCON-USERID is used to identify any conferencing 577 client within the context of the conferencing system and it is 578 assigned by the conferencing server at each conferencing client 579 who interacts with it. The "confUserID" parameter is REQUIRED in 580 the CCMP request and response messages with the exception of the 581 case of a user who has no XCON-USERID and who wants to enter, via 582 CCMP, a conference whose identifier is known. In such case, a 583 side-effect of the request is that the user is provided with an 584 appropriate XCON-USERID. An example of the above mentioned case 585 will be provided in Section 5.3.6. 587 confObjID: An optional parameter containing the XCON-URI of the 588 target conference object. 590 operation: An optional parameter refining the type of specialized 591 request message. The "operation" parameter is REQUIRED in all 592 requests except for the "blueprintsRequest" and "confsRequest" 593 specialized messages. 595 conference-password: An optional parameter that MUST be inserted in 596 all requests whose target conference object is password-protected 597 (as per the element in 598 [I-D.ietf-xcon-common-data-model]). 600 specialized request message: This is specialization of the generic 601 request message (e.g., blueprintsRequest), containing parameters 602 that are dependent on the specific request sent to the server. A 603 specialized request message MUST be included in the CCMP request 604 message. The details for the specialized messages and associated 605 parameters are provided in Section 5.3. 607 609 611 613 614 615 617 618 620 622 624 625 627 629 631 633 635 637 638 639 641 Figure 2: Structure of CCMP Request messages 643 5.2. CCMP Response Message Type 645 A CCMP response message is comprised of the following parameters: 647 confUserID: A mandatory parameter in CCMP response messages 648 containing the XCON-USERID of the conferencing client who issued 649 the CCMP request message. 651 confObjID: An optional parameter containing the XCON-URI of the 652 target conference object. 654 operation: An optional parameter for CCMP response messages. This 655 parameter is REQUIRED in all responses except for the 656 "blueprintsResponse" and "confsResponse" specialized messages. 658 response-code: A mandatory parameter containing the response code 659 associated with the request. The response code MUST be chosen 660 from the codes listed in Section 5.4. 662 response-string: An optional reason string associated with the 663 response. In case of an error, in particular, such string can be 664 used to provide the client with detailed information about the 665 error itself. 667 version: An optional parameter reflecting the current version number 668 of the conference object referred by the confObjID. This number 669 is contained in the "version" attribute of the 670 element related to that conference. 672 specialized response message: This is specialization of the generic 673 response message, containing parameters that are dependent on the 674 specific request sent to the server (e.g., blueprintsResponse). A 675 specialized response message SHOULD be included in the CCMP 676 response message, except in an error situation where the CCMP 677 request message did not contain a valid specialized message. In 678 this case, the conference server MUST return a "response-code" of 679 "400". The details for the specialized messages and associated 680 parameters are provided in Section 5.3. 682 684 686 688 689 690 692 693 695 697 699 700 702 704 706 709 711 713 715 716 717 719 Figure 3: Structure of CCMP Response message 721 5.3. Detailed messages 723 Based on the request and response message structures described in 724 Section 5.1 and Section 5.2, the following summarizes the specialized 725 CCMP request/response types described in this document: 727 1. blueprintsRequest/blueprintsResponse 729 2. confsRequest/confsResponse 731 3. blueprintRequest/blueprintResponse 733 4. confRequest/confResponse 735 5. usersRequest/usersResponse 737 6. userRequest/userResponse 739 7. sidebarsByValRequest/sidebarsByValResponse 741 8. sidebarsByRefRequest/sidebarsByRefResponse 743 9. sidebarByValRequest/sidebarByValResponse 745 10. sidebarByRefRequest/sidebarByRefResponse 747 11. extendedRequest/extendedResponse 749 12. optionsRequest/optionsResponse 751 These CCMP request/response pairs use the fundamental CCMP operations 752 as defined in Section 4.1 to manipulate the conference data. The 753 optionsRequest/optionsResponse message pair deserves a specific 754 discussion, since it is not used for manipulating information about 755 either conferences or conference users, but rather to retrieve 756 general information about conference server capabilities, in terms of 757 standard CCMP messages it supports, plus potential extension messages 758 it understands, as it will be further explained in Section 5.3.12. 759 Table 1 summarizes the remaining CCMP operations and corresponding 760 actions that are valid for a specific CCMP request type, noting that 761 neither the blueprintsRequest/blueprintsResponse nor confsRequest/ 762 confsResponse require an "operation" parameter. The corresponding 763 response MUST contain the same operation. Note that some entries are 764 labeled "N/A" indicating the operation is invalid for that request 765 type. In the case of an "N/A*", the operation MAY be allowed for 766 specific privileged users or system administrators, but is not part 767 of the functionality included in this document. 769 +---------------+------------+------------+------------+------------+ 770 | Operation | Retrieve | Create | Update | Delete | 771 | ------------- | | | | | 772 | Request Type | | | | | 773 +---------------+------------+------------+------------+------------+ 774 | blueprints | Get list | N/A | N/A | N/A | 775 | Request | of | | | | 776 | | blueprints | | | | 777 | ------------- | ---------- | ---------- | ---------- | ---------- | 778 | blueprint | Get | N/A* | N/A* | N/A* | 779 | Request | blueprint | | | | 780 | ------------- | ---------- | ---------- | ---------- | ---------- | 781 | confsRequest | Get list | N/A | N/A | N/A | 782 | | of confs | | | | 783 | ------------- | ---------- | ---------- | ---------- | ---------- | 784 | confRequest | Gets | Creates | Changes | Deletes | 785 | | conference | conference | conference | conference | 786 | | object | object | object | object | 787 | ------------- | ---------- | ---------- | ---------- | ---------- | 788 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 789 | | | | | | 790 | ------------- | ---------- | ---------- | ---------- | ---------- | 791 | userRequest | Gets | Adds a | Changes | Deletes | 792 | | specified | to | specified | specified | 793 | | | a conf | | | 794 | | | (***) | | | 795 | ------------- | ---------- | ---------- | ---------- | ---------- | 796 | sidebarsByVal | Gets | N/A | N/A | N/A | 797 | Request | | | | | 799 | ------------- | ---------- | ---------- | ---------- | ---------- | 800 | sidebarsByRef | Gets | N/A | N/A | N/A | 801 | Request | | | | | 803 | ------------- | ---------- | ---------- | ---------- | ---------- | 804 | sidebarByVal | Gets | Creates | Changes | Deletes | 805 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 806 | | by-val | by-val | by-val | by-val | 807 | ------------- | ---------- | ---------- | ---------- | ---------- | 808 | sidebarByRef | Gets | Creates | Changes | Deletes | 809 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 810 | | by-ref | by-ref | by-ref | by-ref | 811 +---------------+------------+------------+------------+------------+ 813 Table 1: Request Type Operation Specific Processing 815 (**): These operations are not allowed for a usersRequest message, 816 since the section, which is the target element of such a 817 request, is created and removed in conjuntcion with, respectively, 818 the creation and deletion of the associated conference document. 819 Thus, "update" and "retrieve" are the only semantically correct 820 operations for such message. 822 (***): This operation can involve the creation of an XCON-USERID, if 823 the sender does not add it in the "confUserID" parameter, and/or if 824 the "entity" field of the "userInfo" parameter is void. 826 Additional parameters included in the specialized CCMP request/ 827 response messages are detailed in the subsequent sections. If a 828 required parameter is not included in a request, the conference 829 server MUST return a 400 response code per Section 5.4. 831 5.3.1. blueprintsRequest and blueprintsResponse 833 A "blueprintsRequest" (Figure 4) message is sent to request the list 834 of XCON-URIs associated with the available blueprints from the 835 conference server. Such URIs can be subsequently used by the client 836 to access detailed information about a specified blueprint with a 837 specific blueprintRequest message per Section 5.3.3. The 838 "confUserID" parameter MUST be included in every blueprintsRequest/ 839 Response message and reflect the XCON-USERID of the conferencing 840 client issuing the request. A blueprintsRequest message REQUIRES no 841 "confObjID" and "operation" parameters, since it is not targetted to 842 a specific conference instance and it is conceived as a "retrieve- 843 only" request. In order to obtain a specific subset of the available 844 blueprints, a client may specify a selection filter providing an 845 appropriate xpath query in the optional "xpathFilter" parameter of 846 the request. For example, to select blueprints having both audio and 847 video stream support, a possible xpathFilter value could be: "/ 848 conference-info[conference-description/available-media/entry/ 849 type='audio' and conference-description/available-media/entry/ 850 type='video']". 852 The associated "blueprintsResponse" message SHOULD contain, as shown 853 in Figure 4, a "blueprintsInfo" parameter containing the above 854 mentioned XCON-URI list. 856 858 859 860 861 862 864 865 866 867 869 871 873 874 875 876 878 879 880 882 884 885 886 887 888 889 890 891 892 894 896 898 899 900 902 904 905 906 908 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 909 messages 911 5.3.2. confsRequest and confsResponse 913 A "confsRequest" message is used to retrieve, from the server, the 914 list of XCON-URIs associated with active and registered conferences 915 currently handled by the conferencing system. The "confUserID" 916 parameter MUST be included in every confsRequest/Response message and 917 reflect the XCON-USERID of the conferencing client issuing the 918 request. The "confObjID" parameter MUST NOT be included in the 919 confsRequest message. The "confsRequest" message is of a "retrieve- 920 only" type, since the sole purpose is to collect information 921 available at the conference server. Thus, an "operation" parameter 922 MUST NOT be included in a "confsRequest" message. In order to 923 retrieve a specific subset of the available conferences, a client may 924 specify a selection filter providing an appropriate xpath query in 925 the optional "xpathFilter" parameter of the request. For example, to 926 select only the registered conferences, a possible xpathFilter value 927 could be: "/conference-info[conference-description/conference-state/ 928 active='false']". The associated "confsResponse" message SHOULD 929 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 930 upon receipt of the response message, can interact with the available 931 conference objects through further CCMP messages. 933 935 936 937 938 939 940 941 942 943 945 947 949 950 951 952 954 955 956 957 959 960 961 962 963 964 965 966 967 969 971 973 974 975 977 979 980 981 983 Figure 5: Structure of the confsRequest and confsResponse messages 985 5.3.3. blueprintRequest and blueprintResponse 987 Through a "blueprintRequest", a client can manipulate the conference 988 object associated with a specified blueprint. Further than the 989 "confUserID" parameter, the request MUST include the "confObjID" and 990 the "operation" one. Again, the "confUserID" parameter MUST be 991 included in every blueprintRequest/Response message and reflect the 992 XCON-USERID of the conferencing client issuing the request. The 993 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 994 which might have been previously retrieved through a 995 "blueprintsRequest" message. 997 The blueprintRequest message SHOULD NOT contain an "operation" 998 parameter other than "retrieve". The "create", "update" and "delete" 999 operations SHOULD NOT be included in a "blueprintRequest" message 1000 except in the case of privileged users (e.g. the conference server 1001 administration staff), who might authenticate themselves by the mean 1002 of the "subject" request parameter. 1004 A blueprintRequest/retrieve carrying a "confObjID" which is not 1005 associated with one of the available system's blueprints will 1006 generate, on the server's side, a blueprintResponse message 1007 containing a "404" error code. This holds also for the case in which 1008 the mentioned "confObjID" is related to an existing conference 1009 document stored at the server, but associated with an actual 1010 conference (be it active or registered) or with a sidebar rather than 1011 a blueprint. 1013 In the case of "response-code" of "200" for a "retrieve" operation, 1014 the "blueprintInfo" parameter MUST be included in the 1015 "blueprintResponse" message. The "blueprintInfo" parameter contains 1016 the conference document associated with the blueprint as identified 1017 by the "confObjID" parameter specified in the blueprintRequest. 1019 1021 1022 1023 1024 1025 1026 1027 1028 1029 1031 1033 1035 1036 1037 1039 1041 1042 1043 1045 1047 1048 1049 1050 1051 1052 1053 1054 1055 1057 1059 1061 1062 1063 1065 1067 1068 1069 1071 Figure 6: Structure of the blueprintRequest and blueprintResponse 1072 messages 1074 5.3.4. confRequest and confResponse 1076 With a "confRequest" message, CCMP clients can manipulate conference 1077 objects associated with either active or registered conferences. The 1078 "confUserID" parameter MUST be included in every confRequest/Response 1079 message and reflect the XCON-USERID of the conferencing client 1080 issuing the request. ConfRequest and confResponse messages MUST also 1081 include an "operation" parameter. ConfResponse messages MUST return 1082 to the requestor a "response-code" and MAY contain a "response- 1083 string" explaining it. Depending upon the type of "operation", a 1084 "confObjID" and "confInfo" parameter MAY be included in the 1085 confRequest and response. The requirements for inclusion of 1086 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1087 messages and are detailed below for each "operation" case. 1089 The creation case deserves care. To create a new conference through 1090 a "confRequest" message, two approaches can be considered: 1092 1. Creation through explicit cloning: the "confObjID" parameter MUST 1093 contain the XCON-URI of the blueprint or of the conference to be 1094 cloned, while the "confInfo" parameter MUST NOT be included in 1095 the confRequest. Note that cloning of an active conference is 1096 only done in the case of a sidebar operation per the XCON 1097 framework and as described in Section 5.3.8. 1099 2. Creation through implicit cloning (also known as "direct 1100 creation"): the "confObjID" parameter MUST NOT be included in the 1101 request and the CCMP client can describe the desired conference 1102 to be created using the "confInfo" parameter. If no "confInfo" 1103 parameter is provided in the request, the new conference will be 1104 created as a clone of the system default blueprint. 1106 In both creation cases, the confResponse, for a successful completion 1107 of a "create" operation, contains a response-code of "200" and MUST 1108 contain the XCON-URI of the newly created conference in the 1109 "confObjID" parameter, in order to allow the conferencing client to 1110 manipulate that conference through following CCMP requests. In 1111 addition, the "confInfo" parameter transporting the created 1112 conference document MAY be included, at the discretion of the 1113 conferencing system implementation, along with an optional version 1114 parameter initialized at "1", since at creation time the conference 1115 object is at its first version. 1117 In the case of a confRequest with a "retrieve" operation, the 1118 "confObjID" representing the XCON-URI of the target conference MUST 1119 be included and the "confInfo" parameter MUST NOT be included in the 1120 request. The conferencing server MUST ignore any "confInfo" 1121 parameter that is received in a confRequest/retrieve. If the 1122 confResponse for the "retrieve" operation contains a "response-code" 1123 of "200", the "confInfo" parameter MUST be included in the response. 1124 The "confInfo" parameter MUST contain the entire conference document 1125 describing the target conference object in its current state. The 1126 current state of the retrieved conference object MUST also be 1127 reported in the proper "version" response parameter. 1129 In case of a confRequest with an "update" operation, the "confInfo" 1130 and "confObjID" MUST be included in the request. The "confInfo" 1131 represents an object of type "conference-type" containing all the 1132 changes to be applied to the conference whose identifier is 1133 "confObjID". Note that, in such a case, though the confInfo 1134 parameter has indeed to follow the rules indicated in the XCON data 1135 model, it does not represent the entire updated version of the target 1136 conference, since it rather conveys just the modifications to apply 1137 to that conference. For example, in order to change the conference 1138 title, the confInfo parameter will be of the form: 1140 1141 1142 *** NEW CONFERENCE TITLE *** 1143 1144 1146 Figure 7: Updating a conference object: modifying the title of a 1147 conference 1149 Similarly, to remove the title of an existing conference, a 1150 confRequest/update carrying the following "confInfo" parameter would 1151 do the job.: 1153 1154 1155 1156 1157 1159 Figure 8: Updating a conference object: removing the title of a 1160 conference 1162 In the case of a confResponse/update with a response-code of "200", 1163 no additional information is required in the response message, which 1164 means the return of confInfo parameter is not mandatory. A following 1165 confRequest/retrieve transaction might provide the CCMP client with 1166 the current aspect of the conference upon the modification, or the 1167 Notification Protocol might address that task as well. A "200" 1168 response-code indicates that the referenced conference document has 1169 been changed accordingly to the request by the conferencing server. 1170 The "version" parameter MUST be enclosed in the confResponse/update 1171 message, in order to let the client understand what is the actual 1172 current conference-object version, upon the applied modifications. 1173 An "409" response-code indicates that the changes reflected in the 1174 request "confInfo" are not feasible. This could be due to policies, 1175 requestor roles, specific privileges, unacceptable values etc., with 1176 the reason specific to a conferencing system and its configuration. 1177 Together with the "409" response-code, the "version" parameter MUST 1178 be attached in the confResponse/update, by this way allowing the 1179 client to eventually retrieve the current version of the target 1180 conference if the one she attempted to modify was not the most up-to- 1181 date. 1183 In the case of a confRequest with a "delete" operation, the 1184 "confObjID" representing the XCON-URI of the target conference MUST 1185 be included while the "confInfo" MUST NOT be included in the request. 1186 The conferencing server MUST ignore any "confInfo" parameter that is 1187 received within such a request. The confResponse MUST contain the 1188 same "confObjID" that was included in the confRequest. If the 1189 confResponse/delete operation contains a "200" response-code, the 1190 conference indicated in the "confObjID" has been successfully 1191 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1192 parameter. The "version" parameter SHOULD NOT be returned in any 1193 confResponse/delete. If the conferencing server cannot delete the 1194 conference referenced by the "confObjID" received in the confRequest 1195 because it is the parent of another conference object that is in use, 1196 the conferencing server MUST return a response-code of "425". 1198 A confRequest with an "operation" of "retrieve", "update" or "delete" 1199 carrying a "confObjID" which is not associated with one of the 1200 conferences (active or registered) the system is holding will 1201 generate, on the server's side, a confResponse message containing a 1202 "404" error code. This holds also for the case in which the 1203 mentioned "confObjID" is related to an existing conference object 1204 stored at the server, but associated with a blueprint or with a 1205 sidebar rather than an actual conference. 1207 The schema for the confRequest/confResponse pair is shown in 1208 Figure 9. 1210 1212 1213 1214 1215 1216 1217 1218 1219 1220 1222 1224 1226 1227 1228 1230 1232 1233 1234 1236 1238 1239 1240 1241 1242 1243 1244 1245 1246 1248 1250 1252 1253 1254 1256 1258 1259 1260 1262 Figure 9: Structure of the confRequest and confResponse messages 1264 5.3.5. usersRequest and usersResponse 1266 Through a "usersRequest" message the CCMP client manipulates the XML 1267 element of the conference document associated with the 1268 conference identified by the "confObjID" parameter complusory 1269 included in the request. Inside the element, along with the 1270 list of elements associated with conference participants, 1271 there is information that the client may be interested in 1272 controlling, such the list of the users to which access to the 1273 conference is allowed/denied, conference participation policies, 1274 etc.; for this reason, a customized message has been designed to 1275 allow for the manipulation of this specific part of a conference 1276 document. 1278 A "usersInfo" parameter MAY be included in a usersRequest message 1279 depending upon the operation. If the "usersInfo" parameter is 1280 included in the usersRequest message, the parameter MUST be compliant 1281 with the field of the XCON data model. 1283 Two operations are allowed for a "usersRequest" message: 1285 1. "retrieve": In this case the request MUST NOT include a 1286 "usersInfo" parameter, while the successful response MUST contain 1287 the desired element in the "usersInfo" parameter. The 1288 conference server MUST ignore a "usersInfo" parameter if it is 1289 received in a request with a "retrieve" operation. 1291 2. update: In this case, the "usersInfo" parameter MUST contain the 1292 modifications to be applied to the referred element. If 1293 the "response-code" is "200", then the "usersInfo" parameter 1294 SHOULD NOT be returned. Any "usersInfo" parameter that is 1295 returned SHOULD be ignored. A "response-code" of "426" indicates 1296 that the conferencing client is not allowed to make the changes 1297 reflected in the "usersInfo" contained in the usersRequest 1298 message. This could be due to policies, roles, specific 1299 privileges, etc., with the reason specific to a conferencing 1300 system and its configuration. 1302 Operations of "create" and "delete" are not applicable to a 1303 usersRequest message and MUST NOT be considered by the server, which 1304 means that a "response-code" of "403" MUST be included in the 1305 usersResponse message. 1307 1309 1310 1311 1312 1313 1314 1315 1316 1317 1319 1321 1322 1323 1324 1326 1328 1329 1330 1332 1334 1335 1336 1337 1338 1339 1340 1341 1342 1344 1346 1348 1349 1350 1352 1354 1355 1356 1358 Figure 10: Structure of the usersRequest and usersResponse messages 1360 5.3.6. userRequest and userResponse 1362 A "userRequest" message is used to manipulate elements inside 1363 a conference document associated with a conference identified by the 1364 "confObjID" parameter. Besides retrieving information about a 1365 specific conference user, the message is used to request that the 1366 conference server either create, modify, or delete information about 1367 a user. A "userRequest" message MUST include the "confObjID", the 1368 "operation" parameter, and MAY include a "userInfo" parameter 1369 containing the detailed user's information depending upon the 1370 operation and whether the "userInfo" has already been populated for a 1371 specific user. Note that a user may not necessarily be a 1372 conferencing control client (i.e., some participants in a conference 1373 are not "XCON aware"). 1375 An XCON-USERID SHOULD be assigned to each and every user subscribed 1376 to the system. In such a way, a user who is not a conference 1377 participant can make requests (provided she has successfully passed 1378 AAA checks), like creating a conference, retrieving conference 1379 information, etc.. 1381 Conference users can be created in a number of different ways. In 1382 each of these cases the operation MUST be set to "create" in the 1383 userRequest message. Each of the userResponse messages for these 1384 cases MUST include the "confObjID", "confUserID", "operation" and 1385 "response-code" parameters. In the case of a response code of "200", 1386 the userResponse message MAY include the "userInfo" parameter 1387 depending upon the manner in which the user was created: 1389 o Conferencing client with an XCON-USERID adds itself to the 1390 conference: In this case, the "userInfo" parameter MAY be included 1391 in the userRequest. The "userInfo" parameter MUST contain a 1392 element (compliant with the XCON data model) and the 1393 "entity" attribute MUST be set to a value which represents the 1394 XCON-USERID of the user initiating the request. No additional 1395 parameters beyond those previously described are required in the 1396 userResponse message, in the case of a "response-code" of "200". 1398 o Conferencing client acts on behalf of a third user whose XCON- 1399 USERID is known: in this case, the "userInfo" parameter MUST be 1400 included in the userRequest. The "userInfo" parameter MUST 1401 contain a element and the "entity" attribute value MUST be 1402 set to the XCON-USERID of the third user in question. No 1403 additional parameters beyond those previously described are 1404 required in the userResponse message, in the case of a "response- 1405 code" of "200". 1407 o A conferencing client who has no XCON-USERID and who wants to 1408 enter, via CCMP, a conference whose identifier is known. In this 1409 case, a side-effect of the request is that the user is provided 1410 with a new XCON-USERID (created by the server) carried inside the 1411 "confUserID" parameter of the response. This is the only case in 1412 which a CCMP request can be valid though carrying a void 1413 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1414 in the request, providing at least a contact URI of the joining 1415 client, in order to let the focus instigate the signaling phase 1416 needed to add her to the conference. The mandatory "entity" 1417 attribute of the "userInfo" parameter in the request MUST be 1418 filled with a fake value with the user part of the XCON-USERID 1419 containing a value of AUTO_GENERATE_X as described in Section 4.3, 1420 to conform to the rules contained in the XCON data model XML 1421 schema. The messages (userRequest and userResponse) in this case 1422 should look like the following: 1424 Request fields: 1426 confUserID=null; 1427 confObjID=confXYZ; 1428 operation=create; 1429 userInfo= 1431 1432 1433 ... 1435 Response fields (in case of success): 1437 confUserID=user345; 1438 confObjID=confXYZ; 1439 operation=create; 1440 response-code=200; 1441 userInfo=null; //or the entire userInfo object 1443 Figure 11: userRequest and userResponse in the absence of an xcon- 1444 userid 1446 o Conferencing client is unaware of the XCON-USERID of a third user: 1447 In this case, the XCON-USERID in the request "confUserID" is the 1448 sender's one and the "entity" attribute of the attached userInfo 1449 is filled with the fake value 1450 "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for 1451 the third user MUST be returned to the client issuing the request 1452 in the "entity" attribute of the response "userInfo" parameter, if 1453 the "response-code" is "200". This scenario is intended to 1454 support both the case where a brand new conferencing system user 1455 is added to a conference by a third party (i.e. a user who is not 1456 yet provided with an XCON-USERID) and the case where the CCMP 1457 client issuing the request does not know the to-be-added user's 1458 XCON-USERID (which means such an identifier could already exist on 1459 the server's side for that user). In this last case, the 1460 conferencing server is in charge of avoiding XCON-URI duplicates 1461 for the same conferencing client, looking at key fields in the 1462 request provided "userInfo" parameter, such as the signalling URI: 1463 if the joining user is a brand new one, then the generation of a 1464 new XCON identifier is needed; otherwise, if that user is an 1465 existing one, the server must recover the corresponding XCON 1466 identifier. 1468 In the case of a userRequest with a "retrieve" operation, the 1469 "confObjID" representing the XCON-URI of the target conference MUST 1470 be included. The "confUserID", containing the CCMP client's xcon- 1471 userid, MUST also be included in the userRequest message. If the 1472 client wants to retrieve information about her profile in the 1473 specified conference, no "userInfo" parameter is needed in the 1474 retrieve request. On the other hand, if the client wants to obtain 1475 someone else's info within the given conference, she MUST include in 1476 the userRequest/retrieve a "userInfo" parameter whose "entity" 1477 attribute conveys the desired user's xcon-userid. If the 1478 userResponse for the "retrieve" operation contains a "response-code" 1479 of "200", the "userInfo" parameter MUST be included in the response. 1481 In case of a userRequest with an "update" operation, the "confObjID", 1482 "confUserID" and "userInfo" MUST be included in the request. The 1483 "userInfo" is of type "user-type" and contains all the changes to be 1484 applied to a specific element in the conference object 1485 identified by the "confObjID" in the userRequest message. The user 1486 to be modified is identified through the "entity" attribute of the 1487 "userInfo" parameter included in the request. In the case of a 1488 userResponse with a "response-code" of "200", no additional 1489 information is required in the "userResponse" message. A "response- 1490 code" of "200" indicates that the referenced user element has been 1491 updated by the conference server. A "response-code" of "426" 1492 indicates that the conferencing client is not allowed to make the 1493 changes reflected in the "userInfo" in the initial request. This 1494 could be due to policies, roles, specific privileges, etc., with the 1495 reason specific to a conferencing system and its configuration. 1497 In the case of a userRequest with a "delete" operation, the 1498 "confObjID" representing the XCON-URI of the target conference MUST 1499 be included. The "confUserID", containing the CCMP client's xcon- 1500 userid, MUST be included in the userRequest message. If the client 1501 wants to exit the specified conference, no "userInfo" parameter is 1502 needed in the delete request. On the other hand, if the client wants 1503 to remove another participant from the given conference, she MUST 1504 include in the userRequest/delete a "userInfo" parameter whose 1505 "entity" attribute conveys the xcon-userid of that participant. The 1506 userResponse MUST contain the same "confObjID" that was included in 1507 the userRequest. The userResponse MUST contain a "response-code" of 1508 "200" if the target element has been successfully deleted. If 1509 the userResponse for the "delete" operation contains a "response- 1510 code" of "200", the userResponse MUST NOT contain the "userInfo" 1511 parameter. 1513 1515 1516 1517 1518 1519 1520 1521 1522 1523 1525 1527 1529 1530 1531 1533 1535 1536 1537 1539 1541 1542 1543 1544 1545 1546 1547 1548 1549 1551 1552 1554 1555 1556 1558 1560 1561 1562 1564 Figure 12: Structure of the userRequest and userResponse messages 1566 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1568 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1569 on the field of the conference object represented 1570 by the "confObjID". The "sidebarsByValRequest" message is of a 1571 "retrieve-only" type, so an "operation" parameter MUST NOT be 1572 included in a "sidebarsByValRequest" message. As with blueprints and 1573 conferences, also with sidebars, CCMP allows for the use of xpath 1574 filters whenever a selected subset of the sidebars available at the 1575 server's side has to be retrieved by the client. This applies both 1576 to sidebars by reference and to sidebars by value. A 1577 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1578 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1580 the client a "version" element related to the current version of the 1581 main conference object (i.e. the one whose identifier is contained in 1582 the "confObjId" field of the request) to which the sidebars in 1583 question are associated. The "sidebarsByValInfo" parameter contains 1584 the list of the conference objects associated with the sidebars by 1585 value derived from the main conference. The retrieved sidebars can 1586 then be updated or deleted using the "sidebarByValRequest" message, 1587 which is described in Section 5.3.8. 1589 1591 1592 1593 1594 1595 1596 1597 1599 1600 1602 1604 1607 1608 1609 1610 1612 1613 1614 1616 1618 1619 1620 1621 1622 1623 1624 1625 1626 1628 1630 1633 1634 1635 1637 1639 1640 1641 1643 Figure 13: Structure of the sidebarsByValRequest and 1644 sidebarsByValResponse messages 1646 5.3.8. sidebarByValRequest and sidebarByValResponse 1648 A sidebarByValRequest message MUST contain the "operation" parameter 1649 which discriminates among retrieval, creation, modification and 1650 deletion of a specific sidebar. The other required parameters depend 1651 upon the type of operation. 1653 In the case of a "create" operation, the "confObjID" parameter MUST 1654 be included in the sidebyValRequest message. In this case, the 1655 "confObjID" parameter contains the XCON-URI of the main conference in 1656 which the sidebar has to be created. If no "sidebarByValInfo" 1657 parameter is included, as envisaged in the XCON framework 1658 ([RFC5239]), the sidebar is created by cloning the main conference, 1659 following the implementation specific cloning rules. Otherwise, 1660 similarly to the case of direct creation, the sidebar conference 1661 object is built on the basis of the "sidebarByValInfo" parameter 1662 provided by the requestor. As a consequence of a sidebar-by-val 1663 creation, the conference server MUST update the main conference 1664 object reflected by the "confObjID" parameter in the 1665 sidebarbyValRequest/create message introducing the new sidebar object 1666 as a new new in the proper section . The 1667 newly created sidebar conference object MAY be included in the 1668 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1669 "response-code" is "200". The XCON-URI of the newly created sidebar 1670 MUST appear in the "confObjID" parameter of the response. The 1671 conference server can notify any conferencing clients that have 1672 subscribed to the conference event package, and are authorized to 1673 receive the notifications, of the addition of the sidebar to the 1674 conference. 1676 In the case of a "sidebarByVal" request with an operation of 1677 "retrieve", the URI for the conference object created for the sidebar 1678 (received in the response to a "create" operation or in a 1679 sidebarsByValResponse message) MUST be included in the "confObjID" 1680 parameter in the request. This "retrieve" operation is handled by 1681 the conference server in the same manner as a "retrieve" operation 1682 included in a confRequest message as detailed in Section 5.3.4. 1684 In the case of a "sidebarByVal" request with an operation of 1685 "update", the "sidebarByValInfo" MUST also be included in the 1686 request. The "confObjID" parameter contained in the request message 1687 identifies the specific sidebar instance to be updated. An "update" 1688 operation on the "sidebarByValInfo" is handled by the conference 1689 server in the same manner as an "update" operation on the confInfo 1690 included in a confRequest message as detailed in Section 5.3.4. A 1691 "sidebarByValResponse" message MUST carry back to the client a 1692 "version" element related to the current version of the sidebar whose 1693 identifier is contained in the "confObjId" field of the request. 1695 If an "operation" of "delete" is included in the sidebarByVal 1696 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1697 request. Any "sidebarByValInfo" included in the request MUST be 1698 ignored by the conference server. The URI for the conference object 1699 associated with the sidebar MUST be included in the "confObjID" 1700 parameter in the request. If the specific conferencing user as 1701 reflected by the "confUserID" in the request is authorized to delete 1702 the conference, the conference server deletes the conference object 1703 reflected by the "confObjID" parameter and updates the data in the 1704 conference object from which the sidebar was cloned. The conference 1705 server can notify any conferencing clients that have subscribed to 1706 the conference event package, and are authorized to receive the 1707 notifications, of the deletion of the sidebar to the conference. 1709 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1710 or "delete" carries a "confObjID" which is not associated with any 1711 existing sidebar-by-val, a confResponse message containing a "404" 1712 error code will be generated on the server's side. This holds also 1713 for the case in which the mentioned "confObjID" is related to an 1714 existing conference object stored at the server, but associated with 1715 a blueprint or with an actual conference or with a sidebar-by-ref 1716 rather than a sidebar-by-val. 1718 1720 1721 1722 1723 1724 1725 1726 1727 1728 1730 1732 1735 1736 1737 1739 1741 1742 1743 1745 1747 1748 1749 1750 1751 1752 1753 1754 1755 1757 1759 1762 1763 1764 1766 1768 1769 1770 1772 Figure 14: Structure of the sidebarByValRequest and 1773 sidebarByValResponse messages 1775 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1777 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1778 invoked to retrieve the element of the conference 1779 object identified by the "confObjID" parameter. The 1780 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1781 "operation" parameter MUST NOT be included in a 1782 "sidebarsByRefRequest" message. In the case of a "response-code" of 1783 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1785 response. The element represents the set of URIs 1786 of the sidebars associated with the main conference, whose 1787 description (in the form of a standard XCON conference document) is 1788 external to the main conference itself. Through the retrieved URIs, 1789 it is then possible to access single sidebars using the 1790 "sidebarByRef" request message, described in Section 5.3.10. A 1791 "sidebarsByRefResponse" message MUST carry back to the client a 1792 "version" element related to the current version of the main 1793 conference object (i.e. the one whose identifier is contained in the 1794 "confObjId" field of the request) to which the sidebars in question 1795 are associated. 1797 1799 1800 1801 1802 1803 1804 1805 1806 1807 1809 1811 1814 1815 1816 1818 1820 1821 1822 1824 1826 1827 1828 1829 1830 1831 1832 1833 1834 1836 1838 1841 1842 1843 1845 1847 1848 1849 1851 Figure 15: Structure of the sidebarsByRefRequest and 1852 sidebarsByRefResponse messages 1854 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1856 A sidebarByRefRequest message MUST contain the "operation" parameter 1857 which discriminates among retrieval, creation, modification and 1858 deletion of a specific sidebar. The other required parameters depend 1859 upon the type of operation. 1861 In the case of a "create" operation, the "confObjID" parameter MUST 1862 be included in the sidebyRefRequest message. In this case, the 1863 "confObjID" parameter contains the XCON-URI of the main conference in 1864 which the sidebar has to be created. If no "sidebarByRefInfo" 1865 parameter is included, as envisaged in the XCON framework 1866 ([RFC5239]), the sidebar is created by cloning the main conference, 1867 following the implementation specific cloning rules. Otherwise, 1868 similarly to the case of direct creation, the sidebar conference 1869 object is built on the basis of the "sidebarByRefInfo" parameter 1870 provided by the requestor. If the creation of the sidebar is 1871 successful, the conference server MUST update the "sidebars-by-ref" 1872 element in the conference object from which the sidebar was created 1873 (i.e., as identified by the "confObjID" in the original sidebarByRef 1874 request), with the URI of the newly created sidebar. The newly 1875 created conference object MAY be included in the response in the 1876 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1877 URI for the conference object associated with the newly created 1878 sidebar object MUST appear in the "confObjID" parameter of the 1879 response. The conference server can notify any conferencing clients 1880 that have subscribed to the conference event package, and are 1881 authorized to receive the notifications, of the addition of the 1882 sidebar to the conference. 1884 In the case of a "sidebarByRef" request with an operation of 1885 "retrieve", the URI for the conference object created for the sidebar 1886 MUST be included in the "confObjID" parameter in the request. A 1887 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1888 conference server in the same manner as a "retrieve" operation on the 1889 confInfo included in a confRequest message as detailed in 1890 Section 5.3.4. 1892 In the case of a "sidebarByRef" request with an operation of 1893 "update", the URI for the conference object created for the sidebar 1894 MUST be included in the "confObjID" parameter in the request. The 1895 "sidebarByRefInfo" MUST also be included in the request in the case 1896 of an "operation" of "update". An "update" operation on the 1897 "sidebarByRefInfo" is handled by the conference server in the same 1898 manner as an "update" operation on the confInfo included in a 1899 confRequest message as detailed in Section 5.3.4. A 1900 "sidebarByRefResponse" message MUST carry back to the client a 1901 "version" element related to the current version of the sidebar whose 1902 identifier is contained in the "confObjId" field of the request. 1904 If an "operation" of "delete" is included in the sidebarByRef 1905 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1906 request. Any "sidebarByRefInfo" included in the request MUST be 1907 ignored by the conference server. The URI for the conference object 1908 for the sidebar MUST be included in the "confObjID" parameter in the 1909 request. If the specific conferencing user as reflected by the 1910 "confUserID" in the request is authorized to delete the conference, 1911 the conference server SHOULD delete the conference object reflected 1912 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1913 element in the conference object from which the sidebar was 1914 originally cloned. The conference server can notify any conferencing 1915 clients that have subscribed to the conference event package, and are 1916 authorized to receive the notifications, of the deletion of the 1917 sidebar. 1919 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1920 or "delete" carries a "confObjID" which is not associated with any 1921 existing sidebar-by-ref, a confResponse message containing a "404" 1922 error code will be generated on the server's side. This holds also 1923 for the case in which the mentioned "confObjID" is related to an 1924 existing conference object stored at the server, but associated with 1925 a blueprint or with an actual conference or with a sidebar-by-val 1926 rather than a sidebar-by-ref. 1928 1930 1931 1932 1933 1934 1935 1936 1937 1938 1940 1942 1945 1946 1947 1949 1951 1952 1953 1955 1957 1958 1959 1960 1961 1962 1963 1964 1965 1967 1969 1972 1973 1974 1976 1978 1979 1980 1982 Figure 16: Structure of the sidebarByRefRequest and 1983 sidebarByRefResponse messages 1985 5.3.11. extendedRequest and extendedResponse 1987 In order to facilitate the possibility of specifying new request/ 1988 response pairs for conference control, CCMP makes available the 1989 "extendedRequest" and "extendedResponse" messages. Such messages 1990 constitute a CCMP skeleton in which implementors can transport the 1991 information needed to realize conference control mechanisms not 1992 explicitly envisioned in the CCMP specification; these mechanisms are 1993 called, in this context, "extensions". Each extension is assumed to 1994 be characterized by an appropriate name that MUST be carried in the 1995 extendedRequest/extendedResponse pair in the provided 1996 field. Extension-specific information can be transported in the form 1997 of schema-defined XML elements inside the element present in 1998 both extendedRequest and extendedResponse. 2000 The conferencing client SHOULD be able to be informed about the 2001 extensions supported by a CCMP server and to recover the XML Schema 2002 defining the related specific elements by means of an optionsRequest/ 2003 optionsResponse CCMP transaction (see Section 5.3.12). 2005 The meaning of the common CCMP parameters inherited by the 2006 extendedRequest and extendedResponse from the basic CCMP request and 2007 response messages SHOULD be preserved and exploited appropriately 2008 while defining an extension. 2010 2012 2013 2014 2015 2016 2017 2018 2019 2020 2022 2024 2026 2027 2028 2030 2033 2034 2036 2038 2039 2040 2041 2042 2043 2044 2045 2046 2048 2050 2052 2053 2054 2057 2060 2061 2062 Figure 17: Structure of the extendedRequest and extendedResponse 2063 messages 2065 5.3.12. optionsRequest and optionsResponse 2067 An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. 2068 it does not represent a specialization of the general CCMP request. 2069 It allows a CCMP client to become aware of CCMP server capabilities 2070 in terms of CCMP supported messages. 2072 The "optionsResponse" returns, in the appropriate field, a 2073 list of the supported CCMP messages as defined in this specification. 2074 These messages are in the form of a list, 2075 including each of the supported messages as reflected by elements. The "optionsResponse" message also allows for an 2077 , which is a list of additional message types 2078 in the form of elements that are currently 2079 undefined, to allow for future extensibility. The following 2080 information is provided for both types of messages: 2082 o (mandatory): in case of standard messages, it can be one of 2083 the ten standard message names defined in this document (i.e. 2084 "blueprintsRequest", "confsRequest", etc.). In case of 2085 extensions, this element MUST carry the same value of the 2086 inserted in the corresponding extendedRequest/ 2087 extendedResponse message pair 2089 o (optional): this field is a list of 2090 entries, each representing the CRUD operation supported by the 2091 server for the message. If this optional element is absent, the 2092 client SHOULD assume the server is able to handle the entire set 2093 of CRUD operations or, in case of standard messages, all the 2094 operations envisioned for that message in this document. 2096 o (optional): since all CCMP messages can potentially 2097 contain XML elements not envisioned in the CCMP schema (due to the 2098 presence of elements and attributes), a reference to a 2099 proper schema definition specifying such new elements/attributes 2100 can also be sent back to the clients by means of such field. If 2101 this element is absent, no new elements are introduced in the 2102 messages further than those explicitly defined in the CCMP 2103 specification. 2105 o (optional): human readable information about the 2106 related message 2108 The only parameter needed in the optionsRequest is the sender 2109 confUserID, which is mirrored in the homologous parameter of the 2110 corresponding optionsResponse. 2112 The CCMP server MUST include the containing 2113 at least one element in the optionsResponse, since a CCMP 2114 server is required to be able to handle at least one of the standard 2115 messages for at least one of the operations. 2117 2119 2120 2121 2122 2123 2125 2127 2128 2129 2130 2131 2132 2133 2134 2135 2137 2139 2142 2143 2144 2146 2148 2149 2150 2152 2154 2155 2156 2159 2162 2164 2165 2166 2168 2170 2171 2172 2175 2177 2178 2179 2181 2183 2184 2185 2188 2191 2193 2195 2197 2198 2199 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2217 2219 2220 2221 2223 2224 2225 2227 Figure 18: Structure of the optionsRequest and optionsResponse 2228 messages 2230 5.4. CCMP Response Codes 2232 All CCMP response messages MUST include a ""response-code"". The 2233 following summarizes the CCMP response codes: 2235 200 Success: Successful completion of the requested operation. 2237 400 Bad Request: Syntactically malformed request. 2239 401 Unauthorized: User not allowed to perform the required 2240 operation. 2242 403 Forbidden: Operation not allowed (e.g., cancellation of a 2243 blueprint). 2245 404 Object Not Found: Target conference object missing at the server 2246 (it refers to the "confObjID" parameter in the generic request 2247 message) 2249 409 Conflict: A generic error associated with all those situations 2250 in which a requested client operation cannot be successfully 2251 completed by the server. An example of such situation is when the 2252 modification of an object cannot be applied due to conflicts 2253 arising at the server's side, e.g. because the client version of 2254 the object is an obsolete one and the requested modifications 2255 collide with the up-to-date state of the object stored at the 2256 server. Such code would also be used if a client attempts to 2257 create an object (conference or user) with an entity that already 2258 exists. 2260 420 User Not Found: Target user missing at the server (it is related 2261 to the XCON-USERID in the "entity" attribute of the "userInfo" 2262 parameter when it is included in userRequests) 2264 421 Invalid confUserID: User missing at the server (this code is 2265 returned in the case of requests in which the "confUserID" of the 2266 sender is invalid). 2268 422 Invalid Conference Password: Target conference object's password 2269 contained in the request is wrong. 2271 423 Conference Password Required: "conference-password" missing in a 2272 request to access a password-protected conference object. 2274 424 Authentication Required: User's authentication information is 2275 missing or invalid. 2277 425 Forbidden Delete Parent: Cancel operation failed since the 2278 target object is a parent of child objects which depend on it, or 2279 because it effects, based on the "parent-enforceable" mechanism, 2280 the corresponding element in a child object. 2282 426 Forbidden Change Protected: Update refused by the server because 2283 the target element cannot be modified due to its implicit 2284 dependence on the value of a parent object ("parent-enforceable" 2285 mechanism). 2287 500 Server Internal Error: The server cannot complete the required 2288 service due to a system internal error. 2290 501 Not Implemented: Operation envisaged in the protocol, but not 2291 implemented in the contacted server. 2293 510 Request Timeout: The time required to serve the request has 2294 exceeded the envisaged service threshold. 2296 511 Resources Not Available: This code is used when the CCMP server 2297 cannot execute a command because of resource issues, e.g. it 2298 cannot create a sub conference because the system has reached its 2299 limits on the number of sub conferences, or if a request for 2300 adding a new user fails because the max number of users has been 2301 reached for the conference or the max number of users has been 2302 reached for the conferencing system. 2304 The handling of a "response-code" of "404", "409", "420", "421", 2305 "425" and "426" are only applicable to specific operations for 2306 specialized message responses and the details are provided in 2307 Section 5.3. The following table summarizes these response codes and 2308 the specialized message and operation to which they are applicable: 2310 +---------------+------------+------------+------------+------------+ 2311 | Response code | Create | Retrieve | Update | Delete | 2312 +---------------+------------+------------+------------+------------+ 2313 | 404 | userReques | All | All update | All delete | 2314 | | t, | retrieve | requests | requests | 2315 | | sidebarBy | requests, | | | 2316 | | ValRequest | EXCEPT: | | | 2317 | | sidebars | blueprints | | | 2318 | | ByRefReque | Request, | | | 2319 | | st | confsRequ | | | 2320 | | | est | | | 2321 | ------------- | ---------- | ---------- | ---------- | ---------- | 2322 | 409 | N/A | N/A | All update | N/A | 2323 | | | | requests | | 2324 | ------------- | ---------- | ---------- | ---------- | ---------- | 2325 | 420 | userReques | userReques | userReques | userReques | 2326 | | t(3rd part | t | t | t | 2327 | | yinvite | | | | 2328 | | with thir | | | | 2329 | | duser | | | | 2330 | | entity) | | | | 2331 | | (*) | | | | 2332 | ------------- | ---------- | ---------- | ---------- | ---------- | 2333 | 421 | All create | All | All update | All delete | 2334 | | requests, | retrieve | requests | requests | 2335 | | EXCEPT: | requests | | | 2336 | | userReques | | | | 2337 | | twith no | | | | 2338 | | confUserI | | | | 2339 | | D(**) | | | | 2340 | ------------- | ---------- | ---------- | ---------- | ---------- | 2341 | 425 | N/A | N/A | N/A | All delete | 2342 | | | | | request | 2343 | ------------- | ---------- | ---------- | ---------- | ---------- | 2344 | 426 | N/A | N/A | All update | N/A | 2345 | | | | requests | | 2346 +---------------+------------+------------+------------+------------+ 2348 Table 2: Response codes and associated operations 2350 (*) "420" in answer to a "userRequest/create" operation: in the case 2351 of a third-party invite, this code can be returned if the 2352 "confUserID" (contained in the "entity" attribute of the "userInfo" 2353 parameter) of the user to be added is unknown. In the case above, if 2354 instead it is the "confUserID" of the sender of the request that is 2355 invalid, a "421" error code is returned to the client. 2357 (**) "421" is not sent in answers to "userRequest/create" messages 2358 having a "null" confUserID, since this case is associated with a user 2359 who is unaware of his own XCON-USERID, but wants to enter a known 2360 conference. 2362 In the case of a response code of "510", a conferencing client MAY 2363 re-attempt the request within a period of time that would be specific 2364 to a conference control client or conference control server. 2366 A response code of "400" indicates that the conference control client 2367 sent a malformed request, which is indicative of an error in the 2368 conference control client or in the conference control server. The 2369 handling is specific to the conference control client implementation 2370 (e.g., generate a log, display an error message, etc.). It is NOT 2371 RECOMMENDED that the client re-attempt the request in this case. 2373 Response codes such as "401" and "403" indicate the client does not 2374 have the appropriate permissions, or there is an error in the 2375 permissions: re-attempting the request would likely not succeed and 2376 thus it is NOT RECOMMENDED. 2378 Any unexpected or unknown "response-code" SHOULD be treated by the 2379 client in the same manner as a "500" "response-code", the handling of 2380 which is specific to the conference control client implementation. 2382 6. A complete example of the CCMP in action 2384 In this section a typical, not normative, scenario in which the CCMP 2385 comes into play is described, by showing the actual composition of 2386 the various CCMP messages. In the call flows of the example, the 2387 Conference Control Client is a CCMP-enabled client, whereas the 2388 Conference Control Server is a CCMP-enabled server. The "confUserID" 2389 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2390 in all requests. The sequence of operations is as follows: 2392 1. Alice retrieves from the server the list of available blueprints 2393 (Section 6.1); 2395 2. Alice asks for detailed information about a specific blueprint 2396 (Section 6.2); 2398 3. Alice decides to create a new conference by cloning the retrieved 2399 blueprint (Section 6.3); 2401 4. Alice modifies information (e.g. XCON-URI, name, description) 2402 associated with the newly created blueprint (Section 6.4); 2404 5. Alice specifies a list of users to be contacted when the 2405 conference is activated (Section 6.5); 2407 6. Alice joins the conference (Section 6.6); 2409 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2410 "xcon-userid:Ciccio@example.com") join the conference 2411 (Section 6.7). 2413 8. Alice asks for the CCMP server capabilities (Section 6.8); 2415 9. Alice exploits an extension of the CCMP server (Section 6.9). 2417 Note, the examples do not include any details beyond the basic 2418 operation. 2420 In the following sections we deal with each of the above mentioned 2421 actions separately. 2423 6.1. Alice retrieves the available blueprints 2425 This section illustrates the transaction associated with retrieval of 2426 the blueprints, together with a dump of the two messages exchanged 2427 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2428 the figure, the "blueprintsResponse" message contains, in the 2429 "blueprintsInfo" parameter, information about the available 2430 blueprints, in the form of the standard XCON-URI of the blueprint, 2431 plus additional (and optional) information, like its display-text and 2432 purpose. 2434 Alice retrieves from the server the list of available blueprints: 2436 CCMP Client CCMP Server 2437 | | 2438 | CCMP blueprintsRequest message | 2439 | - confUserID: Alice | 2440 | - confObjID: (null) | 2441 |------------------------------------------------------>| 2442 | | 2443 | CMP blueprintsResponse message | 2444 | - confUserID: Alice | 2445 | - confObjID: (null) | 2446 | - response-code: 200 | 2447 | - blueprintsInfo: bp123,bp124,.. | 2448 |<------------------------------------------------------| 2449 | | 2450 . . 2451 . . 2453 1. blueprintsRequest message: 2455 2456 2460 2462 xcon-userid:alice@example.com 2463 2464 2465 2467 2. blueprintsResponse message form the server: 2469 2470 2474 2477 xcon-userid:Alice@example.com 2478 200 2479 2480 2481 2482 xcon:AudioRoom@example.com 2483 AudioRoom 2484 Simple Room: 2485 conference room with public access, 2486 where only audio is available, more users 2487 can talk at the same time 2488 and the requests for the AudioFloor 2489 are automatically accepted. 2490 2491 2492 2493 xcon:VideoRoom@example.com 2494 VideoRoom 2495 Video Room: 2496 conference room with public access, 2497 where both audio and video are available, 2498 8 users can talk and be seen at the same time, 2499 and the floor requests are automatically accepted. 2500 2501 2502 2503 xcon:AudioConference1@example.com 2504 AudioConference1 2505 Public Audio Conference: 2506 conference with public access, 2507 where only audio is available, 2508 only one user can talk at the same time, 2509 and the requests for the AudioFloor MUST 2510 be accepted by a Chair. 2511 2512 2513 2514 xcon:VideoConference1@example.com 2515 VideoConference1 2516 Public Video Conference: conference 2517 where both audio and video are available, 2518 only one user can talk 2519 2520 2521 2522 xcon:AudioConference2@example.com 2523 AudioConference2 2524 Basic Audio Conference: 2525 conference with private access, 2526 where only audio is available, 2527 only one user can talk at the same time, 2528 and the requests for the AudioFloor MUST 2529 be accepted by a Chair. 2530 2531 2533 2534 2535 2536 2538 Figure 19: Getting blueprints from the server 2540 6.2. Alice gets detailed information about a specific blueprint 2542 This section illustrates the second transaction in the overall flow. 2543 In this case, Alice, who now knows the XCON-URIs of the blueprints 2544 available at the server, makes a drill-down query, in the form of a 2545 CCMP "blueprintRequest" message, to get detailed information about 2546 one of them (the one called with XCON-URI 2547 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2548 Notice that the response contains, in the "blueprintInfo" parameter, 2549 a document compliant with the standard XCON data model. 2551 Alice retrieves detailed information about a specified blueprint: 2553 CCMP Client CCMP Server 2554 | | 2555 | CCMP blueprintRequest message | 2556 | - confUserID: Alice | 2557 | - confObjID: bp123 | 2558 | - operation: retrieve | 2559 | - blueprintInfo: (null) | 2560 |------------------------------------------------------>| 2561 | | 2562 | CCMP blueprintResponse message | 2563 | - confUserID: Alice | 2564 | - confObjID: bp123 | 2565 | - operation: retrieve | 2566 | - response-code: 200 | 2567 | - blueprintInfo: bp123Info | 2568 |<------------------------------------------------------| 2569 | | 2570 . . 2571 . . 2573 1. blueprintRequest message: 2575 2576 2580 2582 xcon-userid:Alice@example.com 2583 xcon:AudioRoom@example.com 2584 retrieve 2585 2586 2587 2589 2. blueprintResponse message form the server: 2591 2592 2596 2598 xcon-userid:alice@example.com 2599 xcon:AudioRoom@example.com 2600 retrieve 2601 200 2602 Success 2603 2604 2605 2606 AudioRoom 2607 2608 2609 2610 audio stream 2611 2612 audio 2613 2614 2615 2616 2617 allow 2618 2619 2620 confirm 2621 2622 2623 2624 2625 audioLabel 2626 2627 2628 2629 2630 2631 2632 2633 2635 Figure 20: Getting info about a specific blueprint 2637 6.3. Alice creates a new conference through a cloning operation 2639 This section illustrates the third transaction in the overall flow. 2640 Alice decides to create a new conference by cloning the blueprint 2641 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2642 retrieved detailed information through the "blueprintRequest" 2643 message. This is achieved by sending a "confRequest/create" message 2644 having the blueprint's URI in the "confObjID" parameter. The picture 2645 shows such transaction. Notice that the response contains, in the 2646 "confInfo" parameter, the document associated with the newly created 2647 conference, which is compliant with the standard XCON data model. 2648 The "confObjID" in the response is set to the XCON-URI of the new 2649 conference (in this case, "xcon:8977794@example.com"). We also 2650 notice that this value is equal to the value of the "entity" 2651 attribute of the element of the document 2652 representing the newly created conference object. 2654 Alice creates a new conference by cloning the 2655 "xcon:AudioRoom@example.com" blueprint: 2657 CCMP Client CCMP Server 2658 | | 2659 | CCMP confRequest message | 2660 | - confUserID: Alice | 2661 | - confObjID: AudioRoom | 2662 | - operation: create | 2663 | - confInfo: (null) | 2664 |------------------------------------------------------>| 2665 | | 2666 | CCMP confResponse message | 2667 | - confUserID: Alice | 2668 | - confObjID: newConfId | 2669 | - operation: create | 2670 | - response-code: 200 | 2671 | - version: 1 | 2672 | - confInfo: newConfInfo | 2673 |<------------------------------------------------------| 2674 | | 2675 . . 2676 . . 2678 1. confRequest message: 2680 2681 2685 2688 xcon-userid:Alice@example.com 2689 xcon:AudioRoom@example.com 2690 create 2691 2692 2693 2695 2. confResponse message from the server: 2697 2698 2702 2704 xcon-userid:Alice@example.com 2705 xcon:8977794@example.com 2706 create 2707 200 2708 Success 2709 1 2710 2711 2712 2713 2714 New conference by Alice cloned from AudioRoom 2715 2716 2717 2718 2719 audio stream 2720 2721 audio 2722 2723 2724 2725 2726 allow 2727 2728 2729 2730 confirm 2731 2732 2733 2734 333 2735 2736 2737 2738 2739 2740 2741 2743 Figure 21: Creating a new conference by cloning a blueprint 2745 6.4. Alice updates conference information 2747 This section illustrates the fourth transaction in the overall flow. 2748 Alice decides to modify some of the details associated with the 2749 conference she just created. More precisely, she changes the 2750 element under the element of 2751 the document representing the conference. This is achieved through a 2752 "confRequest/update" message carrying the fragment of the conference 2753 document to which the required changes have to be applied. As shown 2754 in the picture, the response contains a code of "200", which 2755 acknowledges the modifications requested by the client, while also 2756 updating the conference version number from 1 to 2, as reflected in 2757 the "version" parameter. 2759 Alice updates information about the conference she just created: 2761 CCMP Client CCMP Server 2762 | | 2763 | CCMP confRequest message | 2764 | - confUserID: Alice | 2765 | - confObjID: 8977794 | 2766 | - operation: update | 2767 | - confInfo: confUpdates | 2768 |------------------------------------------------------>| 2769 | | 2770 | CCMP confResponse message | 2771 | - confUserID: Alice | 2772 | - confObjID: 8977794 | 2773 | - operation: update | 2774 | - response-code: 200 | 2775 | - version: 2 | 2776 | - confInfo: (null) | 2777 |<------------------------------------------------------| 2778 | | 2779 . . 2780 . . 2782 1. confRequest message: 2784 2785 2789 2792 xcon-userid:Alice@example.com 2793 xcon:8977794@example.com 2794 update 2795 2796 2797 2798 2799 Alice's conference 2800 2801 2802 2803 2804 2805 2806 2. confResponse message form the server: 2808 2809 2813 2815 xcon-userid:Alice@example.com 2816 xcon:8977794@example.com 2817 update 2818 200 2819 Success 2820 2 2821 2822 2823 2825 Figure 22: Updating conference information 2827 6.5. Alice inserts a list of users in the conference object 2829 This section illustrates the fifth transaction in the overall flow. 2830 Alice modifies the under the element in 2831 the document associated with the conference she created. To the 2832 purpose, she exploits the "usersRequest" message provided by the 2833 CCMP. The picture below shows the transaction. 2835 Alice updates information about the list of users to whom access to 2836 the conference is permitted: 2838 CCMP Client CCMP Server 2839 | | 2840 | CCMP usersRequest message | 2841 | - confUserID: Alice | 2842 | - confObjID: 8977794 | 2843 | - operation: update | 2844 | - usersInfo: usersUpdates | 2845 |------------------------------------------------------>| 2846 | | 2847 | CCMP usersResponse message | 2848 | - confUserID: Alice | 2849 | - confObjID: 8977794 | 2850 | - operation: update | 2851 | - response-code: 200 | 2852 | - version: 3 | 2853 | - usersInfo: (null) | 2854 |<------------------------------------------------------| 2855 | | 2856 . . 2857 . . 2859 1. usersRequest message: 2861 2862 2866 2868 xcon-userid:Alice@example.com 2869 xcon:8977794@example.com 2870 update 2871 2872 2873 2874 2876 2878 2880 2881 2882 2883 2884 2886 2. usersResponse message form the server: 2888 2889 2893 2895 xcon-userid:Alice@example.com 2896 xcon:8977794@example.com 2897 retrieve 2898 200 2899 Success 2900 3 2901 2902 2903 2905 Figure 23: Updating the list of allowed users for the conference 2906 'xcon:8977794@example.com' 2908 6.6. Alice joins the conference 2910 This section illustrates the sixth transaction in the overall flow. 2911 Alice uses the CCMP to add herself to the newly created conference. 2912 This is achieved through a "userRequest/create" message containing, 2913 in the "userInfo" parameter, a element compliant with the XCON 2914 data model representation. Notice that such element includes 2915 information about the user's Address of Records, as well as her 2916 current end-point. The picture below shows the transaction. Notice 2917 how the "confUserID" parameter is equal to the "entity" attribute of 2918 the element, which indicates that the request issued by 2919 the client is a first-party one. 2921 Alice joins the conference by issuing a "userRequest/create" message 2922 with her own id to the server: 2924 CCMP Client CCMP Server 2925 | | 2926 | CCMP userRequest message | 2927 | - confUserID: Alice | 2928 | - confObjID: 8977794 | 2929 | - operation: create | 2930 | - userInfo: AliceUserInfo | 2931 |------------------------------------------------------>| 2932 | | 2933 | CCMP userResponse message | 2934 | - confUserID: Alice | 2935 | - confObjID: 8977794 | 2936 | - operation: create | 2937 | - response-code: 200 | 2938 | - version: 4 | 2939 | - userInfo: (null) | 2940 |<------------------------------------------------------| 2941 | | 2942 . . 2944 . . 2946 1. userRequest message: 2948 2949 2953 2955 xcon-userid:Alice@example.com 2956 xcon:8977794@example.com 2957 create 2958 2959 2960 2961 2962 2963 mailto:Alice83@example.com 2964 2965 email 2966 2967 2968 2969 2970 2971 2972 2974 2. userResponse message form the server: 2976 2977 2981 2983 xcon-userid:Alice@example.com 2984 xcon:8977794@example.com 2985 create 2986 200 2987 Success 2988 4 2989 2990 2992 2994 Figure 24: Alice joins the conference through the CCMP 2996 6.7. Alice adds a new user to the conference 2998 This section illustrates the seventh and last transaction in the 2999 overall flow. Alice uses the CCMP to add a new conferencing system 3000 user, Ciccio, to the conference. This "third-party" request is 3001 realized through a "userRequest/create" message containing, in the 3002 "userInfo" parameter, a element compliant with the XCON data 3003 model representation. Notice that such element includes information 3004 about Ciccio's Address of Records, as well as his current end-point, 3005 but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as 3006 discussed in Section 4.3, since the XCON-USERID is initially unknown 3007 to Alice. Thus, the conference server is in charge of generating a 3008 new XCON-USERID for the user Alice indicates (i.e, Ciccio), and 3009 returning it in the "entity" attribute of the "userInfo" parameter 3010 carried in the response, as well as adding the user to the 3011 conference. The picture below shows the transaction. 3013 Alice adds user "Ciccio" to the conference by issuing a third-party 3014 "userRequest/create" message to the server: 3016 CCMP Client CCMP Server 3017 | | 3018 | CCMP userRequest message | 3019 | - confUserID: Alice | 3020 | - confObjID: 8977794 | 3021 | - operation: create | 3022 | - userInfo: dummyUserID, CiccioUserInfo | 3023 |------------------------------------------------------>| 3024 | | 3025 | CCMP optionsResponse message | 3026 | - confUserID: Alice | 3027 | - confObjID: 8977794 | 3028 | - operation: create | 3029 | - response-code: 200 | 3030 | - version: 5 | 3031 | - userInfo: userIDCiccio, | 3032 | CiccioUserInfo | 3033 | | 3034 |<------------------------------------------------------| 3035 | | 3036 . . 3037 . . 3039 1. "third party" userRequest message from Alice: 3041 3042 3046 3048 xcon-userid:Alice@example.com 3049 xcon:8977794@example.com 3050 create 3051 3052 3053 3054 3055 3056 mailto:Ciccio@example.com 3057 3058 email 3059 3060 3061 3062 3063 3064 3065 3067 2. "third party" userResponse message from the server: 3069 3070 3074 3076 xcon-userid:Alice@example.com 3077 xcon:8977794@example.com 3078 create 3079 200 3080 5 3081 3082 3083 3084 3085 3086 mailto:Ciccio@example.com 3087 3088 email 3089 3090 3091 3092 3093 3094 3095 3097 Figure 25: Alice adds a new user to the conference through the CCMP 3099 6.8. Alice asks for the CCMP server capabilities 3101 This section illustrates how Alice can discover which standard CCMP 3102 messages and what extensions are supported by the CCMP server she 3103 interacts with through an optionsRequest/optionsResponse transaction. 3105 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 3106 confUserID parameter. Looking at the element in the 3107 received optionsResponse, Alice infers the following server 3108 capabilities as regards standard CCMP messages: 3110 o the server doesn't support sidebarsByValRequest nor 3111 sidebarByValRequest messages, since they do not appear in the 3112 ; 3114 o the only implemented operation for the blueprintRequest message is 3115 "retrieve", since no other entries are included in the 3116 related field. 3118 By analyzing the , Alice discovers the server 3119 implements a bluePrint extension, referred to as "confSummaryRequest" 3120 in this example. This extension allows Alice to recover via CCMP a 3121 brief description of a specific conference; the XML elements involved 3122 in this extended conference control transaction are available at the 3123 URL indicated in the element and the only operation 3124 provided by this extension is "retrieve". To better understand how 3125 Alice can exploit the "confSummaryRequest" extension via CCMP, see 3126 Section 6.9. 3128 The figure below shows the optionsRequest/optionsResponse message 3129 exchange between Alice and the CCMP server. 3131 CCMP Client CCMP Server 3132 | | 3133 | CCMP optionsRequest message | 3134 | - confUserID: Alice | 3135 |------------------------------------------------------>| 3136 | | 3137 | CCMP userResponse message | 3138 | - confUserID: Alice | 3139 | - response-code: 200 | 3140 | - options (list of both | 3141 | standard and extended | 3142 | supported messages) | 3143 |<------------------------------------------------------| 3144 | | 3145 . . 3146 . . 3148 1. optionsRequest (Alice asks for CCMP server capabilities) 3150 3151 3155 3157 xcon-userid:Alice@example.com 3158 3159 3161 2. optionsResponse (the server returns the list of its conference 3162 control capabilities) 3164 3165 3169 3171 xcon-userid:Alice@example.com 3172 200 3173 success 3174 3175 3176 3177 3178 blueprintsRequest 3179 3180 3181 blueprintRequest 3182 3183 retrieve 3184 3185 3186 3187 confsRequest 3188 3189 3190 confRequest 3191 3192 3193 usersRequest 3194 3195 3196 userRequest 3197 3198 3199 sidebarsByRefRequest 3200 3201 3202 sidebarByRefRequest 3203 3204 3205 3206 3207 confSummaryRequest 3208 3209 retrieve 3210 3211 3212 http://example.com/ccmp-extension-schema.xsd 3213 3214 3215 confSummaryRequest is intented 3216 to allow the requestor to retrieve 3217 a brief description 3218 of the conference indicated in the 3219 confObjID request parameter 3221 3222 3223 3224 3225 3226 3227 3229 Figure 26: Alice asks for the server control capabilities 3231 6.9. Alice exploits a CCMP server extension 3233 In this section, a very simple example of CCMP extension support is 3234 provided. Alice can recover information about this and other server- 3235 supported extensions by issuing an optionsRequest (see Section 6.8). 3237 The extension in question is named "confSummaryRequest" and is 3238 conceived to allow a CCMP client to obtain from the CCMP server 3239 synthetic information about a specific conference. The conference 3240 summary is carried in the form of an XML element, , 3241 defined by the following XML schema: 3243 3244 3246 3248 3249 3250 3251 3252 3253 3254 3255 3257 3259 Figure 27: Example of XML Schema defining an extension parameter 3260 (ccmp-extension-schema.xsd) 3262 As it can be inferred from the schema file, the element 3263 contains conference information related to: 3265 o title 3267 o status (active or registered) 3269 o participation modality (if everyone is allowed to participate, the 3270 boolean element is set to "true") 3272 o involved media 3274 In order to retrieve a conference summary related to the conference 3275 she participates in, Alice then sends to the CCMP server an 3276 extendedRequest with a "confSummaryRequest" , 3277 specifying the conference xcon-uri in the confObjID request 3278 parameter, as depicted in the figure below. 3280 CCMP Client CCMP Server 3281 | | 3282 | CCMP extendedRequest message | 3283 | - confUserID: Alice | 3284 | - confObjID: 8977794 | 3285 | - operation: retrieve | 3286 | - extensionName: confSummaryRequest | 3287 |------------------------------------------------------>| 3288 | | 3289 | CCMP extendedResponse message | 3290 | - confUserID: Alice | 3291 | - confObjID: 8977794 | 3292 | - operation: retrieve | 3293 | - response-code: 200 | 3294 | - extensionName: | 3295 | confSummaryRequest | 3296 | - confSummary | 3297 |<------------------------------------------------------| 3298 | | 3299 . . 3300 . . 3302 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3304 3305 3309 3311 xcon-userid:Alice@example.com 3312 xcon:8977794@example.com 3313 retrieve 3314 3315 confRequestSummary 3316 3317 3318 3320 2. extendedResponse (the server provides Alice with a brief description 3321 of the desired conference) 3323 3324 3328 3330 xcon-userid:Alice@example.com 3331 xcon:8977794@example.com 3332 retrieve 3333 200 3334 success 3335 3336 confSummaryRequest 3337 3338 Alice's conference 3339 active 3340 true 3341 audio 3342 3343 3344 3345 3347 Figure 28: Alice exploits the 'confSummaryRequest' extension 3349 7. Locating a Conference Control Server 3351 If a conference control client is not pre-configured to use a 3352 specific conference control server for the requests, the client MUST 3353 first discover the conference control server before it can send any 3354 requests. The result of the discovery process, is the address of the 3355 server supporting conferencing. In this document, the result is an 3356 http: or https: URI, which identifies a conference server. 3358 This document proposes the use of DNS to locate the conferencing 3359 server. U-NAPTR resolution for conferencing takes a domain name as 3360 input and produces a URI that identifies the conferencing server. 3361 This process also requires an Application Service tag and an 3362 Application Protocol tag, which differentiate conferencing-related 3363 NAPTR records from other records for that domain. 3365 Section 12.4.1 defines an Application Service tag of "XCON", which is 3366 used to identify the centralized conferencing (XCON) server for a 3367 particular domain. The Application Protocol tag "CCMP", defined in 3368 Section 12.4.2, is used to identify an XCON server that understands 3369 the CCMP protocol. 3371 The NAPTR records in the following example Figure 29 demonstrate the 3372 use of the Application Service and Protocol tags. Iterative NAPTR 3373 resolution is used to delegate responsibility for the conferencing 3374 service from "zonea.example.com." and "zoneb.example.com." to 3375 "outsource.example.com.". 3377 zonea.example.com. 3378 ;; order pref flags 3379 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3380 "" ; regex 3381 outsource.example.com. ; replacement 3382 ) 3383 zoneb.example.com. 3384 ;; order pref flags 3385 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3386 "" ; regex 3387 outsource.example.com. ; replacement 3388 ) 3389 outsource.example.com. 3390 ;; order pref flags 3391 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 3392 "!*.!https://confs.example.com/!" ; regex 3393 . ; replacement 3394 ) 3396 Figure 29: Sample XCON:CCMP Service NAPTR Records 3398 Details for the "XCON" Application Service tag and the "CCMP" 3399 Application Protocol tag are included in Section 12.4. 3401 8. Managing Notifications 3403 As per [RFC5239], the CCMP is one of the following four protocols 3404 which have been formally identified within the XCON framework: 3406 Conference Control Protocol: between Conference and Media Control 3407 Client and Conference Server. Such protocol is the subject of the 3408 present document. 3410 Binary floor Control Protocol: between the Floor Control Client and 3411 the Floor Control Server. Such protocol is the BFCP, specified in 3412 [RFC4582]. 3414 Call Signaling Protocol: between the Call Signaling Client and the 3415 Focus. Such protocol can be either SIP or any other call 3416 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3417 a conferencing session. 3419 Notification Protocol: between the Notification Client and the XCON 3420 Notification Service. This specification does not define a new 3421 notification protocol. For clients that use SIP as the call 3422 signaling protocol, the XCON event package 3423 [I-D.ietf-xcon-event-package] MUST be used by the client for 3424 notifications of changes in the conference data as described 3425 below. 3427 The CCMP protocol specified in this document is a pro-active one and 3428 is used by a conferencing client to send requests to a conferencing 3429 server in order to retrieve information about the conference objects 3430 stored by the server and to potentially manipulate them. However, a 3431 complete conferencing solution is not prohibited from providing 3432 clients with a means for receiving asynchronous updates about the 3433 status of the objects available at the server. The notification 3434 protocol, while conceptually independent of all the mentioned 3435 companion protocols, can nonetheless be chosen in a way that is 3436 consistent with the overall protocol architecture characterizing a 3437 specific deployment, as discussed in the following. 3439 When the conference control client uses SIP [RFC3261] as the 3440 signaling protocol to participate in the conference, SIP event 3441 notification can be used. In such a case, the conference control 3442 client MUST implement the Conference event package for XCON 3443 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3444 conferencing clients as is SIP for signaling per the XCON Framework 3446 [RFC5239]. 3448 In the case where the interface to the conference server is entirely 3449 web based, there is a common mechanism for web-based systems that 3450 could be used - a "call back". With this mechanism, the conference 3451 client provides the conference server with an HTTP URL which is 3452 invoked when a change occurs. This is a common implementation 3453 mechanism for e-commerce. This works well in the scenarios whereby 3454 the conferencing client is a web server that provides the graphical 3455 HTML user interface and uses CCMP as the backend interface to the 3456 conference server. And, this model can co-exist with the SIP event 3457 notification model. PC-based clients behind NATs could provide a SIP 3458 event URI, whereas web-based clients using CCMP in the backend would 3459 probably find the HTTP call back approach much easier. The details 3460 of this approach are out of scope for the CCMP per se, thus the 3461 expectation is that a future specification will document this 3462 solution. 3464 9. HTTP Transport 3466 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3467 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3468 conforming conference Server and Conferencing client MUST support. 3470 Although CCMP uses HTTP as a transport, it uses a strict subset of 3471 HTTP features, and due to the restrictions of some features, a 3472 conferencing server may not be a fully compliant HTTP server. It is 3473 intended that a conference server can easily be built using an HTTP 3474 server with extensibility mechanisms, and that a conferencing client 3475 can trivially use existing HTTP libraries. This subset of 3476 requirements helps implementors avoid ambiguity with the many options 3477 the full HTTP protocol offers. 3479 A conferencing client that conforms to this specification is not 3480 required to support HTTP authentication [RFC2617] or cookies 3481 [RFC2965]. These mechanism are unnecessary because CCMP requests 3482 carry their own authentication information (in the "subject" field; 3483 see Section 5.1). 3485 A CCMP request is carried in the body of an HTTP POST request. The 3486 conferencing client MUST include a Host header in the request. 3488 The MIME type of CCMP request and response bodies is "application/ 3489 ccmp+xml". The conference server and conferencing client MUST 3490 provide this value in the HTTP Content-Type and Accept header fields. 3491 If the conference server does not receive the appropriate Content- 3492 Type and Accept header fields, the conference server SHOULD fail the 3493 request, returning a 406 (not acceptable) response. CCMP responses 3494 SHOULD include a Content-Length header. 3496 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3497 header in CCMP requests. The conference server MAY return 501 (not 3498 implemented) errors if either of these HTTP features are used. In 3499 the case that the conference server receives a request from the 3500 conferencing client containing a If-* (conditional) header, the 3501 conference server SHOULD return a 412 (precondition failed) response. 3503 The POST method is the only method REQUIRED for CCMP. If a 3504 conference server chooses to support GET or HEAD, it SHOULD consider 3505 the kind of application doing the GET. Since a conferencing client 3506 only uses a POST method, the GET or HEAD MUST be either an escaped 3507 URL (e.g., somebody found a URL in protocol traces or log files and 3508 fed it into their browser) or somebody doing testing/ debugging. The 3509 conference server could provide information in the CCMP response 3510 indicating that the URL corresponds to a conference server and only 3511 responds to CCMP POST requests or the conference server could instead 3512 try to avoid any leak of information by returning a very generic HTTP 3513 error message such as 405 (method not allowed). 3515 The conference server populates the HTTP headers of responses so that 3516 they are consistent with the contents of the message. In particular, 3517 the "CacheControl" header SHOULD be set to disable caching of any 3518 conference information by HTTP intermediaries. Otherwise, there is 3519 the risk of stale information and/or the unauthorized disclosure of 3520 the information. The HTTP status code MUST indicate a 2xx series 3521 response for all CCMP Response and Error messages. 3523 The conference server MAY redirect a CCMP request. A conferencing 3524 client MUST handle redirects, by using the Location header provided 3525 by the server in a 3xx response. When redirecting, the conferencing 3526 client MUST observe the delay indicated by the Retry-After header. 3527 The conferencing client MUST authenticate the server that returns the 3528 redirect response before following the redirect. A conferencing 3529 client SHOULD authenticate the conference server indicated in a 3530 redirect. 3532 The conference server SHOULD support persistent connections and 3533 request pipelining. If pipelining is not supported, the conference 3534 server MUST NOT allow persistent connections. The conference server 3535 MUST support termination of a response by the closing of a 3536 connection. 3538 Implementations of CCMP that implement HTTP transport MUST implement 3539 transport over TLS [RFC2818]. TLS provides message integrity and 3540 confidentiality between the conference control client and the 3541 conference control server. The conferencing client MUST implement 3542 the server authentication method described in HTTPS [RFC2818]. The 3543 device uses the URI obtained during conference server discovery to 3544 authenticate the server. The details of this authentication method 3545 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3546 the conferencing client SHOULD fail a request if server 3547 authentication fails. 3549 10. Security Considerations 3551 As identified in the XCON framework [RFC5239], there are a wide 3552 variety of potential attacks related to conferencing, due to the 3553 natural involvement of multiple endpoints and the capability to 3554 manipulate the data on the conference server using CCMP. Examples of 3555 attacks include the following: an endpoint attempting to listen to 3556 conferences in which it is not authorized to participate, an endpoint 3557 attempting to disconnect or mute other users, and theft of service by 3558 an endpoint in attempting to create conferences it is not allowed to 3559 create. 3561 The following summarizes the security considerations for CCMP: 3563 1. The client MUST determine the proper conference server. The 3564 conference server discovery is described in Section 7. 3566 2. The client MUST connect to the proper conference server. The 3567 mechanisms for addressing this security consideration are 3568 described in Section 10.1. 3570 3. The protocol MUST support a confidentiality and integrity 3571 mechanism. As described in Section 9, implementations of CCMP 3572 MUST implement the HTTP transport over TLS [RFC2818]. 3574 4. There are security issues associated with the authorization to 3575 perform actions on the conferencing system to invoke specific 3576 capabilities. A conference server SHOULD ensure that only 3577 authorized entities can manipulate the conference data. The 3578 mechanisms for addressing this security consideration are 3579 described in Section 10.2. 3581 5. The privacy and security of the identity of a user in the 3582 conference MUST be assured. The mechanisms to ensure the 3583 security and privacy of identity are discussed in Section 10.3. 3585 6. A final issue is related to Denial of Service (DoS) attacks on 3586 the conferencing server itself. In order to minimize the 3587 potential for DoS attacks, it is RECOMMENDED that conferencing 3588 systems require user authentication and authorization for any 3589 client participating in a conference. This can be accomplished 3590 through the use of the mechanisms described in Section 10.2, as 3591 well as by using the security mechanisms associated with the 3592 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 3593 Most CCMP commands can pend indefinitely, thus increasing the 3594 potential that pending requests can continue to increase when a 3595 server is receiving more requests than it can process within a 3596 specific time period. In this case a server SHOULD return a 510 3597 response code to the pending requests. In addition, to mitigate 3598 the situation clients MUST NOT wait indefinitely for a response 3599 and MUST implement a timer (in the range of seconds) such that 3600 when it expires, the client MUST close the connection. 3602 10.1. Assuring that the Proper Conferencing Server has been contacted 3604 When the CCMP transaction is conducted using TLS [RFC5246], the 3605 conference server can authenticate its identity, either as a domain 3606 name or as an IP address, to the conference client by presenting a 3607 certificate containing that identifier as a subjectAltName (i.e., as 3608 an iPAddress or dNSName, respectively). With the use of HTTP as a 3609 transport for CCMP, this is exactly the authentication described by 3610 TLS [RFC2818]. If the client has external information as to the 3611 expected identity or credentials of the proper conference server 3612 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 3613 implementation of CCMP MUST be capable of being transacted over TLS 3614 so that the client can request the above authentication, and a 3615 conference server implementation MUST include this feature. Note 3616 that in order for the presented certificate to be valid at the 3617 client, the client must be able to validate the certificate. In 3618 particular, the validation path of the certificate must end in one of 3619 the client's trust anchors, even if that trust anchor is the 3620 conference server certificate itself. 3622 10.2. User Authentication and Authorization 3624 Many policy authorization decisions are based on the identity of the 3625 user or the role that a user may have. The conferencing server MUST 3626 implement mechanisms for authentication of users to validate their 3627 identity. There are several ways that a user might authenticate its 3628 identity to the system. For users joining a conference using one of 3629 the call signaling protocols, the user authentication mechanisms for 3630 the specific protocol can be used. For the case of users joining the 3631 conference using the CCMP, TLS is RECOMMENDED. 3633 The XCON Framework [RFC5239] provides an overview of other 3634 authorization mechanisms. In the cases where a user is authorized 3635 via multiple mechanisms, it is RECOMMENDED that the conference server 3636 correlate the authorization of the CCMP interface with other 3637 authorization mechanisms - e.g., PSTN users that join with a PIN and 3638 control the conference using CCMP. When a conference server presents 3639 the identity of authorized users, it MAY provide information about 3640 the way the identity was proven or verified by the system. A 3641 conference server can also allow a completely unauthenticated user 3642 into the system - this information SHOULD also be communicated to 3643 interested parties. 3645 Once a user is authenticated and authorized through the various 3646 mechanisms available on the conference server, the conference server 3647 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3648 associate the XCON-USERID with any signaling specific user 3649 identifiers that were used for authentication and authorization. 3650 This XCON-USERID can be provided to a specific user through the 3651 conference notification interface and MUST be provided to users that 3652 interact with the conferencing system using the CCMP (i.e., in the 3653 appropriate CCMP response messages). This conference user identifier 3654 is REQUIRED for any subsequent operations on the conference object. 3656 We herein remark that the definition of a complete solution for 3657 policy-based management of an XCON-compliant conference system is out 3658 of the scope of this document, as well as of the XCON WG. We believe 3659 that the specification of such a framework is orthogonal to the 3660 overall XCON architecture, especially if a Role Based Access Control 3661 (RBAC) approach is embraced. In RBAC, the following elements are 3662 identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; 3663 (v) Permissions. For all of the above elements a direct mapping 3664 exists onto the main XCON entities. As an example, RBAC objects map 3665 onto XCON data model objects and RBAC operations map onto CCMP 3666 operations. 3668 Future documents might work on the definition of an RBAC framework 3669 for XCON, by first focusing on the definition of roles and eventually 3670 arriving at the specification of the needed permission policy sets 3671 and role policy sets (used to associate policy permission sets with 3672 specific roles). With these policies in place, access to a 3673 conference object compliant with the XCON data model can be 3674 appropriately controlled. Finally, coming to the issue of assigning 3675 users to roles, this can be done through so-called role-assignment 3676 policies. Such assignment should be under the responsibility of an 3677 ad-hoc dedicated Role Assignment entity. 3679 10.3. Security and Privacy of Identity 3681 An overview of the required privacy and anonymity for users of a 3682 conferencing system are provided in the XCON Framework [RFC5239]. 3683 The security of the identity in the form of the XCON-USERID is 3684 provided in the CCMP protocol through the use of TLS. 3686 The conference server SHOULD provide mechanisms to ensure the privacy 3687 of the XCON-USERID. This is accomplished by the conference client 3688 manipulation of the "provide-anonymity" element defined in the XCON 3689 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 3690 anonymity" element controls the degree to which a user reveals their 3691 identity. The conference client MUST set the "provide-anonymity" 3692 element to "hidden" if the user does not want other participants to 3693 even be aware that there is an additional participant in the 3694 conference. The conference client MUST set the "provide-anonymity" 3695 field to "private" if the user wants to be entirely "anonymous" 3696 (i.e., other participants are aware that there is another 3697 participant, but have no information as to their identity). The 3698 conference client MUST set the "provide-anonymity" field to "semi- 3699 private" if their identity is only to be revealed to other 3700 participants or users that have a higher level authorization (e.g., a 3701 conferencing system can be configured such that an administrator can 3702 see all users). To provide the required privacy, the conference 3703 client SHOULD include the "provide-anonymity" element in the 3704 "confInfo" parameter in a CCMP confRequest message with an "update" 3705 or "create" operation or in the "userInfo" parameter in a CCMP 3706 userRequest message with an "update" or "create" operation, to ensure 3707 the user is provided the appropriate level of privacy. If the 3708 "provide-anonymity" element is not included in the conference object, 3709 then other users can see the participant's identity. 3711 11. XML Schema 3713 This section provides the XML schema definition of the "application/ 3714 ccmp+xml" format. 3716 3718 3727 3730 3733 3734 3736 3738 3739 3740 3742 3743 3745 3747 3749 3750 3752 3754 3756 3758 3760 3762 3763 3764 3766 3768 3769 3770 3772 3773 3775 3777 3778 3779 3781 3783 3786 3789 3791 3793 3795 3796 3797 3799 3801 3803 3804 3805 3806 3807 3808 3809 3810 3811 3813 3815 3817 3818 3819 3821 3823 3824 3825 3826 3828 3829 3830 3831 3832 3833 3834 3835 3836 3838 3840 3842 3843 3844 3846 3848 3849 3850 3852 3854 3855 3856 3857 3858 3859 3860 3861 3862 3864 3866 3868 3869 3870 3872 3875 3876 3877 3879 3881 3882 3883 3884 3885 3886 3887 3888 3889 3891 3893 3895 3896 3897 3899 3901 3902 3903 3905 3907 3908 3909 3910 3911 3912 3913 3914 3915 3917 3919 3921 3922 3923 3925 3927 3928 3929 3931 3933 3934 3935 3936 3937 3938 3939 3940 3941 3943 3945 3947 3948 3949 3951 3953 3954 3955 3957 3959 3960 3961 3962 3963 3964 3965 3966 3967 3969 3970 3973 3974 3975 3977 3979 3980 3981 3983 3985 3986 3987 3988 3989 3990 3991 3992 3993 3995 3997 4000 4001 4002 4004 4006 4007 4008 4010 4012 4013 4014 4015 4016 4017 4019 4020 4021 4023 4025 4028 4029 4030 4032 4034 4035 4036 4038 4040 4041 4042 4043 4044 4045 4046 4047 4048 4050 4052 4055 4056 4057 4059 4061 4062 4063 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4076 4078 4080 4081 4082 4084 4086 4087 4089 4091 4092 4093 4094 4095 4096 4098 4100 4102 4103 4104 4105 4106 4107 4108 4109 4110 4112 4113 4115 4116 4117 4119 4121 4122 4123 4125 4127 4128 4129 4130 4131 4132 4133 4134 4135 4137 4139 4141 4142 4143 4145 4147 4148 4149 4151 4153 4154 4155 4156 4157 4158 4159 4160 4162 4164 4166 4168 4169 4170 4172 4174 4175 4176 4178 4180 4181 4182 4183 4184 4185 4186 4187 4188 4190 4192 4194 4195 4196 4198 4200 4201 4202 4204 4206 4207 4208 4209 4210 4211 4212 4213 4214 4216 4218 4220 4221 4222 4224 4226 4227 4228 4230 4232 4233 4234 4235 4236 4237 4238 4239 4240 4242 4244 4246 4247 4248 4250 4252 4253 4254 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4267 4269 4272 4273 4274 4276 4278 4279 4280 4282 4284 4285 4286 4287 4288 4289 4290 4291 4292 4294 4296 4299 4300 4301 4303 4306 4307 4308 4310 4312 4313 4314 4315 4316 4317 4318 4319 4320 4322 4324 4327 4328 4329 4331 4333 4334 4335 4337 4339 4340 4341 4342 4343 4344 4345 4346 4347 4349 4351 4354 4355 4356 4358 4360 4361 4362 4364 4366 4367 4368 4369 4370 4371 4372 4373 4374 4376 4378 4380 4381 4382 4384 4387 4388 4390 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4403 4406 4407 4408 4410 4412 4413 4414 4416 4418 4420 4421 4422 4423 4424 4426 4428 4429 4430 4431 4432 4433 4434 4435 4437 4439 4440 4441 4443 4445 4447 4448 4450 4452 4454 4455 4456 4459 4462 4464 4465 4466 4468 4470 4471 4472 4475 4477 4478 4479 4481 4483 4484 4485 4488 4491 4492 4493 4495 4496 4497 4498 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4515 4517 4518 4519 4521 4522 4523 4525 4527 4528 4529 4532 4534 4535 4536 4538 4540 4541 4542 4543 4547 4548 4551 4553 4554 4555 4557 4559 Figure 30 4561 12. IANA Considerations 4563 This document registers a new XML namespace, a new XML schema, and 4564 the MIME type for the schema. This document also registers the 4565 "XCON" Application Service tag and the "CCMP" Application Protocol 4566 tag. This document also defines registries for the CCMP operation 4567 types and response codes. 4569 12.1. URN Sub-Namespace Registration 4571 This section registers a new XML namespace, 4572 ""urn:ietf:params:xml:ns:xcon:ccmp"". 4574 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 4576 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4577 Mary Barnes (mary.ietf.barnes@gmail.com). 4579 XML: 4581 BEGIN 4582 4583 4585 4586 4587 CCMP Messages 4588 4589 4590

Namespace for CCMP Messages

4591

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

4592 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4593 with the RFC number for this specification.]] 4594

See RFCXXXX.

4595 4596 4597 END 4599 12.2. XML Schema Registration 4601 This section registers an XML schema as per the guidelines in 4602 [RFC3688]. 4604 URI: urn:ietf:params:xml:schema:xcon:ccmp 4606 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4607 Barnes (mary.ietf.barnes@gmail.com). 4609 Schema: The XML for this schema can be found as the entirety of 4610 Section 11 of this document. 4612 12.3. MIME Media Type Registration for 'application/ccmp+xml' 4614 This section registers the "application/ccmp+xml" MIME type. 4616 To: ietf-types@iana.org 4618 Subject: Registration of MIME media type application/ccmp+xml 4620 MIME media type name: application 4622 MIME subtype name: ccmp+xml 4624 Required parameters: (none) 4625 Optional parameters: charset 4626 Same as the charset parameter of "application/xml" as specified in 4627 RFC 3023 [RFC3023], Section 3.2. 4629 Encoding considerations: Same as the encoding considerations of 4630 "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. 4632 Security considerations: This content type is designed to carry 4633 protocol data related to conference control. Some of the data 4634 could be considered private. This media type does not provide any 4635 protection and thus other mechanisms such as those described in 4636 Section 10 are required to protect the data. This media type does 4637 not contain executable content. 4639 Interoperability considerations: None. 4641 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 4642 replace XXXX with the RFC number for this specification.]] 4644 Applications which use this media type: Centralized Conferencing 4645 control clients and servers. 4647 Additional Information: Magic Number(s): (none) 4648 File extension(s): .ccmpxml 4649 Macintosh File Type Code(s): TEXT 4651 Person & email address to contact for further information: Mary 4652 Barnes 4654 Intended usage: LIMITED USE 4656 Author/Change controller: The IETF 4658 Other information: This media type is a specialization of 4659 application/xml [RFC3023], and many of the considerations 4660 described there also apply to application/ccmp+xml. 4662 12.4. DNS Registrations 4664 Section 12.4.1 defines an Application Service tag of "XCON", which is 4665 used to identify the centralized conferencing (XCON) server for a 4666 particular domain. The Application Protocol tag "CCMP", defined in 4667 Section 12.4.2, is used to identify an XCON server that understands 4668 the CCMP protocol. 4670 12.4.1. Registration of a Conference Control Server Application Service 4671 Tag 4673 This section registers a new S-NAPTR/U-NAPTR Application Service tag 4674 for XCON, as mandated by [RFC3958]. 4676 Application Service Tag: XCON 4678 Intended usage: Identifies a server that supports centralized 4679 conferencing. 4681 Defining publication: RFCXXXX 4683 Contact information: The authors of this document 4685 Author/Change controller: The IESG 4687 12.4.2. Registration of a Conference Control Server Application 4688 Protocol Tag for CCMP 4690 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 4691 for the CCMP protocol, as mandated by [RFC3958]. 4693 Application Service Tag: CCMP 4695 Intended Usage: Identifies the Centralized Conferencing (XCON) 4696 Manipulation Protocol. 4698 Applicable Service Tag(s): XCON 4700 Terminal NAPTR Record Type(s): U 4702 Defining Publication: RFCXXXX 4704 Contact Information: The authors of this document 4706 Author/Change Controller: The IESG 4708 12.5. CCMP Protocol Registry 4710 This document requests that the IANA create a new registry for the 4711 CCMP protocol including an initial registry for operation types and 4712 response codes. 4714 12.5.1. CCMP Message Types 4716 The CCMP messages are described in Section 4.1 and defined in the XML 4717 schema in Section 11. The following summarizes the requested 4718 registry: 4720 Related Registry: CCMP Message Types Registry 4722 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4723 with the RFC number for this specification.] 4725 Registration/Assignment Procedures: New CCMP message types are 4726 allocated on a specification required basis. 4728 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4729 Barnes (mary.ietf.barnes@gmail.com). 4731 This section pre-registers the following initial CCMP message types: 4733 optionsRequest: Used by a conference control client to query a 4734 conferencing system for its capabilities, in terms of supported 4735 messages (both standard and non-standard). 4737 optionsResponse: The optionsResponse returns a list of CCMP messages 4738 (both standard and non-standard) supported by the specific 4739 conference server. 4741 blueprintsRequest: Used by a conference control client to query a 4742 conferencing system for its capabilities, in terms of available 4743 conference blueprints. 4745 blueprintsResponse: The blueprintsResponse returns a list of 4746 blueprints supported by the specific conference server. 4748 confsRequest: Used by a conference control client to query a 4749 conferencing system for its scheduled/active conferences. 4751 confsResponse: The "confsResponse" returns the list of the currently 4752 activated/scheduled conferences at the server. 4754 confRequest: The "confRequest" is used to create a conference object 4755 and/or to request an operation on the conference object as a 4756 whole. 4758 confResponse: The "confResponse" indicates the result of the 4759 operation on the conference object as a whole. 4761 userRequest: The "userRequest" is used to request an operation on 4762 the "user" element in the conference object. 4764 userResponse: The "userResponse" indicates the result of the 4765 requested operation on the "user" element in the conference 4766 object. 4768 usersRequest This "usersRequest" is used to manipulate the "users" 4769 element in the conference object, including parameters such as the 4770 "allowed-users-list", "join-handling", etc. 4772 usersResponse: This "usersResponse" indicates the result of the 4773 request to manipulate the "users" element in the conference 4774 object. 4776 sidebarRequest: This "sidebarRequest" is used to retrieve the 4777 information related to a sidebar or to create, change or delete a 4778 specific sidebar. 4780 sidebarResponse: This "sidebarResponse" indicates the result of the 4781 sidebarRequest. 4783 12.5.2. CCMP Response Codes 4785 The following summarizes the requested registry for CCMP Response 4786 codes: 4788 Related Registry: CCMP Response Code Registry 4790 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4791 with the RFC number for this specification.] 4793 Registration/Assignment Procedures: New response codes are allocated 4794 on a first-come/first-serve basis with specification required. 4796 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4797 Barnes (mary.ietf.barnes@gmail.com). 4799 This section pre-registers the following thirteen initial response 4800 codes as described above in Section 4.1: 4802 200: This code indicates that the request was successfully 4803 processed. 4805 409: This code indicates that a requested "update" cannot be 4806 successfully completed by the server. An example of such 4807 situation is when the modification of an object cannot be applied 4808 due to conflicts arising at the server's side (e.g. because the 4809 client version of the object is an obsolete one and the requested 4810 modifications collide with the up-to-date state of the object 4811 stored at the server). 4813 400: This code indicates that the request was badly formed in some 4814 fashion. 4816 401: This code indicates that the user was not authorized for the 4817 specific operation on the conference object. 4819 403: This code indicates that the specific operation is not valid 4820 for the target conference object. 4822 404: This code indicates that the specific conference object was not 4823 found. 4825 420: This code is returned in answer to a "userRequest/create" 4826 operation, in the case of a third-party invite, when the 4827 "confUserID" (contained in the "entity" attribute of the 4828 "userInfo" parameter) of the user to be added is unknown. 4830 421: This code is returned in the case of requests in which the 4831 "confUserID" of the sender is invalid. 4833 422: This code is returned in response to all requests wishing to 4834 access/manipulate a password-protected conference object, when the 4835 "conference-password" parameter contained in the request is wrong. 4837 423: This code is returned in response to all requests wishing to 4838 access/manipulate a password-protected conference object, when the 4839 "conference-password" parameter is missing in the request. 4841 424: This code is returned in response whenever the server wants to 4842 authenticate the requestor through the "subject" parameter and 4843 such a parameter is not provided in the request. 4845 425: This code indicates that the conferencing system cannot delete 4846 the specific conference object because it is a parent for another 4847 conference object. 4849 426: This code indicates that the target conference object cannot be 4850 changed (e.g., due to policies, roles, privileges, etc.). 4852 510: This code indicates that the request could not be processed 4853 within a reasonable time, with the time specific to a conferencing 4854 system implementation. 4856 500: This code indicates that the conferencing system experienced 4857 some sort of internal error. 4859 501: This code indicates that the specific operation is not 4860 implemented on that conferencing system. 4862 13. Acknowledgments 4864 The authors appreciate the feedback provided by Dave Morgan, Pierre 4865 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 4866 Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage and 4867 Peter Reissner. Special thanks go to Roberta Presta for her 4868 invaluable contribution to this document. Roberta has worked on the 4869 specification of the CCMP protocol at the University of Napoli for 4870 the preparation of her Master thesis. She has also implemented the 4871 CCMP prototype used for the trials and from which the dumps provided 4872 in Section 6 have been extracted. 4874 14. References 4876 14.1. Normative References 4878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4879 Requirement Levels", BCP 14, RFC 2119, March 1997. 4881 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4882 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4883 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4885 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 4886 Leach, P., Luotonen, A., and L. Stewart, "HTTP 4887 Authentication: Basic and Digest Access Authentication", 4888 RFC 2617, June 1999. 4890 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 4892 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 4893 Mechanism", RFC 2965, October 2000. 4895 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4896 January 2004. 4898 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 4899 Centralized Conferencing", RFC 5239, June 2008. 4901 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4902 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 4904 [I-D.ietf-xcon-common-data-model] 4905 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 4906 "Conference Information Data Model for Centralized 4907 Conferencing (XCON)", draft-ietf-xcon-common-data-model-23 4908 (work in progress), February 2011. 4910 14.2. Informative References 4912 [REST] Fielding, "Architectural Styles and the Design of Network- 4913 based Software Architectures", 2000. 4915 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 4916 Types", RFC 3023, January 2001. 4918 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4919 A., Peterson, J., Sparks, R., Handley, M., and E. 4920 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4921 June 2002. 4923 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 4924 Service Location Using SRV RRs and the Dynamic Delegation 4925 Discovery Service (DDDS)", RFC 3958, January 2005. 4927 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 4928 Control Protocol (BFCP)", RFC 4582, November 2006. 4930 [I-D.ietf-xcon-event-package] 4931 Camarillo, G., Srinivasan, S., Even, R., and J. 4932 Urpalainen, "Conference Event Package Data Format 4933 Extension for Centralized Conferencing (XCON)", 4934 draft-ietf-xcon-event-package-01 (work in progress), 4935 September 2008. 4937 [W3C.REC-soap12-part1-20030624] 4938 Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and 4939 M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", 4940 World Wide Web Consortium FirstEdition REC-soap12-part1- 4941 20030624, June 2003, 4942 . 4944 [W3C.REC-soap12-part2-20030624] 4945 Mendelsohn, N., Hadley, M., Gudgin, M., Moreau, J., and H. 4946 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 4947 Web Consortium FirstEdition REC-soap12-part2-20030624, 4948 June 2003, 4949 . 4951 Appendix A. Appendix A: Other protocol models and transports considered 4952 for CCMP 4954 The operations on the objects can be implemented in at least two 4955 different ways, namely as remote procedure calls - using SOAP as 4956 described in Appendix A.1 and by defining resources following a 4957 RESTful architecture Appendix A.2. 4959 In both approaches, servers will have to recreate their internal 4960 state representation of the object with each update request, checking 4961 parameters and triggering function invocations. In the SOAP 4962 approach, it would be possible to describe a separate operation for 4963 each atomic element, but that would greatly increase the complexity 4964 of the protocol. A coarser-grained approach to the CCMP does require 4965 that the server process XML elements in updates that have not changed 4966 and that there can be multiple changes in one update. 4968 For CCMP, the resource (REST) model might appear more attractive, 4969 since the conference operations fit the CRUD approach. 4971 Neither of these approaches were considered ideal as SOAP was not 4972 considered to be general purpose enough for use in a broad range of 4973 operational environments. It is quite awkward to apply a RESTful 4974 approach since the CCMP requires a more complex request/response 4975 protocol in order to maintain the data both in the server and at the 4976 client. This doesn't map very elegantly to the basic request/ 4977 response model, whereby a response typically indicates whether the 4978 request was successful or not, rather than providing additional data 4979 to maintain the synchronization between the client and server data. 4980 In addition, the CCMP clients may also receive the data in 4981 Notifications. While the notification method or protocol used by 4982 some conferencing clients can be independent of the CCMP, the same 4983 data in the server is used for both the CCMP and Notifications - this 4984 requires a server application above the transport layer (e.g., HTTP) 4985 for maintaining the data, which in the CCMP model is transparent to 4986 the transport protocol. 4988 A.1. Using SOAP for the CCMP 4990 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 4991 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 4992 -soap12-part2-20030624]), where conferences and the other objects are 4993 modeled as services with associated operations. Conferences and 4994 other objects are selected by their own local identifiers, such as 4995 email-like names for users. This approach has the advantage that it 4996 can easily define atomic operations that have well-defined error 4997 conditions. 4999 All SOAP operations would use a single HTTP verb. While the RESTful 5000 approach requires the use of a URI for each object, SOAP can use any 5001 token. 5003 A.2. A RESTful approach for the CCMP 5005 Conference objects can also be modeled as resources identified by 5006 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 5007 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 5008 changing objects and DELETE for deleting them. Many of the objects, 5009 such as conferences, already have natural URIs. 5011 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 5012 design pattern. The basic CRUD operations are used to manipulate 5013 conference objects, which are XML documents containing the 5014 information characterizing a specified conference instance, be it an 5015 active conference or a conference blueprint used by the conference 5016 server to create new conference instances through a simple clone 5017 operation. 5019 Following the CRUD approach, CCMP could use a general-purpose 5020 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 5021 encoded data objects defined in the Conference Information Data Model 5022 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 5024 Following on the CRUD approach, CCMP could follow the well-known REST 5025 (REpresentational State Transfer) architectural style [REST]. The 5026 CCMP could map onto the REST philosophy, by specifying resource URIs, 5027 resource formats, methods supported at each URI and status codes that 5028 have to be returned when a certain method is invoked on a specific 5029 URI. A REST-style approach must ensure sure that all operations can 5030 be mapped to HTTP operations. 5032 The following summarizes the specific HTTP method that could be used 5033 for each of the CCMP Requests: 5035 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 5036 obtain data about conference objects in the form of XML data model 5037 documents. 5039 Create: HTTP PUT could be used to create a new object as identified 5040 by the XCON-URI or XCON-USERID. 5042 Change: Either HTTP PATCH or HTTP POST could be used to change the 5043 conference object identified by the XCON-URI. 5045 Delete: HTTP DELETE could be used to delete conference objects and 5046 parameters within conference objects identified by the XCON-URI. 5048 Authors' Addresses 5050 Mary Barnes 5051 Polycom 5052 TX 5053 US 5055 Email: mary.ietf.barnes@gmail.com 5057 Chris Boulton 5058 NS-Technologies 5060 Email: chris@ns-technologies.com 5062 Simon Pietro Romano 5063 University of Napoli 5064 Via Claudio 21 5065 Napoli 80125 5066 Italy 5068 Email: spromano@unina.it 5070 Henning Schulzrinne 5071 Columbia University 5072 Department of Computer Science 5073 450 Computer Science Building 5074 New York, NY 10027 5076 Email: hgs+xcon@cs.columbia.edu