idnits 2.17.1 draft-ietf-xcon-ccmp-14.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 127 has weird spacing: '... and trans...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 12, 2011) is 4671 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 4471, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 4964, 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 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-31 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4582 (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: January 13, 2012 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 July 12, 2011 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-14 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 January 13, 2012. 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 . . . . 37 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 . . . . . . . . . 46 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 . . . . . . . . . . . . 82 108 10.4. Mitigating DoS Attacks . . . . . . . . . . . . . . . . . 83 109 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 83 110 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 111 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 101 112 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 102 113 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 102 114 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 103 115 12.4.1. Registration of a Conference Control Server 116 Application Service Tag . . . . . . . . . . . . . . . 104 117 12.4.2. Registration of a Conference Control Server 118 Application Protocol Tag for CCMP . . . . . . . . . . 104 119 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 104 120 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 105 121 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 107 122 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 109 123 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 124 14.1. Normative References . . . . . . . . . . . . . . . . . . 109 125 14.2. Informative References . . . . . . . . . . . . . . . . . 110 126 Appendix A. Appendix A: Evaluation of other protocol models 127 and transports considered for CCMP . . . . . . . . 111 128 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 112 129 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 113 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 132 1. Introduction 134 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 135 defines a signaling-agnostic framework, naming conventions and 136 logical entities required for building advanced conferencing systems. 137 The XCON Framework introduces the conference object as a logical 138 representation of a conference instance, representing the current 139 state and capabilities of a conference. 141 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 142 this document allows authenticated and authorized users to create, 143 manipulate and delete conference objects. Operations on conferences 144 include adding and removing participants, changing their roles, as 145 well as adding and removing media streams and associated end points. 147 The CCMP implements the client-server model within the XCON 148 Framework, with the Conference Control Client and Conference Control 149 Server acting as client and server, respectively. The CCMP uses HTTP 150 [RFC2616] as the protocol to transfer requests and responses, which 151 contain the domain-specific XML-encoded data objects defined in 152 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 153 for Centralized Conferencing (XCON Data Model). 155 Section 2 clarifies the conventions and terminology used in the 156 document. Section 3 provides an overview of the Conference Control 157 functionality of the XCON framework, together with a description of 158 the main targets CCMP deals with, namely conference objects and 159 conference users. A general description of the operations associated 160 with protocol messages is given in Section 4 together with 161 implementation details. Section 5 delves into the details of the 162 specific CCMP messages. A complete, not normative, example of the 163 operation of the CCMP, describing a typical call flow associated with 164 conference creation and manipulation, is provided in Section 6. A 165 survey of the methods that can be used to locate a Conference Control 166 Server is provided in Section 7, whereas Section 8 discusses 167 potential approaches to notifications management. CCMP transport 168 over HTTP is highlighted in Section 9. Security considerations are 169 presented in Section 10. Finally, Section 11 provides the XML 170 schema. 172 2. Conventions and Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 [RFC2119]. 179 In additon to the terms defined in the Framework for Centralized 180 Conferencing [RFC5239], this document uses the following terms and 181 acronyms: 183 XCON aware client: An XCON conferencing system client which is able 184 to issue CCMP requests. 186 First-Party Request: A request issued by the client to manipulate 187 their own conferencing data. 189 Third-Party Request: A request issued by a client to manipulate the 190 conference data of another client. 192 3. XCON Conference Control System Architecture 194 CCMP supports the XCON framework . Figure 1 depicts a subset of the 195 "Conferencing System Logical Decomposition" architecture from the 196 XCON framework document. It illustrates the role that CCMP assumes 197 within the overall centralized architecture. 199 ........................................................ 200 . Conferencing System . 201 . . 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 . | C O N F E R E N C E O B J E C T | | | . 208 . | | |-+ . 209 . | |-+ . 210 . +---------------------------------------+ . 211 . ^ . 212 . | . 213 . v . 214 . +-------------------+ . 215 . | Conference Control| . 216 . | Server | . 217 . +-------------------+ . 218 . ^ . 219 .........................|.............................. 220 | 221 |Centralized 222 |Conferencing 223 |Manipulation 224 |Protocol 225 | 226 .........................|.............................. 227 . V . 228 . +----------------+ . 229 . | Conference | . 230 . | Control | . 231 . | Client | . 232 . +----------------+ . 233 . . 234 . Conferencing Client . 235 ........................................................ 237 Figure 1: Conference Client Interaction 239 The Centralized Conferencing Manipulation Protocol (CCMP) allows the 240 conference control client to interface with the conference object 241 maintained by the conferencing system, as depicted in Figure 1. Note 242 that additional functionality of the Conference Control Client and 243 Conferencing System is discussed in the XCON framework and related 244 documents. 246 This section provides details of the identifiers REQUIRED to address 247 and manage the clients associated with a conferencing system using 248 the CCMP. 250 3.1. Conference Objects 252 Conference objects feature a simple dynamic inheritance-and-override 253 mechanism. Conference objects are linked into a tree known as 254 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 255 node inherits attributes from its parent node. The roots of these 256 inheritance trees are conference templates also known as 257 "blueprints". Nodes in the inheritance tree can be active 258 conferences or simply descriptions that do not currently have any 259 resources associated with them (i.e., conference reservations). An 260 object can mark certain of its properties as unalterable, so that 261 they cannot be overridden. Per the framework, a client may specify a 262 parent object (a conference or blueprint) from which to inherit 263 values when a conference is created using the Conference Control 264 Protocol. 266 Conference objects are uniquely identified by the XCON-URI within the 267 scope of the conferencing system. The XCON-URI is introduced in the 268 XCON framework and defined in the XCON common data model. 270 Conference objects are comprehensively represented through XML 271 documents compliant with the XML Schema defined in the XCON data 272 model [I-D.ietf-xcon-common-data-model]. The root element of such 273 documents, called "", is of type "conference-type". 274 It encompasses other XML elements describing different conference 275 features and users as well. Using the CCMP, conferencing clients can 276 use these XML structures to express their preferences in creating or 277 updating a conference. A conferencing server can convey conference 278 information using the XML elements back to the clients. 280 3.2. Conference Users 282 Each conference can have zero or more users. All conference 283 participants are users, but some users may have only administrative 284 functions and do not contribute or receive media. Users are added 285 one user at a time to simplify error reporting. When a conference is 286 cloned from a parent object, users are inherited as well, so that it 287 is easy to set up a conference that has the same set of participants 288 or a common administrator. The Conference Control Server creates 289 individual users, assigning them a unique Conference User Identifier 290 (XCON-USERID). The XCON-USERID as identifier of each conferencing 291 system client is introduced in the XCON framework and defined in the 292 XCON common data model. Each CCMP request, with an exception pointed 293 out in Section 5.3.6 representing the case of a user at his first 294 entrance in the system as a conference participant, must carry the 295 XCON-USERID of the requestor in the proper "confUserID" parameter. 297 The XCON-USERID acts as a pointer to the user's profile as a 298 conference actor, e.g. her signalling URI and other XCON protocol 299 URIs in general, her role (moderator, participant, observer, etc.), 300 her display text, her joining information and so on. A variety of 301 elements defined in the common element as specified 302 in the XCON data model are used to describe the users related to a 303 conference including the element, as well as each 304 element included within it. For example, it is possible to determine 305 how a specific user expects and is allowed to join a conference by 306 looking at the in : each element 307 involved in such a list represents a user and shows a "method" 308 attribute defining how the user is expected to join the conference, 309 i.e. "dial-in" for users that are allowed to dial, "dial-out" for 310 users that the conference focus will be trying to reach (with 311 "dial-in" being the default mode). If the conference is currently 312 active, dial-out users are contacted immediately; otherwise, they are 313 contacted at the start of the conference. The CCMP, acting as the 314 Conference Control Protocol, provides a means to manipulate these and 315 other kinds of user-related features. 317 As a consequence of an explicit user registration to a specific XCON 318 conferencing system, conferencing clients are usually provided 319 (besides the XCON-USERID) with log-in credentials (i.e. username and 320 password). Such credentials can be used to authenticate the XCON 321 aware client issuing CCMP requests. Thus, both username and password 322 should be carried in a CCMP request as part of the "subject" 323 parameter whenever a registered conferencing client wishes to contact 324 a CCMP server. The CCMP does not maintain user's subscriptions at 325 the conference server; hence, it does not provide any specific 326 mechanism allowing clients to register their conferencing accounts. 327 The "subject" parameter is just used for carrying authentication data 328 associated with pre-registered clients, with the specific 329 registration modality outside the scope of this document. 331 4. Protocol Overview 333 CCMP is a client-server, XML-based protocol for user creation, 334 retrieval, modification and deletion of conference objects. CCMP is 335 a stateless protocol, such that implementations can safely handle 336 transactions independently from each other. CCMP messages are XML 337 documents or XML document fragments compliant with the XCON data 338 model representation [I-D.ietf-xcon-common-data-model]. 340 Section 4.1 specifies the basic operations that can create, retrieve, 341 modify and delete conference-related information in a centralized 342 conference. The core set of objects manipulated in the CCMP includes 343 conference blueprints, the conference object, users, and sidebars. 345 Each operation in the protocol model, as summarized in Section 4.1 is 346 atomic and either succeeds or fails as a whole. The conference 347 server MUST ensure that the operations are atomic in that the 348 operation invoked by a specific conference client completes prior to 349 another client's operation on the same conference object. While the 350 details for this data locking functionality are out of scope for the 351 CCMP protocol specification and are implementation specific for a 352 conference server, some core functionality for ensuring the integrity 353 of the data is provided by the CCMP as described in Section 4.2. 355 While the XML documents that are carried in the CCMP need to comply 356 with the XCON data model, there are situations in which the values 357 for mandatory elements are unknown by the client. The mechanism for 358 ensuring compliance with the data model in these cases is described 359 in Section 4.3. 361 CCMP is completely independent from underlying protocols, which means 362 that there can be different ways to carry CCMP messages from a 363 conferencing client to a conferencing server. The specification 364 describes the use of HTTP as a transport solution, including CCMP 365 requests in HTTP POST messages and CCMP responses in HTTP 200 OK 366 replies. This implementation approach is further described in 367 Section 4.4. 369 4.1. Protocol Operations 371 The main operations provided by CCMP belong in four general 372 categories: 374 create: for the creation of a conference object, a conference user, 375 a sidebar, or a blueprint. 377 retrieve: to get information about the current state of either a 378 conference object (be it an actual conference or a blueprint, or a 379 sidebar) or a conference user. A retrieve operation can also be 380 used to obtain the XCON-URIs of the current conferences (active or 381 registered) handled by the conferencing server and/or the 382 available blueprints. 384 update: to modify the current features of a specified conference or 385 conference user. 387 delete: to remove from the system a conference object or a 388 conference user. 390 Thus, the main targets of CCMP operations are: 392 o conference objects associated with either active or registered 393 conferences, 395 o conference objects associated with blueprints, 397 o conference objects associated with sidebars, both embedded in the 398 main conference (i.e. elements in ) and 399 external to it (i.e. whose xcon-uris are included in the 400 elements of ), 402 o elements associated with conference users, 404 o the list of XCON-URIs related to conferences and blueprints 405 available at the server, for which only retrieval operations are 406 allowed. 408 4.2. Data Management 410 The XCON Framework defines a model whereby the conference server 411 centralizes and maintains the conference information. Since multiple 412 clients can modify the same conference objects a conference client 413 might not have the latest version of a specific conference object 414 when they initiate operations. To determine whether the client has 415 the most up to date conference information, a versioning approach is 416 defined for the CCMP. Each conference object is associated with a 417 version number. All CCMP response messages containing a conference 418 document (or a fragment thereof) MUST contain a "version" parameter. 419 When a client sends an update message to the server, which includes 420 modifications to a conference object, if the modifications are all 421 successfully applied, the server MUST return a "200" response 422 containing the version number of the modified object. With this 423 approach, a client working on version "X" of a conference object that 424 receives a "200" response with a version number which is "X+1" can be 425 certain that the version it manipulated was the most up to date. 426 However, if the "200" response contains a version which is at least 427 "X+2", the client knows that the object modified by the server was 428 more up to date than the object the client was manipulating. In 429 order to ensure that the client always has the latest version of the 430 modified object, the client can send a "retrieve" request to the 431 conference server. The client can then update the relevant data 432 elements in the conference object prior to invoking a specific 433 operation. Note that a client subscribed to the XCON event package 434 [I-D.ietf-xcon-event-package] notifications about conference object 435 modifications, will receive the most up to date version of that 436 object upon receipt of a notification. 438 The "version" parameter is OPTIONAL for requests, since it is not 439 needed by the server: as long as the required modifications can be 440 applied to the target conference object without conflicts, the server 441 does not care whether the client has stored an up to date view of the 442 information. In addition, to ensure the integrity of the data, the 443 conference server first checks all the parameters, before making any 444 changes to the internal representation of the conference object. For 445 example, it would be undesirable to change the of the 446 conference, but then detect an invalid URI in one of the and abort the remaining updates. 449 4.3. Data Model Compliance 451 The XCON data model [I-D.ietf-xcon-common-data-model] identifies some 452 elements/attributes as mandatory. Since the XML documents carried in 453 the body of the CCMP requests/responses need to be compliant with the 454 XCON data model, there can be a problem in cases of client-initiated 455 operations, such as the initial creation of conference objects and 456 cases whereby a client updates a conference object adding new 457 elements, such as a new user. In such cases, not all of the 458 mandatory data can be known in advance to the client issuing a CCMP 459 request. As an example, a client has no means to know, at the time 460 it issues a conference creation request, the XCON-URI that the server 461 will assign to the yet-to-be-created conference and hence it is not 462 able to appropriately fill with that value the mandatory "entity" 463 attribute of the conference document contained in the request. To 464 solve this issue, the CCMP client fills all mandatory data model 465 fields, for which no value is available at the time the request is 466 constructed, with fake values in the form of a wildcard string, 467 AUTO_GENERATE_X (all uppercase), with X being a unique numeric index 468 for each data model field for which the value is unknown. This form 469 of wildcard string is chosen, rather than the use of random unique 470 strings (e.g, FOO_BAR_LA) or non-numeric values for X, to simplify 471 processing at the server. The values of AUTO_GENERATE_X are only 472 unique within the context of the specific request. The fake 473 AUTO_GENERATE_X values MUST be within the value part of an attribute/ 474 element (e.g., ). 477 When the server receives requests containing values in the form of 478 AUTO_GENERATE_X, the server does the following: 480 (a) Generates the proper identifier for each instance of 481 AUTO_GENERATE_X in the document. If an instance of 482 AUTO_GENERATE_X is not within the value part of the attribute/ 483 element, the server MUST respond with an error of 400 Bad 484 Request. In cases where AUTO_GENERATE_X appears only in the 485 user part of a URI (i.e., in the case of XCON-USERIDs or XCON- 486 URIs), the server needs to ensure that the domain name is one 487 that is within the server's domain of responsibility. If the 488 domain name is not within the server's domain of responsibility, 489 then the server MUST return a 427 Invalid Domain Name. The 490 server MUST replace each instance of a specific wildcard field 491 (e.g., AUTO_GENERATE_1) with the same identifier. The 492 identifiers MUST be unique for each instance of AUTO_GENERATE_X 493 within the same XML document received in the request - e.g., the 494 value that replaces AUTO_GENERATE_1 MUST NOT be the same as the 495 value that replaces AUTO_GENERATE_2. Note that the values that 496 replace the instances of AUTO_GENERATE_X are not the same across 497 all conference objects - e.g., different values can be used to 498 replace AUTO_GENERATE_1 in two different documents. 500 (b) Sends a response in which all values of AUTO_GENERATE_X received 501 in the request have been replaced by the newly created one(s). 503 With this approach compatibility with the data model requirements is 504 maintained, while allowing for client-initiated manipulation of 505 conference objects at the server's side. Note that the use of this 506 mechanism could be avoided in come cases by using multiple 507 operations, such as creating a new user and then adding the new user 508 to an existing conference. However, the AUTO_GENERATE_X mechanism 509 allows a single operation to be used to effect the same change on the 510 conference object. 512 4.4. Implementation Approach 514 CCMP is implemented using HTTP, placing the CCMP request messages 515 into the body of an HTTP POST operation and placing the CCMP 516 responses into the body of the HTTP response messages. A non- 517 exhaustive summary of the other approaches that were considered and 518 the perceived advantages of the HTTP solution described in this 519 document are provided in Appendix A. 521 Most CCMP commands can pend indefinitely, thus increasing the 522 potential that pending requests can continue to increase when a 523 server is receiving more requests than it can process within a 524 specific time period. In this case a server SHOULD return a 510 525 response code to the pending requests. In addition, to mitigate the 526 situation clients MUST NOT wait indefinitely for a response and MUST 527 implement a timer such that when it expires, the client MUST close 528 the connection. Thirty seconds is RECOMMENDED as the default value 529 for this timer. Sixty seconds is considered a reasonable upper 530 range. Note, that there may be cases where a response message is 531 lost and a request has been successful (e.g., user added to a 532 conference), yet the client will be unaware and close the connection. 533 However, as described in Section 4.2, there is a versioning mechanism 534 for the conference objects, thus there is a mechanism for the 535 conference object stored by the client to be brought up to date. 537 CCMP messages have a MIME-type of "application/ccmp+xml", which 538 appears inside the "Content-Type" and "Accept" fields of HTTP 539 requests and responses. The XML documents in the CCMP messages MUST 540 be encoded in UTF-8. This specification follows the recommendations 541 and conventions described in [RFC3023], including the naming 542 convention of the type ('+xml' suffix) and the usage of the 'charset' 543 parameter. The 'charset' parameter MUST be included with the XML 544 document. Section 9 provides the complete requirements for an HTTP 545 implementation to support the CCMP. 547 5. CCMP messages 549 CCMP messages are either requests or responses. The general CCMP 550 request message is defined in Section 5.1. The general CCMP response 551 message is defined in Section 5.2. The details of the specific 552 message type which is carried in the CCMP request and response 553 messages are described in Section 5.3. CCMP response codes are 554 listed in Section 5.4 556 5.1. CCMP Request Message Type 558 A CCMP request message is comprised of the following parameters: 560 subject: An OPTIONAL parameter containing username and password of 561 the client registered at the conferencing system. Each user who 562 subscribes to the conferencing system is assumed to be equipped 563 with those credentials and SHOULD enclose them in each CCMP 564 request she issues. These fields can be used to control that the 565 user sending the CCMP request has the authority to perform the 566 entailed operation. The same fields can also be exploited to 567 carry out other authorization and authentication procedures. 569 confUserID: An OPTIONAL parameter containing the XCON-USERID of the 570 client. The XCON-USERID is used to identify any conferencing 571 client within the context of the conferencing system and it is 572 assigned by the conferencing server at each conferencing client 573 who interacts with it. The "confUserID" parameter is REQUIRED in 574 the CCMP request and response messages with the exception of the 575 case of a user who has no XCON-USERID and who wants to enter, via 576 CCMP, a conference whose identifier is known. In such case, a 577 side-effect of the request is that the user is provided with an 578 appropriate XCON-USERID. An example of the above mentioned case 579 will be provided in Section 5.3.6. 581 confObjID: An OPTIONAL parameter containing the XCON-URI of the 582 target conference object. 584 operation: An OPTIONAL parameter refining the type of specialized 585 request message. The "operation" parameter is REQUIRED in all 586 requests except for the "blueprintsRequest" and "confsRequest" 587 specialized messages. 589 conference-password: An OPTIONAL parameter that MUST be inserted in 590 all requests whose target conference object is password-protected 591 (as per the element in 592 [I-D.ietf-xcon-common-data-model]). A CCMP response code of "423" 593 MUST be returned if a conference-password is not included in the 594 request when required. 596 specialized request message: This is specialization of the generic 597 request message (e.g., blueprintsRequest), containing parameters 598 that are dependent on the specific request sent to the server. A 599 specialized request message MUST be included in the CCMP request 600 message. The details for the specialized messages and associated 601 parameters are provided in Section 5.3. 603 605 607 609 610 611 613 614 616 618 620 621 623 625 627 629 631 633 634 635 637 Figure 2: Structure of CCMP Request messages 639 5.2. CCMP Response Message Type 641 A CCMP response message is comprised of the following parameters: 643 confUserID: A REQUIRED parameter in CCMP response messages 644 containing the XCON-USERID of the conferencing client who issued 645 the CCMP request message. 647 confObjID: An OPTIONAL parameter containing the XCON-URI of the 648 target conference object. 650 operation: An OPTIONAL parameter for CCMP response messages. This 651 parameter is REQUIRED in all responses except for the 652 "blueprintsResponse" and "confsResponse" specialized messages. 654 response-code: A REQUIRED parameter containing the response code 655 associated with the request. The response code MUST be chosen 656 from the codes listed in Section 5.4. 658 response-string: An OPTIONAL reason string associated with the 659 response. In case of an error, in particular, this string can be 660 used to provide the client with detailed information about the 661 error itself. 663 version: An OPTIONAL parameter reflecting the current version number 664 of the conference object referred by the confObjID. This number 665 is contained in the "version" attribute of the 666 element related to that conference. This parameter is REQUIRED in 667 CCMP response messages and SHOULD NOT be included in CCMP request 668 messages. 670 specialized response message: This is specialization of the generic 671 response message, containing parameters that are dependent on the 672 specific request sent to the server (e.g., blueprintsResponse). A 673 specialized response message SHOULD be included in the CCMP 674 response message, except in an error situation where the CCMP 675 request message did not contain a valid specialized message. In 676 this case, the conference server MUST return a "response-code" of 677 "400". The details for the specialized messages and associated 678 parameters are provided in Section 5.3. 680 682 684 686 687 688 690 691 693 695 697 698 700 702 704 707 709 711 713 714 715 717 Figure 3: Structure of CCMP Response message 719 5.3. Detailed messages 721 Based on the request and response message structures described in 722 Section 5.1 and Section 5.2, the following summarizes the specialized 723 CCMP request/response types described in this document: 725 1. blueprintsRequest/blueprintsResponse 727 2. confsRequest/confsResponse 729 3. blueprintRequest/blueprintResponse 731 4. confRequest/confResponse 733 5. usersRequest/usersResponse 735 6. userRequest/userResponse 737 7. sidebarsByValRequest/sidebarsByValResponse 739 8. sidebarsByRefRequest/sidebarsByRefResponse 741 9. sidebarByValRequest/sidebarByValResponse 743 10. sidebarByRefRequest/sidebarByRefResponse 745 11. extendedRequest/extendedResponse 747 12. optionsRequest/optionsResponse 749 These CCMP request/response pairs use the fundamental CCMP operations 750 as defined in Section 4.1 to manipulate the conference data. These 751 request/response pairs are included in an IANA registry as defined in 752 Section 12.5. Table 1 summarizes the remaining CCMP operations and 753 corresponding actions that are valid for a specific CCMP request 754 type, noting that neither the blueprintsRequest/blueprintsResponse 755 nor confsRequest/confsResponse require an "operation" parameter. The 756 corresponding response MUST contain the same operation. Note that 757 some entries are labeled "N/A" indicating the operation is invalid 758 for that request type. In the case of an "N/A*", the operation MAY 759 be allowed for specific privileged users or system administrators, 760 but is not part of the functionality included in this document. 762 +---------------+------------+------------+------------+------------+ 763 | Operation | Retrieve | Create | Update | Delete | 764 | ------------- | | | | | 765 | Request Type | | | | | 766 +---------------+------------+------------+------------+------------+ 767 | blueprints | Get list | N/A | N/A | N/A | 768 | Request | of | | | | 769 | | blueprints | | | | 770 | ------------- | ---------- | ---------- | ---------- | ---------- | 771 | blueprint | Get | N/A* | N/A* | N/A* | 772 | Request | blueprint | | | | 773 | ------------- | ---------- | ---------- | ---------- | ---------- | 774 | confsRequest | Get list | N/A | N/A | N/A | 775 | | of confs | | | | 776 | ------------- | ---------- | ---------- | ---------- | ---------- | 777 | confRequest | Gets | Creates | Changes | Deletes | 778 | | conference | conference | conference | conference | 779 | | object | object | object | object | 780 | ------------- | ---------- | ---------- | ---------- | ---------- | 781 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 782 | | | | | | 783 | ------------- | ---------- | ---------- | ---------- | ---------- | 784 | userRequest | Gets | Adds a | Changes | Deletes | 785 | | specified | to | specified | specified | 786 | | | a conf | | | 787 | | | (***) | | | 788 | ------------- | ---------- | ---------- | ---------- | ---------- | 789 | sidebarsByVal | Gets | N/A | N/A | N/A | 790 | Request | | | | | 792 | ------------- | ---------- | ---------- | ---------- | ---------- | 793 | sidebarsByRef | Gets | N/A | N/A | N/A | 794 | Request | | | | | 796 | ------------- | ---------- | ---------- | ---------- | ---------- | 797 | sidebarByVal | Gets | Creates | Changes | Deletes | 798 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 799 | | by-val | by-val | by-val | by-val | 800 | ------------- | ---------- | ---------- | ---------- | ---------- | 801 | sidebarByRef | Gets | Creates | Changes | Deletes | 802 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 803 | | by-ref | by-ref | by-ref | by-ref | 804 +---------------+------------+------------+------------+------------+ 806 Table 1: Request Type Operation Specific Processing 808 (**): These operations are not allowed for a usersRequest message, 809 since the section, which is the target element of such a 810 request, is created and removed in conjuntcion with, respectively, 811 the creation and deletion of the associated conference document. 812 Thus, "update" and "retrieve" are the only semantically correct 813 operations for such message. 815 (***): This operation can involve the creation of an XCON-USERID, if 816 the sender does not add it in the "confUserID" parameter, and/or if 817 the "entity" field of the "userInfo" parameter is void. 819 Additional parameters included in the specialized CCMP request/ 820 response messages are detailed in the subsequent sections. If a 821 required parameter is not included in a request, the conference 822 server MUST return a 400 response code per Section 5.4. 824 5.3.1. blueprintsRequest and blueprintsResponse 826 A "blueprintsRequest" (Figure 4) message is sent to request the list 827 of XCON-URIs associated with the available blueprints from the 828 conference server. These XCON-URIs can be subsequently used by the 829 client to access detailed information about a specified blueprint 830 with a specific blueprintRequest message per Section 5.3.3. 832 The "confUserID" parameter MUST be included in every 833 blueprintsRequest/Response message and reflect the XCON-USERID of the 834 conferencing client issuing the request. Since a blueprintsRequest 835 message is not targetted to a specific conference instance and is a 836 "retrieve-only" request, the "confObjID" and "operation" MUST NOT be 837 included in the blueprintsRequest/Response messages. 839 In order to obtain a specific subset of the available blueprints, a 840 client may specify a selection filter providing an appropriate xpath 841 query in the OPTIONAL "xpathFilter" parameter of the request. The 842 information in the blueprints typically represents general 843 capabilities and characteristics. For example, to select blueprints 844 having both audio and video stream support, a possible xpathFilter 845 value could be: "/conference-info[conference-description/ 846 available-media/entry/type='audio' and conference-description/ 847 available-media/entry/type='video']". A conference server SHOULD NOT 848 provide any sensitive information (e.g., passwords) in the 849 blueprints. 851 The associated "blueprintsResponse" message SHOULD contain, as shown 852 in Figure 4, a "blueprintsInfo" parameter containing the above 853 mentioned XCON-URI list. 855 856 857 858 859 860 861 862 863 864 866 868 870 871 872 873 875 876 877 879 881 882 883 884 885 886 887 888 889 891 893 895 896 897 899 901 902 903 904 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 905 messages 907 5.3.2. confsRequest and confsResponse 909 A "confsRequest" message is used to retrieve, from the server, the 910 list of XCON-URIs associated with active and registered conferences 911 currently handled by the conferencing system. The "confUserID" 912 parameter MUST be included in every confsRequest/Response message and 913 reflect the XCON-USERID of the conferencing client issuing the 914 request. The "confObjID" parameter MUST NOT be included in the 915 confsRequest message. The "confsRequest" message is of a "retrieve- 916 only" type, since the sole purpose is to collect information 917 available at the conference server. Thus, an "operation" parameter 918 MUST NOT be included in a "confsRequest" message. In order to 919 retrieve a specific subset of the available conferences, a client may 920 specify a selection filter providing an appropriate xpath query in 921 the OPTIONAL "xpathFilter" parameter of the request. For example, to 922 select only the registered conferences, a possible xpathFilter value 923 could be: "/conference-info[conference-description/conference-state/ 924 active='false']". The associated "confsResponse" message SHOULD 925 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 926 upon receipt of the response message, can interact with the available 927 conference objects through further CCMP messages. 929 931 932 933 934 935 936 937 938 939 941 943 945 946 947 948 950 951 952 954 956 957 958 959 960 961 962 963 964 966 968 970 971 972 974 976 977 978 980 Figure 5: Structure of the confsRequest and confsResponse messages 982 5.3.3. blueprintRequest and blueprintResponse 984 Through a "blueprintRequest", a client can manipulate the conference 985 object associated with a specified blueprint. Further than the 986 "confUserID" parameter, the request MUST include the "confObjID" and 987 the "operation" one. Again, the "confUserID" parameter MUST be 988 included in every blueprintRequest/Response message and reflect the 989 XCON-USERID of the conferencing client issuing the request. The 990 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 991 which might have been previously retrieved through a 992 "blueprintsRequest" message. 994 The blueprintRequest message SHOULD NOT contain an "operation" 995 parameter other than "retrieve". The "create", "update" and "delete" 996 operations SHOULD NOT be included in a "blueprintRequest" message 997 except in the case of privileged users (e.g. the conference server 998 administration staff), who might authenticate themselves by the mean 999 of the "subject" request parameter. 1001 A blueprintRequest/retrieve carrying a "confObjID" which is not 1002 associated with one of the available system's blueprints will 1003 generate, on the server's side, a blueprintResponse message 1004 containing a "404" error code. This holds also for the case in which 1005 the mentioned "confObjID" is related to an existing conference 1006 document stored at the server, but associated with an actual 1007 conference (be it active or registered) or with a sidebar rather than 1008 a blueprint. 1010 In the case of "response-code" of "200" for a "retrieve" operation, 1011 the "blueprintInfo" parameter MUST be included in the 1012 "blueprintResponse" message. The "blueprintInfo" parameter contains 1013 the conference document associated with the blueprint as identified 1014 by the "confObjID" parameter specified in the blueprintRequest. 1016 1018 1019 1020 1021 1022 1023 1024 1025 1026 1028 1030 1032 1033 1034 1036 1038 1039 1040 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1053 1055 1057 1058 1059 1061 1063 1064 1065 1067 Figure 6: Structure of the blueprintRequest and blueprintResponse 1068 messages 1070 5.3.4. confRequest and confResponse 1072 With a "confRequest" message, CCMP clients can manipulate conference 1073 objects associated with either active or registered conferences. The 1074 "confUserID" parameter MUST be included in every confRequest/Response 1075 message and reflect the XCON-USERID of the conferencing client 1076 issuing the request. ConfRequest and confResponse messages MUST also 1077 include an "operation" parameter. ConfResponse messages MUST return 1078 to the requestor a "response-code" and MAY contain a "response- 1079 string" explaining it. Depending upon the type of "operation", a 1080 "confObjID" and "confInfo" parameter MAY be included in the 1081 confRequest and response. The requirements for inclusion of 1082 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1083 messages and are detailed below for each "operation" case. 1085 The creation case deserves care. To create a new conference through 1086 a "confRequest" message, two approaches can be considered: 1088 1. Creation through explicit cloning: the "confObjID" parameter MUST 1089 contain the XCON-URI of the blueprint or of the conference to be 1090 cloned, while the "confInfo" parameter MUST NOT be included in 1091 the confRequest. Note that cloning of an active conference is 1092 only done in the case of a sidebar operation per the XCON 1093 framework and as described in Section 5.3.8. 1095 2. Creation through implicit cloning (also known as "direct 1096 creation"): the "confObjID" parameter MUST NOT be included in the 1097 request and the CCMP client can describe the desired conference 1098 to be created using the "confInfo" parameter. If no "confInfo" 1099 parameter is provided in the request, the new conference will be 1100 created as a clone of the system default blueprint. 1102 In both creation cases, the confResponse, for a successful completion 1103 of a "create" operation, contains a response-code of "200" and MUST 1104 contain the XCON-URI of the newly created conference in the 1105 "confObjID" parameter, in order to allow the conferencing client to 1106 manipulate that conference through following CCMP requests. In 1107 addition, the "confInfo" parameter transporting the created 1108 conference document MAY be included, at the discretion of the 1109 conferencing system implementation, along with the REQUIRED "version" 1110 parameter initialized at "1", since at creation time the conference 1111 object is at its first version. 1113 In the case of a confRequest with a "retrieve" operation, the 1114 "confObjID" representing the XCON-URI of the target conference MUST 1115 be included and the "confInfo" parameter MUST NOT be included in the 1116 request. The conferencing server MUST ignore any "confInfo" 1117 parameter that is received in a confRequest/retrieve. If the 1118 confResponse for the "retrieve" operation contains a "response-code" 1119 of "200", the "confInfo" parameter MUST be included in the response. 1120 The "confInfo" parameter MUST contain the entire conference document 1121 describing the target conference object in its current state. The 1122 current state of the retrieved conference object MUST also be 1123 reported in the proper "version" response parameter. 1125 In case of a confRequest with an "update" operation, the "confInfo" 1126 and "confObjID" MUST be included in the request. The "confInfo" 1127 represents an object of type "conference-type" containing all the 1128 changes to be applied to the conference whose identifier is 1129 "confObjID". Note that, in such a case, though the confInfo 1130 parameter has indeed to follow the rules indicated in the XCON data 1131 model, it does not represent the entire updated version of the target 1132 conference, since it rather conveys just the modifications to apply 1133 to that conference. For example, in order to change the conference 1134 title, the confInfo parameter will be of the form: 1136 1137 1138 *** NEW CONFERENCE TITLE *** 1139 1140 1142 Figure 7: Updating a conference object: modifying the title of a 1143 conference 1145 Similarly, to remove the title of an existing conference, a 1146 confRequest/update carrying the following "confInfo" parameter would 1147 do the job.: 1149 1150 1151 1152 1153 1155 Figure 8: Updating a conference object: removing the title of a 1156 conference 1158 In the case of a confResponse/update with a response-code of "200", 1159 no additional information is REQUIRED in the response message, which 1160 means the return of confInfo parameter is OPTIONAL. A subsequent 1161 confRequest/retrieve transaction might provide the CCMP client with 1162 the current aspect of the conference upon the modification, or the 1163 Notification Protocol might address that task as well. A "200" 1164 response-code indicates that the conference object has been changed 1165 accordingly to the request by the conferencing server. The "version" 1166 parameter MUST be enclosed in the confResponse/update message, in 1167 order to let the client understand what is the actual current 1168 conference-object version, upon the applied modifications. An "409" 1169 response-code indicates that the changes reflected in the request 1170 "confInfo" are not feasible. This could be due to policies, 1171 requestor roles, specific privileges, unacceptable values etc., with 1172 the reason specific to a conferencing system and its configuration. 1173 Together with the "409" response-code, the "version" parameter MUST 1174 be attached in the confResponse/update, by this way allowing the 1175 client to eventually retrieve the current version of the target 1176 conference if the one she attempted to modify was not the most up-to- 1177 date. 1179 In the case of a confRequest with a "delete" operation, the 1180 "confObjID" representing the XCON-URI of the target conference MUST 1181 be included while the "confInfo" MUST NOT be included in the request. 1182 The conferencing server MUST ignore any "confInfo" parameter that is 1183 received within such a request. The confResponse MUST contain the 1184 same "confObjID" that was included in the confRequest. If the 1185 confResponse/delete operation contains a "200" response-code, the 1186 conference indicated in the "confObjID" has been successfully 1187 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1188 parameter. The "version" parameter SHOULD NOT be returned in any 1189 confResponse/delete. If the conferencing server cannot delete the 1190 conference referenced by the "confObjID" received in the confRequest 1191 because it is the parent of another conference object that is in use, 1192 the conferencing server MUST return a response-code of "425". 1194 A confRequest with an "operation" of "retrieve", "update" or "delete" 1195 carrying a "confObjID" which is not associated with one of the 1196 conferences (active or registered) the system is holding will 1197 generate, on the server's side, a confResponse message containing a 1198 "404" error code. This holds also for the case in which the 1199 mentioned "confObjID" is related to an existing conference object 1200 stored at the server, but associated with a blueprint or with a 1201 sidebar rather than an actual conference. 1203 The schema for the confRequest/confResponse pair is shown in 1204 Figure 9. 1206 1208 1209 1210 1211 1212 1213 1214 1215 1216 1218 1220 1222 1223 1224 1226 1228 1229 1230 1232 1234 1235 1236 1237 1238 1239 1240 1241 1242 1244 1246 1248 1249 1250 1252 1254 1255 1256 1258 Figure 9: Structure of the confRequest and confResponse messages 1260 5.3.5. usersRequest and usersResponse 1262 The "usersRequest" message allows a client to manipulate the 1263 element of the conference object represented by the "confObjID". The 1264 element contains the list of elements associated with 1265 conference participants, the list of the users to which access to the 1266 conference is allowed/denied, conference participation policies, etc. 1267 The "confObjID" MUST be included in a "usersRequest" message. 1269 A "usersInfo" parameter MAY be included in a usersRequest message 1270 depending upon the operation. If the "usersInfo" parameter is 1271 included in the usersRequest message, the parameter MUST be compliant 1272 with the field of the XCON data model. 1274 Two operations are allowed for a "usersRequest" message: 1276 1. "retrieve": In this case the request MUST NOT include a 1277 "usersInfo" parameter, while the successful response MUST contain 1278 the desired element in the "usersInfo" parameter. The 1279 conference server MUST ignore a "usersInfo" parameter if it is 1280 received in a request with a "retrieve" operation. 1282 2. update: In this case, the "usersInfo" parameter MUST contain the 1283 modifications to be applied to the referred element. If 1284 the "response-code" is "200", then the "usersInfo" parameter 1285 SHOULD NOT be returned. Any "usersInfo" parameter that is 1286 returned SHOULD be ignored. A "response-code" of "426" indicates 1287 that the conferencing client is not allowed to make the changes 1288 reflected in the "usersInfo" contained in the usersRequest 1289 message. This could be due to policies, roles, specific 1290 privileges, etc., with the reason specific to a conferencing 1291 system and its configuration. 1293 Operations of "create" and "delete" are not applicable to a 1294 usersRequest message and MUST NOT be considered by the server, which 1295 means that a "response-code" of "403" MUST be included in the 1296 usersResponse message. 1298 1300 1301 1302 1303 1304 1305 1306 1307 1308 1310 1312 1314 1315 1316 1318 1320 1321 1322 1324 1326 1327 1328 1329 1330 1331 1332 1333 1334 1336 1338 1340 1341 1342 1344 1346 1347 1348 1350 Figure 10: Structure of the usersRequest and usersResponse messages 1352 5.3.6. userRequest and userResponse 1354 A "userRequest" message is used to manipulate elements inside 1355 a conference document associated with a conference identified by the 1356 "confObjID" parameter. Besides retrieving information about a 1357 specific conference user, the message is used to request that the 1358 conference server either create, modify, or delete information about 1359 a user. A "userRequest" message MUST include the "confObjID", the 1360 "operation" parameter, and MAY include a "userInfo" parameter 1361 containing the detailed user's information depending upon the 1362 operation and whether the "userInfo" has already been populated for a 1363 specific user. Note that a user may not necessarily be a 1364 conferencing control client (i.e., some participants in a conference 1365 are not "XCON aware"). 1367 An XCON-USERID SHOULD be assigned to each and every user subscribed 1368 to the system. In such a way, a user who is not a conference 1369 participant can make requests (provided she has successfully passed 1370 authorization and authentication checks), like creating a conference, 1371 retrieving conference information, etc.. 1373 Conference users can be created in a number of different ways. In 1374 each of these cases the operation MUST be set to "create" in the 1375 userRequest message. Each of the userResponse messages for these 1376 cases MUST include the "confObjID", "confUserID", "operation" and 1377 "response-code" parameters. In the case of a response code of "200", 1378 the userResponse message MAY include the "userInfo" parameter 1379 depending upon the manner in which the user was created: 1381 o Conferencing client with an XCON-USERID adds itself to the 1382 conference: In this case, the "userInfo" parameter MAY be included 1383 in the userRequest. The "userInfo" parameter MUST contain a 1384 element (compliant with the XCON data model) and the 1385 "entity" attribute MUST be set to a value which represents the 1386 XCON-USERID of the user initiating the request. No additional 1387 parameters beyond those previously described are required in the 1388 userResponse message, in the case of a "response-code" of "200". 1390 o Conferencing client acts on behalf of a third user whose XCON- 1391 USERID is known: in this case, the "userInfo" parameter MUST be 1392 included in the userRequest. The "userInfo" parameter MUST 1393 contain a element and the "entity" attribute value MUST be 1394 set to the XCON-USERID of the third user in question. No 1395 additional parameters beyond those previously described are 1396 required in the userResponse message, in the case of a "response- 1397 code" of "200". 1399 o A conferencing client who has no XCON-USERID and who wants to 1400 enter, via CCMP, a conference whose identifier is known. In this 1401 case, a side-effect of the request is that the user is provided 1402 with a new XCON-USERID (created by the server) carried inside the 1403 "confUserID" parameter of the response. This is the only case in 1404 which a CCMP request can be valid though carrying a void 1405 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1406 in the request, providing at least a contact URI of the joining 1407 client, in order to let the focus instigate the signaling phase 1408 needed to add her to the conference. The mandatory "entity" 1409 attribute of the "userInfo" parameter in the request MUST be 1410 filled with a fake value with the user part of the XCON-USERID 1411 containing a value of AUTO_GENERATE_X as described in Section 4.3, 1412 to conform to the rules contained in the XCON data model XML 1413 schema. The messages (userRequest and userResponse) in this case 1414 should look like the following: 1416 Request fields: 1418 confUserID=null; 1419 confObjID=confXYZ; 1420 operation=create; 1421 userInfo= 1423 1424 1425 ... 1427 Response fields (in case of success): 1429 confUserID=user345; 1430 confObjID=confXYZ; 1431 operation=create; 1432 response-code=200; 1433 userInfo=null; //or the entire userInfo object 1435 Figure 11: userRequest and userResponse in the absence of an xcon- 1436 userid 1438 o Conferencing client is unaware of the XCON-USERID of a third user: 1439 In this case, the XCON-USERID in the request "confUserID" is the 1440 sender's one and the "entity" attribute of the attached userInfo 1441 is filled with the fake value 1442 "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for 1443 the third user MUST be returned to the client issuing the request 1444 in the "entity" attribute of the response "userInfo" parameter, if 1445 the "response-code" is "200". This scenario is intended to 1446 support both the case where a brand new conferencing system user 1447 is added to a conference by a third party (i.e. a user who is not 1448 yet provided with an XCON-USERID) and the case where the CCMP 1449 client issuing the request does not know the to-be-added user's 1450 XCON-USERID (which means such an identifier could already exist on 1451 the server's side for that user). In this last case, the 1452 conferencing server is in charge of avoiding XCON-URI duplicates 1453 for the same conferencing client, looking at key fields in the 1454 request provided "userInfo" parameter, such as the signalling URI: 1455 if the joining user is a brand new one, then the generation of a 1456 new XCON identifier is needed; otherwise, if that user is an 1457 existing one, the server must recover the corresponding XCON 1458 identifier. 1460 In the case of a userRequest with a "retrieve" operation, the 1461 "confObjID" representing the XCON-URI of the target conference MUST 1462 be included. The "confUserID", containing the CCMP client's xcon- 1463 userid, MUST also be included in the userRequest message. If the 1464 client wants to retrieve information about her profile in the 1465 specified conference, no "userInfo" parameter is needed in the 1466 retrieve request. On the other hand, if the client wants to obtain 1467 someone else's info within the given conference, she MUST include in 1468 the userRequest/retrieve a "userInfo" parameter whose "entity" 1469 attribute conveys the desired user's xcon-userid. If the 1470 userResponse for the "retrieve" operation contains a "response-code" 1471 of "200", the "userInfo" parameter MUST be included in the response. 1473 In case of a userRequest with an "update" operation, the "confObjID", 1474 "confUserID" and "userInfo" MUST be included in the request. The 1475 "userInfo" is of type "user-type" and contains all the changes to be 1476 applied to a specific element in the conference object 1477 identified by the "confObjID" in the userRequest message. The user 1478 to be modified is identified through the "entity" attribute of the 1479 "userInfo" parameter included in the request. In the case of a 1480 userResponse with a "response-code" of "200", no additional 1481 information is required in the "userResponse" message. A "response- 1482 code" of "200" indicates that the referenced user element has been 1483 updated by the conference server. A "response-code" of "426" 1484 indicates that the conferencing client is not allowed to make the 1485 changes reflected in the "userInfo" in the initial request. This 1486 could be due to policies, roles, specific privileges, etc., with the 1487 reason specific to a conferencing system and its configuration. 1489 In the case of a userRequest with a "delete" operation, the 1490 "confObjID" representing the XCON-URI of the target conference MUST 1491 be included. The "confUserID", containing the CCMP client's xcon- 1492 userid, MUST be included in the userRequest message. If the client 1493 wants to exit the specified conference, no "userInfo" parameter is 1494 needed in the delete request. On the other hand, if the client wants 1495 to remove another participant from the given conference, she MUST 1496 include in the userRequest/delete a "userInfo" parameter whose 1497 "entity" attribute conveys the xcon-userid of that participant. The 1498 userResponse MUST contain the same "confObjID" that was included in 1499 the userRequest. The userResponse MUST contain a "response-code" of 1500 "200" if the target element has been successfully deleted. If 1501 the userResponse for the "delete" operation contains a "response- 1502 code" of "200", the userResponse MUST NOT contain the "userInfo" 1503 parameter. 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1516 1518 1520 1521 1522 1524 1526 1527 1528 1530 1532 1533 1534 1535 1536 1537 1538 1539 1540 1542 1544 1546 1547 1548 1550 1552 1553 1555 1557 Figure 12: Structure of the userRequest and userResponse messages 1559 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1561 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1562 on the field of the conference object represented 1563 by the "confObjID". The "sidebarsByValRequest" message is of a 1564 "retrieve-only" type, so an "operation" parameter MUST NOT be 1565 included in a "sidebarsByValRequest" message. As with blueprints and 1566 conferences, also with sidebars, CCMP allows for the use of xpath 1567 filters whenever a selected subset of the sidebars available at the 1568 server's side has to be retrieved by the client. This applies both 1569 to sidebars by reference and to sidebars by value. A 1570 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1571 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1573 the client a "version" element related to the current version of the 1574 main conference object (i.e. the one whose identifier is contained in 1575 the "confObjId" field of the request) to which the sidebars in 1576 question are associated. The "sidebarsByValInfo" parameter contains 1577 the list of the conference objects associated with the sidebars by 1578 value derived from the main conference. The retrieved sidebars can 1579 then be updated or deleted using the "sidebarByValRequest" message, 1580 which is described in Section 5.3.8. 1582 1584 1585 1586 1587 1588 1589 1590 1591 1592 1594 1596 1599 1600 1601 1602 1604 1605 1606 1608 1610 1611 1612 1613 1614 1615 1616 1617 1618 1620 1622 1625 1626 1627 1629 1631 1632 1633 1635 Figure 13: Structure of the sidebarsByValRequest and 1636 sidebarsByValResponse messages 1638 5.3.8. sidebarByValRequest and sidebarByValResponse 1640 A sidebarByValRequest message MUST contain the "operation" parameter 1641 which discriminates among retrieval, creation, modification and 1642 deletion of a specific sidebar. The other required parameters depend 1643 upon the type of operation. 1645 In the case of a "create" operation, the "confObjID" parameter MUST 1646 be included in the sidebyValRequest message. In this case, the 1647 "confObjID" parameter contains the XCON-URI of the main conference in 1648 which the sidebar has to be created. If no "sidebarByValInfo" 1649 parameter is included, as envisaged in the XCON framework 1650 ([RFC5239]), the sidebar is created by cloning the main conference, 1651 following the implementation specific cloning rules. Otherwise, 1652 similarly to the case of direct creation, the sidebar conference 1653 object is built on the basis of the "sidebarByValInfo" parameter 1654 provided by the requestor. As a consequence of a sidebar-by-val 1655 creation, the conference server MUST update the main conference 1656 object reflected by the "confObjID" parameter in the 1657 sidebarbyValRequest/create message introducing the new sidebar object 1658 as a new new in the proper section . The 1659 newly created sidebar conference object MAY be included in the 1660 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1661 "response-code" is "200". The XCON-URI of the newly created sidebar 1662 MUST appear in the "confObjID" parameter of the response. The 1663 conference server can notify any conferencing clients that have 1664 subscribed to the conference event package, and are authorized to 1665 receive the notifications, of the addition of the sidebar to the 1666 conference. 1668 In the case of a "sidebarByVal" request with an operation of 1669 "retrieve", the URI for the conference object created for the sidebar 1670 (received in the response to a "create" operation or in a 1671 sidebarsByValResponse message) MUST be included in the "confObjID" 1672 parameter in the request. This "retrieve" operation is handled by 1673 the conference server in the same manner as a "retrieve" operation 1674 included in a confRequest message as detailed in Section 5.3.4. 1676 In the case of a "sidebarByVal" request with an operation of 1677 "update", the "sidebarByValInfo" MUST also be included in the 1678 request. The "confObjID" parameter contained in the request message 1679 identifies the specific sidebar instance to be updated. An "update" 1680 operation on the "sidebarByValInfo" is handled by the conference 1681 server in the same manner as an "update" operation on the confInfo 1682 included in a confRequest message as detailed in Section 5.3.4. A 1683 "sidebarByValResponse" message MUST carry back to the client a 1684 "version" element related to the current version of the sidebar whose 1685 identifier is contained in the "confObjId" field of the request. 1687 If an "operation" of "delete" is included in the sidebarByVal 1688 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1689 request. Any "sidebarByValInfo" included in the request MUST be 1690 ignored by the conference server. The URI for the conference object 1691 associated with the sidebar MUST be included in the "confObjID" 1692 parameter in the request. If the specific conferencing user as 1693 reflected by the "confUserID" in the request is authorized to delete 1694 the conference, the conference server deletes the conference object 1695 reflected by the "confObjID" parameter and updates the data in the 1696 conference object from which the sidebar was cloned. The conference 1697 server can notify any conferencing clients that have subscribed to 1698 the conference event package, and are authorized to receive the 1699 notifications, of the deletion of the sidebar to the conference. 1701 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1702 or "delete" carries a "confObjID" which is not associated with any 1703 existing sidebar-by-val, a confResponse message containing a "404" 1704 error code will be generated on the server's side. This holds also 1705 for the case in which the mentioned "confObjID" is related to an 1706 existing conference object stored at the server, but associated with 1707 a blueprint or with an actual conference or with a sidebar-by-ref 1708 rather than a sidebar-by-val. 1710 1712 1713 1714 1715 1716 1717 1718 1719 1720 1722 1724 1727 1728 1729 1731 1733 1734 1735 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1748 1750 1753 1754 1755 1757 1759 1760 1761 1763 Figure 14: Structure of the sidebarByValRequest and 1764 sidebarByValResponse messages 1766 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1768 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1769 invoked to retrieve the element of the conference 1770 object identified by the "confObjID" parameter. The 1771 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1772 "operation" parameter MUST NOT be included in a 1773 "sidebarsByRefRequest" message. In the case of a "response-code" of 1774 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1776 response. The element represents the set of URIs 1777 of the sidebars associated with the main conference, whose 1778 description (in the form of a standard XCON conference document) is 1779 external to the main conference itself. Through the retrieved URIs, 1780 it is then possible to access single sidebars using the 1781 "sidebarByRef" request message, described in Section 5.3.10. A 1782 "sidebarsByRefResponse" message MUST carry back to the client a 1783 "version" element related to the current version of the main 1784 conference object (i.e. the one whose identifier is contained in the 1785 "confObjId" field of the request) to which the sidebars in question 1786 are associated. 1788 1790 1791 1792 1793 1794 1795 1796 1797 1798 1800 1802 1805 1806 1807 1809 1811 1812 1813 1815 1817 1818 1819 1820 1821 1822 1823 1824 1825 1827 1829 1832 1833 1834 1836 1838 1839 1840 1842 Figure 15: Structure of the sidebarsByRefRequest and 1843 sidebarsByRefResponse messages 1845 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1847 A sidebarByRefRequest message MUST contain the "operation" parameter 1848 which discriminates among retrieval, creation, modification and 1849 deletion of a specific sidebar. The other required parameters depend 1850 upon the type of operation. 1852 In the case of a "create" operation, the "confObjID" parameter MUST 1853 be included in the sidebyRefRequest message. In this case, the 1854 "confObjID" parameter contains the XCON-URI of the main conference in 1855 which the sidebar has to be created. If no "sidebarByRefInfo" 1856 parameter is included, as envisaged in the XCON framework 1857 ([RFC5239]), the sidebar is created by cloning the main conference, 1858 following the implementation specific cloning rules. Otherwise, 1859 similarly to the case of direct creation, the sidebar conference 1860 object is built on the basis of the "sidebarByRefInfo" parameter 1861 provided by the requestor. If the creation of the sidebar is 1862 successful, the conference server MUST update the "sidebars-by-ref" 1863 element in the conference object from which the sidebar was created 1864 (i.e., as identified by the "confObjID" in the original sidebarByRef 1865 request), with the URI of the newly created sidebar. The newly 1866 created conference object MAY be included in the response in the 1867 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1868 URI for the conference object associated with the newly created 1869 sidebar object MUST appear in the "confObjID" parameter of the 1870 response. The conference server can notify any conferencing clients 1871 that have subscribed to the conference event package, and are 1872 authorized to receive the notifications, of the addition of the 1873 sidebar to the conference. 1875 In the case of a "sidebarByRef" request with an operation of 1876 "retrieve", the URI for the conference object created for the sidebar 1877 MUST be included in the "confObjID" parameter in the request. A 1878 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1879 conference server in the same manner as a "retrieve" operation on the 1880 confInfo included in a confRequest message as detailed in 1881 Section 5.3.4. 1883 In the case of a "sidebarByRef" request with an operation of 1884 "update", the URI for the conference object created for the sidebar 1885 MUST be included in the "confObjID" parameter in the request. The 1886 "sidebarByRefInfo" MUST also be included in the request in the case 1887 of an "operation" of "update". An "update" operation on the 1888 "sidebarByRefInfo" is handled by the conference server in the same 1889 manner as an "update" operation on the confInfo included in a 1890 confRequest message as detailed in Section 5.3.4. A 1891 "sidebarByRefResponse" message MUST carry back to the client a 1892 "version" element related to the current version of the sidebar whose 1893 identifier is contained in the "confObjId" field of the request. 1895 If an "operation" of "delete" is included in the sidebarByRef 1896 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1897 request. Any "sidebarByRefInfo" included in the request MUST be 1898 ignored by the conference server. The URI for the conference object 1899 for the sidebar MUST be included in the "confObjID" parameter in the 1900 request. If the specific conferencing user as reflected by the 1901 "confUserID" in the request is authorized to delete the conference, 1902 the conference server SHOULD delete the conference object reflected 1903 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1904 element in the conference object from which the sidebar was 1905 originally cloned. The conference server can notify any conferencing 1906 clients that have subscribed to the conference event package, and are 1907 authorized to receive the notifications, of the deletion of the 1908 sidebar. 1910 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1911 or "delete" carries a "confObjID" which is not associated with any 1912 existing sidebar-by-ref, a confResponse message containing a "404" 1913 error code will be generated on the server's side. This holds also 1914 for the case in which the mentioned "confObjID" is related to an 1915 existing conference object stored at the server, but associated with 1916 a blueprint or with an actual conference or with a sidebar-by-val 1917 rather than a sidebar-by-ref. 1919 1921 1922 1923 1924 1925 1926 1927 1928 1929 1931 1933 1936 1937 1938 1940 1942 1943 1944 1946 1948 1949 1950 1951 1952 1953 1954 1955 1956 1958 1960 1963 1964 1965 1967 1969 1970 1972 1974 Figure 16: Structure of the sidebarByRefRequest and 1975 sidebarByRefResponse messages 1977 5.3.11. extendedRequest and extendedResponse 1979 In order to facilitate the possibility of specifying new request/ 1980 response pairs for conference control, CCMP makes available the 1981 "extendedRequest" and "extendedResponse" messages. Such messages 1982 constitute a CCMP skeleton in which implementors can transport the 1983 information needed to realize conference control mechanisms not 1984 explicitly envisioned in the CCMP specification; these mechanisms are 1985 called, in this context, "extensions". Each extension is assumed to 1986 be characterized by an appropriate name that MUST be carried in the 1987 extendedRequest/extendedResponse pair in the provided 1988 field. Extension-specific information can be transported in the form 1989 of schema-defined XML elements inside the element present in 1990 both extendedRequest and extendedResponse. 1992 The conferencing client SHOULD be able to be informed about the 1993 extensions supported by a CCMP server and to recover the XML Schema 1994 defining the related specific elements by means of an optionsRequest/ 1995 optionsResponse CCMP transaction (see Section 5.3.12). 1997 The meaning of the common CCMP parameters inherited by the 1998 extendedRequest and extendedResponse from the basic CCMP request and 1999 response messages SHOULD be preserved and exploited appropriately 2000 while defining an extension. 2002 2004 2005 2006 2007 2008 2009 2010 2011 2012 2014 2016 2017 2018 2019 2021 2024 2025 2027 2029 2030 2031 2032 2033 2034 2035 2036 2037 2039 2041 2043 2044 2045 2048 2051 2052 2054 Figure 17: Structure of the extendedRequest and extendedResponse 2055 messages 2057 5.3.12. optionsRequest and optionsResponse 2059 The "optionsRequest" (Figure 18) message is used to retrieve general 2060 information about conference server capabilities. These capabilities 2061 include the standard CCMP messages (request/response pairs) and 2062 potential extension messages supported by the conference server. As 2063 such it is a basic CCMP message, rather than a specialization of the 2064 general CCMP request. 2066 The "optionsResponse" returns, in the appropriate field, a 2067 list of the supported CCMP message pairs as defined in this 2068 specification. These messages are in the form of a list, including each of the supported messages as reflected 2070 by elements. The "optionsResponse" message also 2071 allows for an , which is a list of additional 2072 message types in the form of elements that 2073 are currently undefined, to allow for future extensibility. The 2074 following information is provided for both types of messages: 2076 o (REQUIRED): in case of standard messages, it can be one of 2077 the ten standard message names defined in this document (i.e. 2078 "blueprintsRequest", "confsRequest", etc.). In case of 2079 extensions, this element MUST carry the same value of the 2080 inserted in the corresponding extendedRequest/ 2081 extendedResponse message pair 2083 o (OPTIONAL): this field is a list of 2084 entries, each representing the CRUD operation supported by the 2085 server for the message. If this element is absent, the client 2086 SHOULD assume the server is able to handle the entire set of CRUD 2087 operations or, in case of standard messages, all the operations 2088 envisioned for that message in this document. 2090 o (OPTIONAL): since all CCMP messages can potentially 2091 contain XML elements not envisioned in the CCMP schema (due to the 2092 presence of elements and attributes), a reference to a 2093 proper schema definition specifying such new elements/attributes 2094 can also be sent back to the clients by means of such field. If 2095 this element is absent, no new elements are introduced in the 2096 messages further than those explicitly defined in the CCMP 2097 specification. 2099 o (OPTIONAL): human readable information about the 2100 related message 2102 The only parameter needed in the optionsRequest is the sender 2103 confUserID, which is mirrored in the homologous parameter of the 2104 corresponding optionsResponse. 2106 The CCMP server MUST include the containing 2107 at least one element in the optionsResponse, since a CCMP 2108 server is required to be able to handle at least one of the standard 2109 messages for at least one of the operations. 2111 2113 2114 2115 2116 2117 2119 2121 2122 2123 2124 2125 2126 2127 2128 2129 2131 2133 2136 2137 2138 2140 2142 2143 2144 2146 2148 2149 2150 2153 2156 2158 2159 2160 2162 2164 2165 2166 2169 2171 2172 2173 2175 2177 2178 2179 2182 2185 2187 2189 2191 2192 2193 2195 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2212 2214 2215 2216 2218 2219 2220 2222 Figure 18: Structure of the optionsRequest and optionsResponse 2223 messages 2225 5.4. CCMP Response Codes 2227 All CCMP response messages MUST include a "response-code". This 2228 document defines an IANA registry for the CCMP response codes as 2229 described in Section 12.5.2. The following summarizes the CCMP 2230 response codes: 2232 200 Success: Successful completion of the requested operation. 2234 400 Bad Request: Syntactically malformed request. 2236 401 Unauthorized: User not allowed to perform the required 2237 operation. 2239 403 Forbidden: Operation not allowed (e.g., cancellation of a 2240 blueprint). 2242 404 Object Not Found: Target conference object missing at the server 2243 (it refers to the "confObjID" parameter in the generic request 2244 message) 2246 409 Conflict: A generic error associated with all those situations 2247 in which a requested client operation cannot be successfully 2248 completed by the server. An example of such situation is when the 2249 modification of an object cannot be applied due to conflicts 2250 arising at the server's side, e.g. because the client version of 2251 the object is an obsolete one and the requested modifications 2252 collide with the up-to-date state of the object stored at the 2253 server. Such code would also be used if a client attempts to 2254 create an object (conference or user) with an entity that already 2255 exists. 2257 420 User Not Found: Target user missing at the server (it is related 2258 to the XCON-USERID in the "entity" attribute of the "userInfo" 2259 parameter when it is included in userRequests) 2261 421 Invalid confUserID: User missing at the server (this code is 2262 returned in the case of requests in which the "confUserID" of the 2263 sender is invalid). 2265 422 Invalid Conference Password: Target conference object's password 2266 contained in the request is wrong. 2268 423 Conference Password Required: "conference-password" missing in a 2269 request to access a password-protected conference object. 2271 424 Authentication Required: User's authentication information is 2272 missing or invalid. 2274 425 Forbidden Delete Parent: Cancel operation failed since the 2275 target object is a parent of child objects which depend on it, or 2276 because it effects, based on the "parent-enforceable" mechanism, 2277 the corresponding element in a child object. 2279 426 Forbidden Change Protected: Update refused by the server because 2280 the target element cannot be modified due to its implicit 2281 dependence on the value of a parent object ("parent-enforceable" 2282 mechanism). 2284 427 Invalid Domain Name: The domain name in an AUTO_GENERATE_X 2285 instance in the conference object is not within the CCMP server's 2286 domain of responsibility. 2288 500 Server Internal Error: The server cannot complete the required 2289 service due to a system internal error. 2291 501 Not Implemented: Operation envisaged in the protocol, but not 2292 implemented in the contacted server. 2294 510 Request Timeout: The time required to serve the request has 2295 exceeded the envisaged service threshold. 2297 511 Resources Not Available: This code is used when the CCMP server 2298 cannot execute a command because of resource issues, e.g. it 2299 cannot create a sub conference because the system has reached its 2300 limits on the number of sub conferences, or if a request for 2301 adding a new user fails because the max number of users has been 2302 reached for the conference or the max number of users has been 2303 reached for the conferencing system. 2305 The handling of a "response-code" of "404", "409", "420", "421", 2306 "425", "426" and "427" are only applicable to specific operations for 2307 specialized message responses and the details are provided in 2308 Section 5.3. The following table summarizes these response codes and 2309 the specialized message and operation to which they are applicable: 2311 +----------+-------------+--------------+-------------+-------------+ 2312 | Response | Create | Retrieve | Update | Delete | 2313 | code | | | | | 2314 +----------+-------------+--------------+-------------+-------------+ 2315 | 404 | userRequest | All retrieve | All update | All delete | 2316 | | sidebarBy | requests | requests | requests | 2317 | | ValRequest, | EXCEPT: | | | 2318 | | sidebarsBy | blueprints | | | 2319 | | RefRequest | Request, | | | 2320 | | | confsRequest | | | 2321 | -------- | ----------- | ------------ | ----------- | ----------- | 2322 | | - | | | | 2323 | 409 | N/A | N/A | All update | N/A | 2324 | | | | requests | | 2325 | -------- | ----------- | ----------- | ----------- | ----------- | 2326 | 420 | userRequest | userRequest | userRequest | userRequest | 2327 | | (3rd party | | | | 2328 | | invite with | | | | 2329 | | third user | | | | 2330 | | entity) (*) | | | | 2331 | -------- | ----------- | ----------- | ----------- | ----------- | 2332 | 421 | All create | All retrieve | All update | All delete | 2333 | | requests | requests | requests | requests | 2334 | | EXCEPT: | | | | 2335 | | userRequest | | | | 2336 | | with no | | | | 2337 | | confUserID | | | | 2338 | | (**) | | | | 2339 | -------- | ----------- | ----------- | ----------- | ----------- | 2340 | 425 | N/A | N/A | N/A | All delete | 2341 | | | | | request | 2342 | -------- | ----------- | ----------- | ----------- | ----------- | 2343 | 426 | N/A | N/A | All update | N/A | 2344 | | | | requests | | 2345 | -------- | ----------- | ----------- | ----------- | ----------- | 2346 | 427 | ConfRequest | N/A | All update | N/A | 2347 | | UserRequest | | requests | | 2348 +----------+-------------+--------------+-------------+-------------+ 2349 Table 2: Response codes and associated operations 2351 (*) "420" in answer to a "userRequest/create" operation: in the case 2352 of a third-party invite, this code can be returned if the 2353 "confUserID" (contained in the "entity" attribute of the "userInfo" 2354 parameter) of the user to be added is unknown. In the case above, if 2355 instead it is the "confUserID" of the sender of the request that is 2356 invalid, a "421" error code is returned to the client. 2358 (**) "421" is not sent in answers to "userRequest/create" messages 2359 having a "null" confUserID, since this case is associated with a user 2360 who is unaware of his own XCON-USERID, but wants to enter a known 2361 conference. 2363 In the case of a response code of "510", a conferencing client MAY 2364 re-attempt the request within a period of time that would be specific 2365 to a conference control client or conference control server. 2367 A response code of "400" indicates that the conference control client 2368 sent a malformed request, which is indicative of an error in the 2369 conference control client or in the conference control server. The 2370 handling is specific to the conference control client implementation 2371 (e.g., generate a log, display an error message, etc.). It is NOT 2372 RECOMMENDED that the client re-attempt the request in this case. 2374 Response codes such as "401" and "403" indicate the client does not 2375 have the appropriate permissions, or there is an error in the 2376 permissions: re-attempting the request would likely not succeed and 2377 thus it is NOT RECOMMENDED. 2379 Any unexpected or unknown "response-code" SHOULD be treated by the 2380 client in the same manner as a "500" "response-code", the handling of 2381 which is specific to the conference control client implementation. 2383 6. A complete example of the CCMP in action 2385 In this section a typical, not normative, scenario in which the CCMP 2386 comes into play is described, by showing the actual composition of 2387 the various CCMP messages. In the call flows of the example, the 2388 Conference Control Client is a CCMP-enabled client, whereas the 2389 Conference Control Server is a CCMP-enabled server. The "confUserID" 2390 of the client, Alice, is "xcon-userid:alice@example.com" and appears 2391 in all requests. The sequence of operations is as follows: 2393 1. Alice retrieves from the server the list of available blueprints 2394 (Section 6.1); 2396 2. Alice asks for detailed information about a specific blueprint 2397 (Section 6.2); 2399 3. Alice decides to create a new conference by cloning the retrieved 2400 blueprint (Section 6.3); 2402 4. Alice modifies information (e.g. XCON-URI, name, description) 2403 associated with the newly created blueprint (Section 6.4); 2405 5. Alice specifies a list of users to be contacted when the 2406 conference is activated (Section 6.5); 2408 6. Alice joins the conference (Section 6.6); 2410 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2411 "xcon-userid:Ciccio@example.com") join the conference 2412 (Section 6.7). 2414 8. Alice asks for the CCMP server capabilities (Section 6.8); 2416 9. Alice exploits an extension of the CCMP server (Section 6.9). 2418 Note, the examples do not include any details beyond the basic 2419 operation. 2421 In the following sections we deal with each of the above mentioned 2422 actions separately. 2424 6.1. Alice retrieves the available blueprints 2426 This section illustrates the transaction associated with retrieval of 2427 the blueprints, together with a dump of the two messages exchanged 2428 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2429 the figure, the "blueprintsResponse" message contains, in the 2430 "blueprintsInfo" parameter, information about the available 2431 blueprints, in the form of the standard XCON-URI of the blueprint, 2432 plus additional (and optional) information, like its display-text and 2433 purpose. 2435 Alice retrieves from the server the list of available blueprints: 2437 CCMP Client CCMP Server 2438 | | 2439 | CCMP blueprintsRequest message | 2440 | - confUserID: Alice | 2441 | - confObjID: (null) | 2442 |------------------------------------------------------>| 2443 | | 2444 | CMP blueprintsResponse message | 2445 | - confUserID: Alice | 2446 | - confObjID: (null) | 2447 | - response-code: 200 | 2448 | - blueprintsInfo: bp123,bp124,.. | 2449 |<------------------------------------------------------| 2450 | | 2451 . . 2452 . . 2454 1. blueprintsRequest message: 2456 2457 2461 2463 xcon-userid:alice@example.com 2464 2465 2466 2468 2. blueprintsResponse message from the server: 2470 2471 2475 2478 xcon-userid:alice@example.com 2479 200 2480 2481 2482 2483 xcon:AudioRoom@example.com 2484 AudioRoom 2485 Simple Room: 2486 conference room with public access, 2487 where only audio is available, more users 2488 can talk at the same time 2489 and the requests for the AudioFloor 2490 are automatically accepted. 2491 2492 2493 2494 xcon:VideoRoom@example.com 2495 VideoRoom 2496 Video Room: 2497 conference room with public access, 2498 where both audio and video are available, 2499 8 users can talk and be seen at the same time, 2500 and the floor requests are automatically accepted. 2501 2502 2503 2504 xcon:AudioConference1@example.com 2505 AudioConference1 2506 Public Audio Conference: 2507 conference with public access, 2508 where only audio is available, 2509 only one user can talk at the same time, 2510 and the requests for the AudioFloor MUST 2511 be accepted by a Chair. 2512 2513 2514 2515 xcon:VideoConference1@example.com 2516 VideoConference1 2517 Public Video Conference: conference 2518 where both audio and video are available, 2519 only one user can talk 2520 2521 2522 2523 xcon:AudioConference2@example.com 2524 AudioConference2 2525 Basic Audio Conference: 2526 conference with private access, 2527 where only audio is available, 2528 only one user can talk at the same time, 2529 and the requests for the AudioFloor MUST 2530 be accepted by a Chair. 2531 2532 2533 2534 2535 2537 2539 Figure 19: Getting blueprints from the server 2541 6.2. Alice gets detailed information about a specific blueprint 2543 This section illustrates the second transaction in the overall flow. 2544 In this case, Alice, who now knows the XCON-URIs of the blueprints 2545 available at the server, makes a drill-down query, in the form of a 2546 CCMP "blueprintRequest" message, to get detailed information about 2547 one of them (the one called with XCON-URI 2548 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2549 Notice that the response contains, in the "blueprintInfo" parameter, 2550 a document compliant with the standard XCON data model. 2552 Alice retrieves detailed information about a specified blueprint: 2554 CCMP Client CCMP Server 2555 | | 2556 | CCMP blueprintRequest message | 2557 | - confUserID: Alice | 2558 | - confObjID: bp123 | 2559 | - operation: retrieve | 2560 | - blueprintInfo: (null) | 2561 |------------------------------------------------------>| 2562 | | 2563 | CCMP blueprintResponse message | 2564 | - confUserID: Alice | 2565 | - confObjID: bp123 | 2566 | - operation: retrieve | 2567 | - response-code: 200 | 2568 | - blueprintInfo: bp123Info | 2569 |<------------------------------------------------------| 2570 | | 2571 . . 2572 . . 2574 1. blueprintRequest message: 2576 2577 2581 2583 xcon-userid:alice@example.com 2584 xcon:AudioRoom@example.com 2585 retrieve 2586 2587 2588 2590 2. blueprintResponse message from the server: 2592 2593 2597 2599 xcon-userid:alice@example.com 2600 xcon:AudioRoom@example.com 2601 retrieve 2602 200 2603 Success 2604 2605 2606 2607 AudioRoom 2608 2609 2610 audio stream 2611 audio 2612 2613 2614 2615 2616 allow 2617 2618 2619 confirm 2620 2621 2622 audioLabel 2623 2624 2625 2626 2627 2629 2630 2632 Figure 20: Getting info about a specific blueprint 2634 6.3. Alice creates a new conference through a cloning operation 2636 This section illustrates the third transaction in the overall flow. 2637 Alice decides to create a new conference by cloning the blueprint 2638 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2639 retrieved detailed information through the "blueprintRequest" 2640 message. This is achieved by sending a "confRequest/create" message 2641 having the blueprint's URI in the "confObjID" parameter. The picture 2642 shows such transaction. Notice that the response contains, in the 2643 "confInfo" parameter, the document associated with the newly created 2644 conference, which is compliant with the standard XCON data model. 2645 The "confObjID" in the response is set to the XCON-URI of the new 2646 conference (in this case, "xcon:8977794@example.com"). We also 2647 notice that this value is equal to the value of the "entity" 2648 attribute of the element of the document 2649 representing the newly created conference object. 2651 Alice creates a new conference by cloning the 2652 "xcon:AudioRoom@example.com" blueprint: 2654 CCMP Client CCMP Server 2655 | | 2656 | CCMP confRequest message | 2657 | - confUserID: Alice | 2658 | - confObjID: AudioRoom | 2659 | - operation: create | 2660 | - confInfo: (null) | 2661 |------------------------------------------------------>| 2662 | | 2663 | CCMP confResponse message | 2664 | - confUserID: Alice | 2665 | - confObjID: newConfId | 2666 | - operation: create | 2667 | - response-code: 200 | 2668 | - version: 1 | 2669 | - confInfo: newConfInfo | 2670 |<------------------------------------------------------| 2671 | | 2672 . . 2673 . . 2675 1. confRequest message: 2677 2678 2682 2685 xcon-userid:alice@example.com 2686 xcon:AudioRoom@example.com 2687 create 2688 2689 2690 2692 2. confResponse message from the server: 2694 2695 2699 2701 xcon-userid:alice@example.com 2702 xcon:8977794@example.com 2703 create 2704 200 2705 Success 2706 1 2707 2708 2709 2710 2711 New conference by Alice cloned from AudioRoom 2712 2713 2714 2715 audio stream 2716 audio 2717 2718 2720 2721 2722 allow 2723 2724 2725 confirm 2726 2727 2728 333 2729 2730 2731 2732 2733 2734 2735 2737 Figure 21: Creating a new conference by cloning a blueprint 2739 6.4. Alice updates conference information 2741 This section illustrates the fourth transaction in the overall flow. 2742 Alice decides to modify some of the details associated with the 2743 conference she just created. More precisely, she changes the 2744 element under the element of 2745 the document representing the conference. This is achieved through a 2746 "confRequest/update" message carrying the fragment of the conference 2747 document to which the required changes have to be applied. As shown 2748 in the picture, the response contains a code of "200", which 2749 acknowledges the modifications requested by the client, while also 2750 updating the conference version number from 1 to 2, as reflected in 2751 the "version" parameter. 2753 Alice updates information about the conference she just created: 2755 CCMP Client CCMP Server 2756 | | 2757 | CCMP confRequest message | 2758 | - confUserID: Alice | 2759 | - confObjID: 8977794 | 2760 | - operation: update | 2761 | - confInfo: confUpdates | 2762 |------------------------------------------------------>| 2763 | | 2764 | CCMP confResponse message | 2765 | - confUserID: Alice | 2766 | - confObjID: 8977794 | 2767 | - operation: update | 2768 | - response-code: 200 | 2769 | - version: 2 | 2770 | - confInfo: (null) | 2771 |<------------------------------------------------------| 2772 | | 2773 . . 2774 . . 2776 1. confRequest message: 2778 2779 2783 2786 xcon-userid:alice@example.com 2787 xcon:8977794@example.com 2788 update 2789 2790 2791 2792 2793 Alice's conference 2794 2795 2796 2797 2798 2799 2801 2. confResponse message from the server: 2803 2804 2808 2810 xcon-userid:alice@example.com 2811 xcon:8977794@example.com 2812 update 2813 200 2814 Success 2815 2 2816 2817 2818 2820 Figure 22: Updating conference information 2822 6.5. Alice inserts a list of users in the conference object 2824 This section illustrates the fifth transaction in the overall flow. 2825 Alice modifies the under the element in 2826 the document associated with the conference she created. To the 2827 purpose, she exploits the "usersRequest" message provided by the 2828 CCMP. The picture below shows the transaction. 2830 Alice updates information about the list of users to whom access to 2831 the conference is permitted: 2833 CCMP Client CCMP Server 2834 | | 2835 | CCMP usersRequest message | 2836 | - confUserID: Alice | 2837 | - confObjID: 8977794 | 2838 | - operation: update | 2839 | - usersInfo: usersUpdates | 2840 |------------------------------------------------------>| 2841 | | 2842 | CCMP usersResponse message | 2843 | - confUserID: Alice | 2844 | - confObjID: 8977794 | 2845 | - operation: update | 2846 | - response-code: 200 | 2847 | - version: 3 | 2848 | - usersInfo: (null) | 2849 |<------------------------------------------------------| 2850 | | 2851 . . 2852 . . 2854 1. usersRequest message: 2856 2857 2861 2863 xcon-userid:alice@example.com 2864 xcon:8977794@example.com 2865 update 2866 2867 2868 2869 2871 2873 2875 2876 2877 2878 2879 2881 2. usersResponse message from the server: 2883 2884 2888 2890 xcon-userid:alice@example.com 2891 xcon:8977794@example.com 2892 retrieve 2893 200 2894 Success 2895 3 2896 2897 2898 2899 Figure 23: Updating the list of allowed users for the conference 2900 'xcon:8977794@example.com' 2902 6.6. Alice joins the conference 2904 This section illustrates the sixth transaction in the overall flow. 2905 Alice uses the CCMP to add herself to the newly created conference. 2906 This is achieved through a "userRequest/create" message containing, 2907 in the "userInfo" parameter, a element compliant with the XCON 2908 data model representation. Notice that such element includes 2909 information about the user's Address of Records, as well as her 2910 current end-point. The picture below shows the transaction. Notice 2911 how the "confUserID" parameter is equal to the "entity" attribute of 2912 the element, which indicates that the request issued by 2913 the client is a first-party one. 2915 Alice joins the conference by issuing a "userRequest/create" message 2916 with her own id to the server: 2918 CCMP Client CCMP Server 2919 | | 2920 | CCMP userRequest message | 2921 | - confUserID: Alice | 2922 | - confObjID: 8977794 | 2923 | - operation: create | 2924 | - userInfo: AliceUserInfo | 2925 |------------------------------------------------------>| 2926 | | 2927 | CCMP userResponse message | 2928 | - confUserID: Alice | 2929 | - confObjID: 8977794 | 2930 | - operation: create | 2931 | - response-code: 200 | 2932 | - version: 4 | 2933 | - userInfo: (null) | 2934 |<------------------------------------------------------| 2935 | | 2936 . . 2937 . . 2939 1. userRequest message: 2941 2942 2946 2948 xcon-userid:alice@example.com 2949 xcon:8977794@example.com 2950 create 2951 2952 2953 2954 2955 2956 mailto:Alice83@example.com 2957 2958 email 2959 2960 2961 2962 2963 2964 2965 2967 2. userResponse message from the server: 2969 2970 2974 2976 xcon-userid:alice@example.com 2977 xcon:8977794@example.com 2978 create 2979 200 2980 Success 2981 4 2982 2983 2984 2986 Figure 24: Alice joins the conference through the CCMP 2988 6.7. Alice adds a new user to the conference 2990 This section illustrates the seventh and last transaction in the 2991 overall flow. Alice uses the CCMP to add a new conferencing system 2992 user, Ciccio, to the conference. This "third-party" request is 2993 realized through a "userRequest/create" message containing, in the 2994 "userInfo" parameter, a element compliant with the XCON data 2995 model representation. Notice that such element includes information 2996 about Ciccio's Address of Records, as well as his current end-point, 2997 but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as 2998 discussed in Section 4.3, since the XCON-USERID is initially unknown 2999 to Alice. Thus, the conference server is in charge of generating a 3000 new XCON-USERID for the user Alice indicates (i.e, Ciccio), and 3001 returning it in the "entity" attribute of the "userInfo" parameter 3002 carried in the response, as well as adding the user to the 3003 conference. The picture below shows the transaction. 3005 Alice adds user "Ciccio" to the conference by issuing a third-party 3006 "userRequest/create" message to the server: 3008 CCMP Client CCMP Server 3009 | | 3010 | CCMP userRequest message | 3011 | - confUserID: Alice | 3012 | - confObjID: 8977794 | 3013 | - operation: create | 3014 | - userInfo: dummyUserID, CiccioUserInfo | 3015 |------------------------------------------------------>| 3016 | | 3017 | CCMP optionsResponse message | 3018 | - confUserID: Alice | 3019 | - confObjID: 8977794 | 3020 | - operation: create | 3021 | - response-code: 200 | 3022 | - version: 5 | 3023 | - userInfo: userIDCiccio, | 3024 | CiccioUserInfo | 3025 | | 3026 |<------------------------------------------------------| 3027 | | 3028 . . 3029 . . 3031 1. "third party" userRequest message from Alice: 3033 3034 3038 3040 xcon-userid:alice@example.com 3041 xcon:8977794@example.com 3042 create 3043 3044 3045 3046 3047 3048 mailto:Ciccio@example.com 3049 3050 email 3051 3052 3053 3054 3055 3056 3057 3059 2. "third party" userResponse message from the server: 3061 3062 3066 3068 xcon-userid:alice@example.com 3069 xcon:8977794@example.com 3070 create 3071 200 3072 5 3073 3074 3075 3076 3077 3078 mailto:Ciccio@example.com 3079 3080 email 3082 3083 3084 3085 3086 3087 3088 3090 Figure 25: Alice adds a new user to the conference through the CCMP 3092 6.8. Alice asks for the CCMP server capabilities 3094 This section illustrates how Alice can discover which standard CCMP 3095 messages and what extensions are supported by the CCMP server she 3096 interacts with through an optionsRequest/optionsResponse transaction. 3098 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 3099 confUserID parameter. Looking at the element in the 3100 received optionsResponse, Alice infers the following server 3101 capabilities as regards standard CCMP messages: 3103 o the server doesn't support sidebarsByValRequest nor 3104 sidebarByValRequest messages, since they do not appear in the 3105 ; 3107 o the only implemented operation for the blueprintRequest message is 3108 "retrieve", since no other entries are included in the 3109 related field. 3111 By analyzing the , Alice discovers the server 3112 implements a bluePrint extension, referred to as "confSummaryRequest" 3113 in this example. This extension allows Alice to recover via CCMP a 3114 brief description of a specific conference; the XML elements involved 3115 in this extended conference control transaction are available at the 3116 URL indicated in the element and the only operation 3117 provided by this extension is "retrieve". To better understand how 3118 Alice can exploit the "confSummaryRequest" extension via CCMP, see 3119 Section 6.9. 3121 The figure below shows the optionsRequest/optionsResponse message 3122 exchange between Alice and the CCMP server. 3124 CCMP Client CCMP Server 3125 | | 3126 | CCMP optionsRequest message | 3127 | - confUserID: Alice | 3128 |------------------------------------------------------>| 3129 | | 3130 | CCMP userResponse message | 3131 | - confUserID: Alice | 3132 | - response-code: 200 | 3133 | - options (list of both | 3134 | standard and extended | 3135 | supported messages) | 3136 |<------------------------------------------------------| 3137 | | 3138 . . 3139 . . 3141 1. optionsRequest (Alice asks for CCMP server capabilities) 3143 3144 3148 3150 xcon-userid:alice@example.com 3151 3152 3154 2. optionsResponse (the server returns the list of its conference 3155 control capabilities) 3157 3158 3162 3164 xcon-userid:alice@example.com 3165 200 3166 success 3167 3168 3169 3170 3171 blueprintsRequest 3172 3173 3174 blueprintRequest 3175 3176 retrieve 3177 3178 3179 3180 confsRequest 3181 3182 3183 confRequest 3184 3185 3186 usersRequest 3187 3188 3189 userRequest 3190 3191 3192 sidebarsByRefRequest 3193 3194 3195 sidebarByRefRequest 3196 3197 3198 3199 3200 confSummaryRequest 3201 3202 retrieve 3203 3204 3205 http://example.com/ccmp-extension-schema.xsd 3206 3207 3208 confSummaryRequest is intented 3209 to allow the requestor to retrieve 3210 a brief description 3211 of the conference indicated in the 3212 confObjID request parameter 3213 3214 3215 3216 3217 3218 3220 3222 Figure 26: Alice asks for the server control capabilities 3224 6.9. Alice exploits a CCMP server extension 3226 In this section, a very simple example of CCMP extension support is 3227 provided. Alice can recover information about this and other server- 3228 supported extensions by issuing an optionsRequest (see Section 6.8). 3230 The extension in question is named "confSummaryRequest" and allows a 3231 CCMP client to obtain from the CCMP server synthetic information 3232 about a specific conference. The conference summary is carried in 3233 the form of an XML element as follows: 3235 3236 3240 3242 3243 3244 3245 3246 3247 3248 3249 3251 3253 Figure 27: Example of XML Schema defining an extension parameter 3254 (ccmp-extension-schema.xsd) 3256 As it can be inferred from the schema file, the element 3257 contains conference information related to: 3259 o title 3261 o status (active or registered) 3263 o participation modality (if everyone is allowed to participate, the 3264 boolean element is set to "true") 3266 o involved media 3268 In order to retrieve a conference summary related to the conference 3269 she participates in, Alice then sends to the CCMP server an 3270 extendedRequest with a "confSummaryRequest" , 3271 specifying the conference xcon-uri in the confObjID request 3272 parameter, as depicted in the figure below. 3274 CCMP Client CCMP Server 3275 | | 3276 | CCMP extendedRequest message | 3277 | - confUserID: Alice | 3278 | - confObjID: 8977794 | 3279 | - operation: retrieve | 3280 | - extensionName: confSummaryRequest | 3281 |------------------------------------------------------>| 3282 | | 3283 | CCMP extendedResponse message | 3284 | - confUserID: Alice | 3285 | - confObjID: 8977794 | 3286 | - operation: retrieve | 3287 | - response-code: 200 | 3288 | - extensionName: | 3289 | confSummaryRequest | 3290 | - confSummary | 3291 |<------------------------------------------------------| 3292 | | 3293 . . 3294 . . 3296 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3298 3299 3303 3305 xcon-userid:alice@example.com 3306 xcon:8977794@example.com 3307 retrieve 3308 3309 confRequestSummary 3310 3311 3312 3314 2. extendedResponse (the server provides Alice with a brief description 3315 of the desired conference) 3317 3318 3322 3324 xcon-userid:alice@example.com 3325 xcon:8977794@example.com 3326 retrieve 3327 200 3328 success 3329 3330 confSummaryRequest 3331 3332 Alice's conference 3333 active 3334 true 3335 audio 3336 3337 3338 3339 3341 Figure 28: Alice exploits the 'confSummaryRequest' extension 3343 7. Locating a Conference Control Server 3345 If a conference control client is not pre-configured to use a 3346 specific conference control server for the requests, the client MUST 3347 first discover the conference control server before it can send any 3348 requests. The result of the discovery process, is the address of the 3349 server supporting conferencing. In this document, the result is an 3350 http: or https: URI, which identifies a conference server. 3352 DNS is RECOMMENDED to be used to locate a conference server in the 3353 case that the client is not pre-configured to use a specific 3354 conference server. U-NAPTR resolution for conferencing takes a 3355 domain name as input and produces a URI that identifies the 3356 conferencing server. This process also requires an Application 3357 Service tag and an Application Protocol tag, which differentiate 3358 conferencing-related NAPTR records from other records for that 3359 domain. 3361 Section 12.4.1 defines an Application Service tag of "XCON", which is 3362 used to identify the centralized conferencing (XCON) server for a 3363 particular domain. The Application Protocol tag "CCMP", defined in 3364 Section 12.4.2, is used to identify an XCON server that understands 3365 the CCMP protocol. 3367 The NAPTR records in the following example Figure 29 demonstrate the 3368 use of the Application Service and Protocol tags. Iterative NAPTR 3369 resolution is used to delegate responsibility for the conferencing 3370 service from "zonea.example.com." and "zoneb.example.com." to 3371 "outsource.example.com.". 3373 zonea.example.com. 3374 ;; order pref flags 3375 IN NAPTR 100 10 "" "XCON-CCMP" ( ; service 3376 "" ; regex 3377 outsource.example.com. ; replacement 3378 ) 3379 zoneb.example.com. 3380 ;; order pref flags 3381 IN NAPTR 100 10 "" "XCON-CCMP" ( ; service 3382 "" ; regex 3383 outsource.example.com. ; replacement 3384 ) 3385 outsource.example.com. 3386 ;; order pref flags 3387 IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service 3388 "!*.!https://confs.example.com/!" ; regex 3389 . ; replacement 3390 ) 3392 Figure 29: Sample XCON-CCMP Service NAPTR Records 3394 Details for the "XCON" Application Service tag and the "CCMP" 3395 Application Protocol tag are included in Section 12.4. 3397 8. Managing Notifications 3399 As per [RFC5239], the CCMP is one of the following four protocols 3400 which have been formally identified within the XCON framework: 3402 Conference Control Protocol: between Conference and Media Control 3403 Client and Conference Server. Such protocol is the subject of the 3404 present document. 3406 Binary floor Control Protocol: between the Floor Control Client and 3407 the Floor Control Server. Such protocol is the BFCP, specified in 3408 [RFC4582]. 3410 Call Signaling Protocol: between the Call Signaling Client and the 3411 Focus. Such protocol can be either SIP or any other call 3412 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3413 a conferencing session. 3415 Notification Protocol: between the Notification Client and the XCON 3416 Notification Service. This specification does not define a new 3417 notification protocol. For clients that use SIP as the call 3418 signaling protocol, the XCON event package 3419 [I-D.ietf-xcon-event-package] MUST be used by the client for 3420 notifications of changes in the conference data as described 3421 below. 3423 The CCMP protocol specified in this document is a pro-active one and 3424 is used by a conferencing client to send requests to a conferencing 3425 server in order to retrieve information about the conference objects 3426 stored by the server and to potentially manipulate them. However, a 3427 complete conferencing solution is not prohibited from providing 3428 clients with a means for receiving asynchronous updates about the 3429 status of the objects available at the server. The notification 3430 protocol, while conceptually independent of all the mentioned 3431 companion protocols, can nonetheless be chosen in a way that is 3432 consistent with the overall protocol architecture characterizing a 3433 specific deployment, as discussed in the following. 3435 When the conference control client uses SIP [RFC3261] as the 3436 signaling protocol to participate in the conference, SIP event 3437 notification can be used. In such a case, the conference control 3438 client MUST implement the Conference event package for XCON 3439 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3440 conferencing clients as is SIP for signaling per the XCON Framework 3441 [RFC5239]. 3443 In the case where the interface to the conference server is entirely 3444 web based, there is a common mechanism for web-based systems that 3445 could be used - a "call back". With this mechanism, the conference 3446 client provides the conference server with an HTTP URL which is 3447 invoked when a change occurs. This is a common implementation 3448 mechanism for e-commerce. This works well in the scenarios whereby 3449 the conferencing client is a web server that provides the graphical 3450 HTML user interface and uses CCMP as the backend interface to the 3451 conference server. And, this model can co-exist with the SIP event 3452 notification model. PC-based clients behind NATs could provide a SIP 3453 event URI, whereas web-based clients using CCMP in the backend would 3454 probably find the HTTP call back approach much easier. The details 3455 of this approach are out of scope for the CCMP per se, thus the 3456 expectation is that a future specification will document this 3457 solution. 3459 9. HTTP Transport 3461 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3462 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3463 conforming conference Server and Conferencing client MUST support. 3465 Although CCMP uses HTTP as a transport, it uses a strict subset of 3466 HTTP features, and due to the restrictions of some features, a 3467 conferencing server might not be a fully compliant HTTP server. It 3468 is intended that a conference server can easily be built using an 3469 HTTP server with extensibility mechanisms, and that a conferencing 3470 client can trivially use existing HTTP libraries. This subset of 3471 requirements helps implementors avoid ambiguity with the many options 3472 the full HTTP protocol offers. 3474 Support of HTTP authentication [RFC2617] and cookies [RFC6265] is 3475 OPTIONAL for a conferencing client that conforms to this 3476 specification. These mechanism are unnecessary because CCMP requests 3477 carry their own authentication information (in the "subject" field; 3478 see Section 5.1). 3480 A CCMP request is carried in the body of an HTTP POST request. The 3481 conferencing client MUST include a Host header in the request. 3483 The MIME type of CCMP request and response bodies is "application/ 3484 ccmp+xml". The conference server and conferencing client MUST 3485 provide this value in the HTTP Content-Type and Accept header fields. 3486 If the conference server does not receive the appropriate Content- 3487 Type and Accept header fields, the conference server SHOULD fail the 3488 request, returning a 406 (not acceptable) response. CCMP responses 3489 SHOULD include a Content-Length header. 3491 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3492 header in CCMP requests. The conference server MAY return 501 (not 3493 implemented) errors if either of these HTTP features are used. In 3494 the case that the conference server receives a request from the 3495 conferencing client containing a If-* (conditional) header, the 3496 conference server SHOULD return a 412 (precondition failed) response. 3498 The POST method is the only method REQUIRED for CCMP. If a 3499 conference server chooses to support GET or HEAD, it SHOULD consider 3500 the kind of application doing the GET. Since a conferencing client 3501 only uses a POST method, the GET or HEAD MUST be either an escaped 3502 URL (e.g., somebody found a URL in protocol traces or log files and 3503 fed it into their browser) or somebody doing testing/ debugging. The 3504 conference server could provide information in the CCMP response 3505 indicating that the URL corresponds to a conference server and only 3506 responds to CCMP POST requests or the conference server could instead 3507 try to avoid any leak of information by returning a very generic HTTP 3508 error message such as 405 (method not allowed). 3510 The conference server populates the HTTP headers of responses so that 3511 they are consistent with the contents of the message. In particular, 3512 the "CacheControl" header SHOULD be set to disable caching of any 3513 conference information by HTTP intermediaries. Otherwise, there is 3514 the risk of stale information and/or the unauthorized disclosure of 3515 the information. The HTTP status code MUST indicate a 2xx series 3516 response for all CCMP Response and Error messages. 3518 The conference server MAY redirect a CCMP request. A conference 3519 server MUST NOT include CCMP responses in a 3xx response. A 3520 conferencing client MUST handle redirects, by using the Location 3521 header provided by the server in a 3xx response. When redirecting, 3522 the conferencing client MUST observe the delay indicated by the 3523 Retry-After header. The conferencing client MUST authenticate the 3524 server that returns the redirect response before following the 3525 redirect. A conferencing client SHOULD authenticate the conference 3526 server indicated in a redirect. 3528 The conference server SHOULD support persistent connections and 3529 request pipelining. If pipelining is not supported, the conference 3530 server MUST NOT allow persistent connections. The conference server 3531 MUST support termination of a response by the closing of a 3532 connection. 3534 Implementations of CCMP that implement HTTP transport MUST implement 3535 transport over TLS [RFC2818]. TLS provides message integrity and 3536 confidentiality between the conference control client and the 3537 conference control server. The conferencing client MUST implement 3538 the server authentication method described in HTTPS [RFC2818]. The 3539 device uses the URI obtained during conference server discovery to 3540 authenticate the server. The details of this authentication method 3541 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3542 the conferencing client SHOULD fail a request if server 3543 authentication fails. 3545 10. Security Considerations 3547 As identified in the XCON framework [RFC5239], there are a wide 3548 variety of potential attacks related to conferencing, due to the 3549 natural involvement of multiple endpoints and the capability to 3550 manipulate the data on the conference server using CCMP. Examples of 3551 attacks include the following: an endpoint attempting to listen to 3552 conferences in which it is not authorized to participate, an endpoint 3553 attempting to disconnect or mute other users, and theft of service by 3554 an endpoint in attempting to create conferences it is not allowed to 3555 create. 3557 The following summarizes the security considerations for CCMP: 3559 1. The client MUST determine the proper conference server. The 3560 conference server discovery is described in Section 7. 3562 2. The client MUST connect to the proper conference server. The 3563 mechanisms for addressing this security consideration are 3564 described in Section 10.1. 3566 3. The protocol MUST support a confidentiality and integrity 3567 mechanism. As described in Section 9, implementations of CCMP 3568 MUST implement the HTTP transport over TLS [RFC2818]. 3570 4. There are security issues associated with the authorization to 3571 perform actions on the conferencing system to invoke specific 3572 capabilities. A conference server SHOULD ensure that only 3573 authorized entities can manipulate the conference data. The 3574 mechanisms for addressing this security consideration are 3575 described in Section 10.2. 3577 5. The privacy and security of the identity of a user in the 3578 conference MUST be assured. The mechanisms to ensure the 3579 security and privacy of identity are discussed in Section 10.3. 3581 6. A final issue is related to Denial of Service (DoS) attacks on 3582 the conferencing server itself. The recommendations to minimize 3583 the potential and impact of DoS attacks are discussed in 3584 Section 10.4. 3586 Of the considerations listed above, items 1 and 3 are addressed 3587 within the referenced sections earlier in this document. The 3588 remaining security considerations are addressed in detail in the 3589 following sections. 3591 10.1. Assuring that the Proper Conferencing Server has been contacted 3593 Section 7 describes a mechanism using DNS by which a conference 3594 client discovers a conference server. A primary concern is spoofed 3595 DNS replies, thus the use of DNSSEC is RECOMMENDED to ensure that the 3596 client receives a valid response from the DNS server in cases where 3597 this is a concern. 3599 When the CCMP transaction is conducted using TLS [RFC5246], the 3600 conference server can authenticate its identity, either as a domain 3601 name or as an IP address, to the conference client by presenting a 3602 certificate containing that identifier as a subjectAltName (i.e., as 3603 an iPAddress or dNSName, respectively). Any implementation of CCMP 3604 MUST be capable of being transacted over TLS so that the client can 3605 request the above authentication. Note that in order for the 3606 presented certificate to be valid at the client, the client MUST be 3607 able to validate the certificate following the procedures in 3608 [RFC2818] in the case of HTTP as a transport. In particular, the 3609 validation path of the certificate must end in one of the client's 3610 trust anchors, even if that trust anchor is the conference server 3611 certificate itself. If the client has external information as to the 3612 expected identity or credentials of the proper conference server, the 3613 authentication checks described above MAY be omitted. 3615 10.2. User Authentication and Authorization 3617 Many policy authorization decisions are based on the identity of the 3618 user or the role that a user may have. The conferencing server MUST 3619 implement mechanisms for authentication of users to validate their 3620 identity. There are several ways that a user might authenticate its 3621 identity to the system. For users joining a conference using one of 3622 the call signaling protocols, the user authentication mechanisms for 3623 the specific protocol can be used. For example, in the case of a 3624 user joining the conference using SIP signaling, the user 3625 authentication as defined in [RFC3261] MUST be used. For the case of 3626 users joining the conference using the CCMP, the CCMP Request 3627 messages provide a subject field which contains a username and 3628 password, which can be used for authentication. Since the CCMP 3629 messages are RECOMMENDED to be carried over TLS, this information can 3630 be sent securely. 3632 The XCON Framework [RFC5239] provides an overview of other 3633 authorization mechanisms. In the cases where a user is authorized 3634 via multiple mechanisms, it is RECOMMENDED that the conference server 3635 associate the authorization of the CCMP interface with other 3636 authorization mechanisms - e.g., PSTN users that join with a PIN and 3637 control the conference using CCMP. When a conference server presents 3638 the identity of authorized users, it MAY provide information about 3639 the way the identity was proven or verified by the system. A 3640 conference server can also allow a completely unauthenticated user 3641 into the system - this information SHOULD also be communicated to 3642 interested parties. 3644 Once a user is authenticated and authorized through the various 3645 mechanisms available on the conference server, the conference server 3646 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3647 associate the XCON-USERID with any signaling specific user 3648 identifiers that were used for authentication and authorization. 3649 This XCON-USERID can be provided to a specific user through the 3650 conference notification interface and MUST be provided to users that 3651 interact with the conferencing system using the CCMP (i.e., in the 3652 appropriate CCMP response messages). The XCON-USERIDs for each user/ 3653 participant in the conference are contained in the "entity" attribute 3654 in the "user" element in the conference object. The XCON-USERID is 3655 REQUIRED for any subsequent operations by the user on the conference 3656 object and is carried in the confUserID parameter in the CCMP 3657 requests and responses. 3659 Note that the policy management of an XCON-compliant conference 3660 system is out of the scope of this document, as well as of the XCON 3661 WG. However, the specification of a policy management framework is 3662 realizable with the overall XCON architecture, in particular with 3663 regards to a Role Based Access Control (RBAC) approach. In RBAC, the 3664 following elements are identified: (i) Users; (ii) Roles; (iii) 3665 Objects; (iv) Operations; (v) Permissions. For all of the above 3666 elements a direct mapping exists onto the main XCON entities. As an 3667 example, RBAC objects map onto XCON data model objects and RBAC 3668 operations map onto CCMP operations. 3670 Future documents can define an RBAC framework for XCON, by first 3671 focusing on the definition of roles and then specifying the needed 3672 permission policy sets and role policy sets (used to associate policy 3673 permission sets with specific roles). With these policies in place, 3674 access to a conference object compliant with the XCON data model can 3675 be appropriately controlled. As far as assigning users to roles, the 3676 Users in the RBAC model relate directly to the "users" element in the 3677 conference object. The "users" element is comprised of "user" 3678 elements representing a specific user in the conferencing system. 3679 Each "user" element contains an "entity" attribute with the XCON- 3680 USERID and a "role" element. Thus, each authorized user (as 3681 represented by an XCON-USERID) can be associated with a "role" 3682 element. 3684 10.3. Security and Privacy of Identity 3686 An overview of the required privacy and anonymity for users of a 3687 conferencing system are provided in the XCON Framework [RFC5239]. 3688 The security of the identity in the form of the XCON-USERID is 3689 provided in the CCMP protocol through the use of TLS. 3691 The conference server SHOULD support the mechanism to ensure the 3692 privacy of the XCON-USERID. The conference client indicates the 3693 desired level of privacy by manipulation of the "provide-anonymity" 3694 element defined in the XCON data model 3695 ([I-D.ietf-xcon-common-data-model]. The "provide-anonymity" element 3696 controls the degree to which a user reveals their identity. The 3697 following summarizes the values for the "provide-anonymity" element 3698 that the client includes in their requests: 3700 "hidden": Ensures that other participants are not aware that there 3701 is an additional participant (i.e., the user issuing the request) 3702 in the conference. This could be used in cases of users that are 3703 authorized with a special role in a conference (e.g., a supervisor 3704 in a call center environment). 3706 "anonymous": Ensures that other participants are aware that there 3707 is another participant (i.e., the user issuing the request), 3708 however, the other participants are not provided information as to 3709 the identity of the user. 3711 "semi-private": Ensures that the user's identity is only to be 3712 revealed to other participants or users that have a higher level 3713 authorization (e.g., a conferencing system can be configured such 3714 that a human administrator can see all users). 3716 If the client desires privacy, the conference client SHOULD include 3717 the "provide-anonymity" element in the "confInfo" parameter in a CCMP 3718 confRequest message with an "update" or "create" operation or in the 3719 "userInfo" parameter in a CCMP userRequest message with an "update" 3720 or "create" operation. If the "provide-anonymity" element is not 3721 included in the conference object, then other users can see the 3722 participant's identity. Participants are made aware of other 3723 participants that are "anonymous" or "semi-private" when they perform 3724 subsequent operations on the conference object or retrieve the 3725 conference object or when they receive subsequent notifications. 3727 Note, that independent of the level of anonymity requested by the 3728 user, the identity of the user is always known by the conferencing 3729 system as that is required to perform the necessary authorization as 3730 described in Section 10.2. The degree to which human administrators 3731 can see the information can be controlled using policies (e.g., some 3732 information in the data model can be hidden from human 3733 administrators). 3735 10.4. Mitigating DoS Attacks 3737 [RFC4732] provides an overview of possible DoS attacks. In order to 3738 minimize the potential for DoS attacks, it is RECOMMENDED that 3739 conferencing systems require user authentication and authorization 3740 for any client participating in a conference. This can be 3741 accomplished through the use of the mechanisms described in 3742 Section 10.2, as well as by using the security mechanisms associated 3743 with the specific signaling (e.g., SIPS) and media protocols (e.g., 3744 SRTP). In addition, Section 4.4 describes the use of a timer 3745 mechanism to alleviate the situation whereby CCMP messages pend 3746 indefinitely, thus increasing the potential that pending requests 3747 continue to increase when is a server is receiving more requests than 3748 it can process. 3750 11. XML Schema 3752 This section gives the XML Schema Definition 3753 [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the 3754 "application/ccmp+xml" format. This is presented as a formal 3755 definition of the "application/ccmp+xml" format. A new XML 3756 namespace, a new XML schema, and the MIME type for this schema are 3757 registered with IANA as described in Section 12. Note that this XML 3758 Schema Definition is not intended to be used with on-the-fly 3759 validation of the presence XML document. Whitespaces are included in 3760 the schema to conform to the line length restrictions of the RFC 3761 format without having a negative impact on the readability of the 3762 document. Any conforming processor should remove leading and 3763 trailing white spaces. 3765 3767 3776 3778 3781 3782 3784 3786 3787 3788 3790 3791 3793 3795 3797 3798 3800 3802 3804 3806 3808 3810 3811 3812 3814 3816 3817 3818 3820 3821 3823 3824 3825 3826 3828 3830 3833 3836 3838 3840 3842 3843 3844 3846 3848 3850 3851 3852 3853 3854 3855 3856 3857 3858 3860 3862 3864 3865 3866 3868 3870 3871 3873 3875 3877 3878 3879 3880 3881 3882 3883 3884 3885 3887 3889 3891 3892 3893 3895 3897 3898 3899 3901 3903 3904 3905 3906 3907 3908 3909 3910 3911 3913 3915 3917 3918 3919 3922 3924 3925 3926 3928 3930 3931 3932 3933 3934 3935 3936 3937 3938 3940 3942 3944 3945 3946 3948 3950 3951 3952 3954 3956 3957 3958 3959 3960 3961 3962 3963 3964 3966 3968 3969 3970 3971 3973 3975 3976 3977 3979 3981 3982 3983 3984 3985 3986 3987 3988 3989 3991 3993 3995 3996 3997 3999 4001 4002 4003 4005 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4018 4021 4022 4023 4025 4027 4028 4029 4031 4033 4034 4035 4036 4037 4038 4039 4040 4041 4043 4045 4048 4049 4050 4052 4054 4055 4056 4058 4060 4061 4062 4063 4064 4065 4066 4067 4068 4070 4072 4075 4076 4077 4079 4081 4082 4083 4085 4087 4088 4089 4090 4091 4092 4093 4094 4095 4097 4099 4102 4103 4104 4106 4108 4109 4110 4111 4113 4114 4115 4116 4117 4118 4119 4120 4121 4123 4125 4127 4128 4129 4131 4133 4134 4136 4138 4139 4140 4141 4142 4143 4145 4147 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4160 4162 4163 4164 4166 4168 4169 4170 4172 4174 4175 4176 4177 4178 4179 4180 4181 4182 4184 4186 4188 4189 4190 4192 4194 4195 4196 4198 4200 4201 4202 4203 4204 4205 4207 4208 4209 4211 4213 4215 4216 4217 4219 4221 4222 4223 4225 4227 4228 4229 4230 4231 4232 4233 4234 4235 4237 4239 4241 4242 4243 4245 4247 4248 4249 4251 4253 4254 4255 4256 4257 4258 4259 4260 4261 4263 4265 4267 4268 4269 4271 4273 4274 4275 4277 4279 4280 4281 4282 4283 4284 4285 4286 4287 4289 4291 4293 4294 4295 4297 4299 4300 4301 4302 4304 4305 4306 4307 4308 4309 4310 4311 4312 4314 4316 4319 4320 4321 4323 4325 4326 4327 4329 4331 4332 4333 4334 4335 4336 4337 4338 4339 4341 4343 4346 4347 4348 4351 4353 4354 4355 4357 4359 4360 4361 4362 4363 4364 4365 4366 4367 4369 4371 4374 4375 4376 4378 4380 4381 4382 4384 4386 4387 4388 4389 4390 4391 4392 4393 4394 4396 4398 4401 4402 4403 4405 4407 4408 4409 4411 4413 4414 4415 4416 4417 4418 4419 4420 4421 4423 4425 4427 4428 4429 4431 4434 4435 4437 4439 4440 4441 4442 4443 4444 4445 4446 4448 4450 4452 4455 4456 4457 4459 4461 4462 4463 4465 4467 4469 4470 4471 4472 4473 4475 4477 4478 4479 4480 4481 4482 4483 4484 4486 4488 4489 4490 4492 4494 4497 4498 4499 4501 4503 4504 4505 4508 4511 4513 4514 4515 4517 4519 4520 4521 4524 4526 4527 4528 4530 4532 4533 4534 4537 4540 4541 4542 4544 4545 4546 4548 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4565 4567 4568 4569 4571 4572 4573 4575 4577 4578 4579 4582 4584 4585 4586 4588 4590 4591 4592 4593 4596 4597 4600 4602 4603 4604 4606 4608 Figure 30 4610 12. IANA Considerations 4612 This document registers a new XML namespace, a new XML schema, and 4613 the MIME type for the schema. This document also registers the 4614 "XCON" Application Service tag and the "CCMP" Application Protocol 4615 tag. This document also defines registries for the CCMP operation 4616 types and response codes. 4618 12.1. URN Sub-Namespace Registration 4620 This section registers a new XML namespace, 4621 ""urn:ietf:params:xml:ns:xcon-ccmp"". 4623 URI: "urn:ietf:params:xml:ns:xcon-ccmp" 4625 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4626 Mary Barnes (mary.ietf.barnes@gmail.com). 4628 XML: 4630 BEGIN 4631 4632 4634 4635 4636 CCMP Messages 4637 4638 4639

Namespace for CCMP Messages

4640

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

4641 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4642 with the RFC number for this specification.]] 4643

See RFCXXXX.

4644 4645 4646 END 4648 12.2. XML Schema Registration 4650 This section registers an XML schema as per the guidelines in 4651 [RFC3688]. 4653 URI: urn:ietf:params:xml:schema:xcon-ccmp 4655 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4656 Barnes (mary.ietf.barnes@gmail.com). 4658 Schema: The XML for this schema can be found as the entirety of 4659 Section 11 of this document. 4661 12.3. MIME Media Type Registration for 'application/ccmp+xml' 4663 This section registers the "application/ccmp+xml" MIME type. 4665 To: ietf-types@iana.org 4667 Subject: Registration of MIME media type application/ccmp+xml 4669 MIME media type name: application 4671 MIME subtype name: ccmp+xml 4673 Required parameters: (none) 4674 Optional parameters: charset 4675 Same as the charset parameter of "application/xml" as specified in 4676 RFC 3023 [RFC3023], Section 3.2. 4678 Encoding considerations: Same as the encoding considerations of 4679 "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. 4681 Security considerations: This content type is designed to carry 4682 protocol data related to conference control. Some of the data 4683 could be considered private. This media type does not provide any 4684 protection and thus other mechanisms such as those described in 4685 Section 10 are required to protect the data. This media type does 4686 not contain executable content. 4688 Interoperability considerations: None. 4690 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 4691 replace XXXX with the RFC number for this specification.]] 4693 Applications which use this media type: Centralized Conferencing 4694 control clients and servers. 4696 Additional Information: Magic Number(s): (none) 4697 File extension(s): .ccmp 4698 Macintosh File Type Code(s): TEXT 4700 Person & email address to contact for further information: Mary 4701 Barnes 4703 Intended usage: LIMITED USE 4705 Author/Change controller: The IETF 4707 Other information: This media type is a specialization of 4708 application/xml [RFC3023], and many of the considerations 4709 described there also apply to application/ccmp+xml. 4711 12.4. DNS Registrations 4713 Section 12.4.1 defines an Application Service tag of "XCON", which is 4714 used to identify the centralized conferencing (XCON) server for a 4715 particular domain. The Application Protocol tag "CCMP", defined in 4716 Section 12.4.2, is used to identify an XCON server that understands 4717 the CCMP protocol. 4719 12.4.1. Registration of a Conference Control Server Application Service 4720 Tag 4722 This section registers a new S-NAPTR/U-NAPTR Application Service tag 4723 for XCON, as mandated by [RFC3958]. 4725 Application Service Tag: XCON 4727 Intended usage: Identifies a server that supports centralized 4728 conferencing. 4730 Defining publication: RFCXXXX 4732 Contact information: The authors of this document 4734 Author/Change controller: The IESG 4736 12.4.2. Registration of a Conference Control Server Application 4737 Protocol Tag for CCMP 4739 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 4740 for the CCMP protocol, as mandated by [RFC3958]. 4742 Application Service Tag: CCMP 4744 Intended Usage: Identifies the Centralized Conferencing (XCON) 4745 Manipulation Protocol. 4747 Applicable Service Tag(s): XCON 4749 Terminal NAPTR Record Type(s): U 4751 Defining Publication: RFCXXXX 4753 Contact Information: The authors of this document 4755 Author/Change Controller: The IESG 4757 12.5. CCMP Protocol Registry 4759 This document requests that the IANA create a new registry for the 4760 CCMP protocol: http://www.iana.org/assignments/ccmp-parameters. The 4761 document creates initial sub-registries for CCMP operation types and 4762 response codes." 4764 12.5.1. CCMP Message Types 4766 The following summarizes the requested registry for CCMP Messages: 4768 Related Registry: CCMP Message Types Registry 4770 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4771 with the RFC number for this specification.] 4773 Registration/Assignment Procedures: Following the policies outlined 4774 in [RFC5226], the IANA policy for assigning new values for the 4775 CCMP message types for CCMP shall be Specification Required. 4777 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4778 Barnes (mary.ietf.barnes@gmail.com). 4780 This specification establishes the Message sub-registry under 4781 http://www.iana.org/assignments/ccmp-messages. The initial Message 4782 table is populated using the CCMP messages described in Section 4.1 4783 and defined in the XML schema in Section 11. 4785 Message Description Reference 4786 ------- ----------- --------- 4787 optionsRequest Used by a conference control client [RFCxxxx] 4788 to query a conference server for 4789 its capabilities, in terms of 4790 supported messages. 4792 optionsResponse Returns a list of CCMP messages [RFCxxxx] 4793 supported by the specific 4794 conference server. 4796 blueprintsRequest Used by a conference control client [RFCxxxx] 4797 to query a conferencing system for 4798 its capabilities, in terms of 4799 available conference blueprints. 4801 blueprintsResponse The blueprintsResponse returns a [RFCxxxx] 4802 list of blueprints supported 4803 by the specific conference server. 4805 confsRequest Used by a conference control client [RFCxxxx] 4806 to query a conference server for 4807 its scheduled/active conferences. 4809 confsResponse Returns the list of the currently [RFCxxxx] 4810 activated/scheduled conferences 4811 at the server. 4813 confRequest Used to create a conference object [RFCxxxx] 4814 and/or to request an operation on 4815 the conference object as a whole. 4817 confResponse Indicates the result of the operation [RFCxxxx] 4818 on the conference object as a whole. 4820 userRequest Used to request an operation on the [RFCxxxx] 4821 "user" element in the conference object. 4823 userResponse Indicates the result of the requested [RFCxxxx] 4824 operation on the "user" element in 4825 the conference object. 4827 usersRequest Used to manipulate the "users" element [RFCxxxx] 4828 in the conference object, including 4829 parameters such as the "allowed-users-list", 4830 "join-handling", etc. 4832 usersResponse Indicates the result of the request to [RFCxxxx] 4833 manipulate the "users" element in the 4834 conference object. 4836 sidebarsByValRequest Used to retrieve the "sidebars-by-val" [RFCxxxx] 4837 element of the target conference object. 4839 sidebarsByValResponse Returns the list of the sidebar-by-val [RFCxxxx] 4840 conferences within the target conference 4841 object. 4843 sidebarsByRefRequest Used to retrieve the "sidebars-by-ref" [RFCxxxx] 4844 element of the target conference object. 4846 sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFCxxxx] 4847 conferences associated with the target 4848 conference object. 4850 sidebarByValRequest Used to request an operation on a [RFCxxxx] 4851 sideber-by-val conference. 4853 sidebarByValResponse Indicates the result of the request to [RFCxxxx] 4854 manipulate a sidebar-by-val conference. 4856 sidebarByRefRequest Used to request an operation on a [RFCxxxx] 4857 sideber-by-ref conference. 4859 sidebarByRefResponse Indicates the result of the request to [RFCxxxx] 4860 manipulate a sidebar-by-ref conference. 4862 12.5.2. CCMP Response Codes 4864 The following summarizes the requested registry for CCMP Response 4865 codes: 4867 Related Registry: CCMP Response Code Registry 4869 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4870 with the RFC number for this specification.] 4872 Registration/Assignment Procedures: Following the policies outlined 4873 in [RFC5226], the IANA policy for assigning new values for the 4874 Response codes for CCMP shall be Specification Required. 4876 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4877 Barnes (mary.ietf.barnes@gmail.com). 4879 This specification establishes the Response-code sub-registry under 4880 http://www.iana.org/assignments/ccmp-parameters. The initial 4881 Response-code table is populated using the Response codes defined in 4882 Section 5.4 as follows: 4884 Default 4885 Response 4886 Number String Description Reference 4887 ------ ------------- ------------ --------- 4888 200 Success The request was successfully [RFCxxxx] 4889 processed. 4891 400 Bad Request The request was badly formed in [RFCxxxx] 4892 some fashion. 4894 401 Unauthorized The user was not authorized for [RFCxxxx] 4895 the specific operation on the 4896 conference object. 4898 403 Forbidden The specific operation is not [RFCxxxx] 4899 valid for the target conference 4900 object. 4902 404 Object Not Found The specific conference object [RFCxxxx] 4903 was not found. 4905 409 Conflict A requested operation cannot be [RFCxxxx] 4906 successfully completed by the 4907 server. For example, the 4908 modification of an object 4909 cannot be applied because 4910 the client version of the object 4911 is obsolete and the requested 4912 modifications collide with the 4913 up-to-date state of the object 4914 stored at the server. 4916 420 User Not Found The user who is the target of the [RFCxxxx] 4917 requested operation is unknown. 4919 421 Invalid confUserID The "confUserID" of the sender [RFCxxxx] 4920 in the request is invalid. 4922 422 Invalid Conference A request to access/manipulate [RFCxxxx] 4923 Password a password-protected conference 4924 object contained an invalid 4925 "conference-password" parameter. 4927 423 Conference Password A request to access/manipulate [RFCxxxx] 4928 Required a password-protected conference 4929 object did not contain a 4930 "conference-password" parameter. 4932 424 Authentication The server wants to authenticate [RFCxxxx] 4933 Required the request through the "subject" 4934 parameter but the parameter is 4935 not provided in the request. 4937 425 Forbidden Delete The conferencing system cannot [RFCxxxx] 4938 Parent system cannot delete the specific 4939 conference object because it is a 4940 parent for another conference object. 4942 426 Forbidden Change The target conference object [RFCxxxx] 4943 Protected cannot be changed (e.g., due to 4944 policies, roles or privileges). 4946 427 Invalid Domain Name The domain name in an [RFCxxxx] 4947 AUTO_GENERATE_X 4948 instance in the conference object 4949 is not within the conference 4950 server's domain of responsibility. 4952 500 Server Internal The conference server experienced [RFCxxxx] 4953 Error some sort of internal error. 4955 501 Not Implemented The specific operation is not [RFCxxxx] 4956 implemented on the conferencing 4957 system. 4959 510 Request Timeout The request could not be [RFCxxxx] 4960 processed within a reasonable 4961 time (as specified by the 4962 conferencing system). 4964 511 Resources Not The conference server cannot [RFCxxxx] 4965 Available execute a command because of 4966 resource issues, e.g. it cannot 4967 create a conference because 4968 the system has reached its limits 4969 on the number of conferences. 4971 13. Acknowledgments 4973 The authors appreciate the feedback provided by Dave Morgan, Pierre 4974 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 4975 Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage, 4976 Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian 4977 Carpenter (genart review) and Mykyta Yevstifeyev (IANA 4978 considerations). Special thanks go to Roberta Presta for her 4979 invaluable contribution to this document. Roberta has worked on the 4980 specification of the CCMP protocol at the University of Napoli for 4981 the preparation of her Master thesis. She has also implemented the 4982 CCMP prototype used for the trials and from which the dumps provided 4983 in Section 6 have been extracted. 4985 14. References 4987 14.1. Normative References 4989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4990 Requirement Levels", BCP 14, RFC 2119, March 1997. 4992 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4993 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4994 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4996 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 4997 Leach, P., Luotonen, A., and L. Stewart, "HTTP 4998 Authentication: Basic and Digest Access Authentication", 4999 RFC 2617, June 1999. 5001 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 5003 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 5004 April 2011. 5006 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5007 January 2004. 5009 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 5010 Centralized Conferencing", RFC 5239, June 2008. 5012 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5013 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 5015 [I-D.ietf-xcon-common-data-model] 5016 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 5017 "Conference Information Data Model for Centralized 5018 Conferencing (XCON)", draft-ietf-xcon-common-data-model-31 5019 (work in progress), June 2011. 5021 [W3C.REC-xmlschema-1-20041028] 5022 Mendelsohn, N., Thompson, H., Maloney, M., and D. Beech, 5023 "XML Schema Part 1: Structures Second Edition", World Wide 5024 Web Consortium Recommendation REC-xmlschema-1-20041028, 5025 October 2004, 5026 . 5028 [W3C.REC-xmlschema-2-20041028] 5029 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 5030 Second Edition", World Wide Web Consortium 5031 Recommendation REC-xmlschema-2-20041028, October 2004, 5032 . 5034 14.2. Informative References 5036 [REST] Fielding, "Architectural Styles and the Design of Network- 5037 based Software Architectures", 2000. 5039 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 5040 Types", RFC 3023, January 2001. 5042 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 5043 A., Peterson, J., Sparks, R., Handley, M., and E. 5044 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 5045 June 2002. 5047 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 5048 Service Location Using SRV RRs and the Dynamic Delegation 5049 Discovery Service (DDDS)", RFC 3958, January 2005. 5051 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 5052 Control Protocol (BFCP)", RFC 4582, November 2006. 5054 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 5055 Service Considerations", RFC 4732, December 2006. 5057 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5058 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5059 May 2008. 5061 [I-D.ietf-xcon-event-package] 5062 Camarillo, G., Srinivasan, S., Even, R., and J. 5063 Urpalainen, "Conference Event Package Data Format 5064 Extension for Centralized Conferencing (XCON)", 5065 draft-ietf-xcon-event-package-01 (work in progress), 5066 September 2008. 5068 [W3C.REC-soap12-part1-20030624] 5069 Moreau, J., Gudgin, M., Hadley, M., Nielsen, H., and N. 5070 Mendelsohn, "SOAP Version 1.2 Part 1: Messaging 5071 Framework", World Wide Web Consortium FirstEdition REC- 5072 soap12-part1-20030624, June 2003, 5073 . 5075 [W3C.REC-soap12-part2-20030624] 5076 Moreau, J., Mendelsohn, N., Nielsen, H., Hadley, M., and 5077 M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 5078 Web Consortium FirstEdition REC-soap12-part2-20030624, 5079 June 2003, 5080 . 5082 Appendix A. Appendix A: Evaluation of other protocol models and 5083 transports considered for CCMP 5085 This section provides some background as to the selection of HTTP as 5086 the transport for the CCMP requests/responses. In addition to HTTP, 5087 the operations on the objects can be implemented in at least two 5088 different ways, namely as remote procedure calls - using SOAP as 5089 described in Appendix A.1 and by defining resources following a 5090 RESTful architecture Appendix A.2. 5092 In both the SOAP and RESTFUL approaches, servers will have to 5093 recreate their internal state representation of the object with each 5094 update request, checking parameters and triggering function 5095 invocations. In the SOAP approach, it would be possible to describe 5096 a separate operation for each atomic element, but that would greatly 5097 increase the complexity of the protocol. A coarser-grained approach 5098 to the CCMP does require that the server process XML elements in 5099 updates that have not changed and that there can be multiple changes 5100 in one update. For CCMP, the resource (REST) model might appear more 5101 attractive, since the conference operations fit the CRUD approach. 5103 However, neither of these approaches were considered ideal. SOAP was 5104 considered to bring additional overhead. It is quite awkward to 5105 apply a RESTful approach since the CCMP requires a more complex 5106 request/response protocol in order to maintain the data both in the 5107 server and at the client. This doesn't map very elegantly to the 5108 basic request/response model, whereby a response typically indicates 5109 whether the request was successful or not, rather than providing 5110 additional data to maintain the synchronization between the client 5111 and server data. In addition, the CCMP clients may also receive the 5112 data in Notifications. While the notification method or protocol 5113 used by some conferencing clients can be independent of the CCMP, the 5114 same data in the server is used for both the CCMP and Notifications - 5115 this requires a server application above the transport layer (e.g., 5116 HTTP) for maintaining the data, which in the CCMP model is 5117 transparent to the transport protocol. 5119 Thus, the solution for the CCMP defined in this document is viewed as 5120 a good compromise amongst the most notable past candidates and is 5121 referred to as "HTTP single-verb transport plus CCMP body". With 5122 this approach, CCMP is able to take advantage of existing HTTP 5123 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 5124 transport (i.e. a single transaction type for each request/response 5125 pair); this allows decoupling CCMP messages from HTTP messages. 5126 Similarly, as with any RESTful approach, CCMP messages are inserted 5127 directly in the body of HTTP messages, thus avoiding any unnecessary 5128 processing and communication burden associated with further 5129 intermediaries. With this approach, no modification to the CCMP 5130 messages/operations is required to use a different transport 5131 protocol. 5133 A.1. Using SOAP for the CCMP 5135 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 5136 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 5137 -soap12-part2-20030624]), where conferences and the other objects are 5138 modeled as services with associated operations. Conferences and 5139 other objects are selected by their own local identifiers, such as 5140 email-like names for users. This approach has the advantage that it 5141 can easily define atomic operations that have well-defined error 5142 conditions. 5144 All SOAP operations would use a single HTTP verb. While the RESTful 5145 approach requires the use of a URI for each object, SOAP can use any 5146 token. 5148 A.2. A RESTful approach for the CCMP 5150 Conference objects can also be modeled as resources identified by 5151 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 5152 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 5153 changing objects and DELETE for deleting them. Many of the objects, 5154 such as conferences, already have natural URIs. 5156 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 5157 design pattern. The basic CRUD operations are used to manipulate 5158 conference objects, which are XML documents containing the 5159 information characterizing a specified conference instance, be it an 5160 active conference or a conference blueprint used by the conference 5161 server to create new conference instances through a simple clone 5162 operation. 5164 Following the CRUD approach, CCMP could use a general-purpose 5165 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 5166 encoded data objects defined in the Conference Information Data Model 5167 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 5169 Following on the CRUD approach, CCMP could follow the well-known REST 5170 (REpresentational State Transfer) architectural style [REST]. The 5171 CCMP could map onto the REST philosophy, by specifying resource URIs, 5172 resource formats, methods supported at each URI and status codes that 5173 have to be returned when a certain method is invoked on a specific 5174 URI. A REST-style approach must ensure sure that all operations can 5175 be mapped to HTTP operations. 5177 The following summarizes the specific HTTP method that could be used 5178 for each of the CCMP Requests: 5180 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 5181 obtain data about conference objects in the form of XML data model 5182 documents. 5184 Create: HTTP PUT could be used to create a new object as identified 5185 by the XCON-URI or XCON-USERID. 5187 Change: Either HTTP PATCH or HTTP POST could be used to change the 5188 conference object identified by the XCON-URI. 5190 Delete: HTTP DELETE could be used to delete conference objects and 5191 parameters within conference objects identified by the XCON-URI. 5193 Authors' Addresses 5195 Mary Barnes 5196 Polycom 5197 TX 5198 US 5200 Email: mary.ietf.barnes@gmail.com 5202 Chris Boulton 5203 NS-Technologies 5205 Email: chris@ns-technologies.com 5207 Simon Pietro Romano 5208 University of Napoli 5209 Via Claudio 21 5210 Napoli 80125 5211 Italy 5213 Email: spromano@unina.it 5215 Henning Schulzrinne 5216 Columbia University 5217 Department of Computer Science 5218 450 Computer Science Building 5219 New York, NY 10027 5221 Email: hgs+xcon@cs.columbia.edu