idnits 2.17.1 draft-ietf-xcon-ccmp-15.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 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 (August 3, 2011) is 4643 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 4473, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 4966, 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 (~~), 5 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: February 4, 2012 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 August 3, 2011 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-15 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 February 4, 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. An 756 entity MUST support the response message for each of the request 757 messages that are supported. The corresponding response message MUST 758 contain the same operation. Note that some entries are labeled "N/A" 759 indicating the operation is invalid for that request type. In the 760 case of an "N/A*", the operation MAY be allowed for specific 761 privileged users or system administrators, but is not part of the 762 functionality included in this document. 764 +---------------+------------+------------+------------+------------+ 765 | Operation | Retrieve | Create | Update | Delete | 766 | ------------- | | | | | 767 | Request Type | | | | | 768 +---------------+------------+------------+------------+------------+ 769 | blueprints | Get list | N/A | N/A | N/A | 770 | Request | of | | | | 771 | | blueprints | | | | 772 | ------------- | ---------- | ---------- | ---------- | ---------- | 773 | blueprint | Get | N/A* | N/A* | N/A* | 774 | Request | blueprint | | | | 775 | ------------- | ---------- | ---------- | ---------- | ---------- | 776 | confsRequest | Get list | N/A | N/A | N/A | 777 | | of confs | | | | 778 | ------------- | ---------- | ---------- | ---------- | ---------- | 779 | confRequest | Gets | Creates | Changes | Deletes | 780 | | conference | conference | conference | conference | 781 | | object | object | object | object | 782 | ------------- | ---------- | ---------- | ---------- | ---------- | 783 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 784 | | | | | | 785 | ------------- | ---------- | ---------- | ---------- | ---------- | 786 | userRequest | Gets | Adds a | Changes | Deletes | 787 | | specified | to | specified | specified | 788 | | | a conf | | | 789 | | | (***) | | | 790 | ------------- | ---------- | ---------- | ---------- | ---------- | 791 | sidebarsByVal | Gets | N/A | N/A | N/A | 792 | Request | | | | | 794 | ------------- | ---------- | ---------- | ---------- | ---------- | 795 | sidebarsByRef | Gets | N/A | N/A | N/A | 796 | Request | | | | | 798 | ------------- | ---------- | ---------- | ---------- | ---------- | 799 | sidebarByVal | Gets | Creates | Changes | Deletes | 800 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 801 | | by-val | by-val | by-val | by-val | 802 | ------------- | ---------- | ---------- | ---------- | ---------- | 803 | sidebarByRef | Gets | Creates | Changes | Deletes | 804 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 805 | | by-ref | by-ref | by-ref | by-ref | 806 +---------------+------------+------------+------------+------------+ 808 Table 1: Request Type Operation Specific Processing 810 (**): These operations are not allowed for a usersRequest message, 811 since the section, which is the target element of such a 812 request, is created and removed in conjunction with, respectively, 813 the creation and deletion of the associated conference document. 814 Thus, "update" and "retrieve" are the only semantically correct 815 operations for such message. 817 (***): This operation can involve the creation of an XCON-USERID, if 818 the sender does not add it in the "confUserID" parameter, and/or if 819 the "entity" field of the "userInfo" parameter is void. 821 Additional parameters included in the specialized CCMP request/ 822 response messages are detailed in the subsequent sections. If a 823 required parameter is not included in a request, the conference 824 server MUST return a 400 response code per Section 5.4. 826 5.3.1. blueprintsRequest and blueprintsResponse 828 A "blueprintsRequest" (Figure 4) message is sent to request the list 829 of XCON-URIs associated with the available blueprints from the 830 conference server. These XCON-URIs can be subsequently used by the 831 client to access detailed information about a specified blueprint 832 with a specific blueprintRequest message per Section 5.3.3. 834 The "confUserID" parameter MUST be included in every 835 blueprintsRequest/Response message and reflect the XCON-USERID of the 836 conferencing client issuing the request. Since a blueprintsRequest 837 message is not targetted to a specific conference instance and is a 838 "retrieve-only" request, the "confObjID" and "operation" MUST NOT be 839 included in the blueprintsRequest/Response messages. 841 In order to obtain a specific subset of the available blueprints, a 842 client may specify a selection filter providing an appropriate xpath 843 query in the OPTIONAL "xpathFilter" parameter of the request. The 844 information in the blueprints typically represents general 845 capabilities and characteristics. For example, to select blueprints 846 having both audio and video stream support, a possible xpathFilter 847 value could be: "/conference-info[conference-description/ 848 available-media/entry/type='audio' and conference-description/ 849 available-media/entry/type='video']". A conference server SHOULD NOT 850 provide any sensitive information (e.g., passwords) in the 851 blueprints. 853 The associated "blueprintsResponse" message SHOULD contain, as shown 854 in Figure 4, a "blueprintsInfo" parameter containing the above 855 mentioned XCON-URI list. 857 858 859 860 861 862 863 864 865 866 868 870 872 873 874 875 877 878 879 881 883 884 885 886 887 888 889 890 891 893 895 897 898 899 901 903 904 905 906 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 907 messages 909 5.3.2. confsRequest and confsResponse 911 A "confsRequest" message is used to retrieve, from the server, the 912 list of XCON-URIs associated with active and registered conferences 913 currently handled by the conferencing system. The "confUserID" 914 parameter MUST be included in every confsRequest/Response message and 915 reflect the XCON-USERID of the conferencing client issuing the 916 request. The "confObjID" parameter MUST NOT be included in the 917 confsRequest message. The "confsRequest" message is of a "retrieve- 918 only" type, since the sole purpose is to collect information 919 available at the conference server. Thus, an "operation" parameter 920 MUST NOT be included in a "confsRequest" message. In order to 921 retrieve a specific subset of the available conferences, a client may 922 specify a selection filter providing an appropriate xpath query in 923 the OPTIONAL "xpathFilter" parameter of the request. For example, to 924 select only the registered conferences, a possible xpathFilter value 925 could be: "/conference-info[conference-description/conference-state/ 926 active='false']". The associated "confsResponse" message SHOULD 927 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 928 upon receipt of the response message, can interact with the available 929 conference objects through further CCMP messages. 931 933 934 935 936 937 938 939 940 941 943 945 947 948 949 950 952 953 954 956 958 959 960 961 962 963 964 965 966 968 970 972 973 974 976 978 979 980 982 Figure 5: Structure of the confsRequest and confsResponse messages 984 5.3.3. blueprintRequest and blueprintResponse 986 Through a "blueprintRequest", a client can manipulate the conference 987 object associated with a specified blueprint. Further than the 988 "confUserID" parameter, the request MUST include the "confObjID" and 989 the "operation" one. Again, the "confUserID" parameter MUST be 990 included in every blueprintRequest/Response message and reflect the 991 XCON-USERID of the conferencing client issuing the request. The 992 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 993 which might have been previously retrieved through a 994 "blueprintsRequest" message. 996 The blueprintRequest message SHOULD NOT contain an "operation" 997 parameter other than "retrieve". The "create", "update" and "delete" 998 operations SHOULD NOT be included in a "blueprintRequest" message 999 except in the case of privileged users (e.g. the conference server 1000 administration staff), who might authenticate themselves by the mean 1001 of the "subject" request parameter. 1003 A blueprintRequest/retrieve carrying a "confObjID" which is not 1004 associated with one of the available system's blueprints will 1005 generate, on the server's side, a blueprintResponse message 1006 containing a "404" error code. This holds also for the case in which 1007 the mentioned "confObjID" is related to an existing conference 1008 document stored at the server, but associated with an actual 1009 conference (be it active or registered) or with a sidebar rather than 1010 a blueprint. 1012 In the case of "response-code" of "200" for a "retrieve" operation, 1013 the "blueprintInfo" parameter MUST be included in the 1014 "blueprintResponse" message. The "blueprintInfo" parameter contains 1015 the conference document associated with the blueprint as identified 1016 by the "confObjID" parameter specified in the blueprintRequest. 1018 1020 1021 1022 1023 1024 1025 1026 1027 1028 1030 1032 1034 1035 1036 1038 1040 1041 1042 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1055 1057 1059 1060 1061 1063 1065 1066 1067 1069 Figure 6: Structure of the blueprintRequest and blueprintResponse 1070 messages 1072 5.3.4. confRequest and confResponse 1074 With a "confRequest" message, CCMP clients can manipulate conference 1075 objects associated with either active or registered conferences. The 1076 "confUserID" parameter MUST be included in every confRequest/Response 1077 message and reflect the XCON-USERID of the conferencing client 1078 issuing the request. ConfRequest and confResponse messages MUST also 1079 include an "operation" parameter. ConfResponse messages MUST return 1080 to the requestor a "response-code" and MAY contain a "response- 1081 string" explaining it. Depending upon the type of "operation", a 1082 "confObjID" and "confInfo" parameter MAY be included in the 1083 confRequest and response. The requirements for inclusion of 1084 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1085 messages and are detailed below for each "operation" case. 1087 The creation case deserves care. To create a new conference through 1088 a "confRequest" message, two approaches can be considered: 1090 1. Creation through explicit cloning: the "confObjID" parameter MUST 1091 contain the XCON-URI of the blueprint or of the conference to be 1092 cloned, while the "confInfo" parameter MUST NOT be included in 1093 the confRequest. Note that cloning of an active conference is 1094 only done in the case of a sidebar operation per the XCON 1095 framework and as described in Section 5.3.8. 1097 2. Creation through implicit cloning (also known as "direct 1098 creation"): the "confObjID" parameter MUST NOT be included in the 1099 request and the CCMP client can describe the desired conference 1100 to be created using the "confInfo" parameter. If no "confInfo" 1101 parameter is provided in the request, the new conference will be 1102 created as a clone of the system default blueprint. 1104 In both creation cases, the confResponse, for a successful completion 1105 of a "create" operation, contains a response-code of "200" and MUST 1106 contain the XCON-URI of the newly created conference in the 1107 "confObjID" parameter, in order to allow the conferencing client to 1108 manipulate that conference through following CCMP requests. In 1109 addition, the "confInfo" parameter transporting the created 1110 conference document MAY be included, at the discretion of the 1111 conferencing system implementation, along with the REQUIRED "version" 1112 parameter initialized at "1", since at creation time the conference 1113 object is at its first version. 1115 In the case of a confRequest with a "retrieve" operation, the 1116 "confObjID" representing the XCON-URI of the target conference MUST 1117 be included and the "confInfo" parameter MUST NOT be included in the 1118 request. The conferencing server MUST ignore any "confInfo" 1119 parameter that is received in a confRequest/retrieve. If the 1120 confResponse for the "retrieve" operation contains a "response-code" 1121 of "200", the "confInfo" parameter MUST be included in the response. 1122 The "confInfo" parameter MUST contain the entire conference document 1123 describing the target conference object in its current state. The 1124 current state of the retrieved conference object MUST also be 1125 reported in the proper "version" response parameter. 1127 In case of a confRequest with an "update" operation, the "confInfo" 1128 and "confObjID" MUST be included in the request. The "confInfo" 1129 represents an object of type "conference-type" containing all the 1130 changes to be applied to the conference whose identifier is 1131 "confObjID". Note that, in such a case, though the confInfo 1132 parameter has indeed to follow the rules indicated in the XCON data 1133 model, it does not represent the entire updated version of the target 1134 conference, since it rather conveys just the modifications to apply 1135 to that conference. For example, in order to change the conference 1136 title, the confInfo parameter will be of the form: 1138 1139 1140 *** NEW CONFERENCE TITLE *** 1141 1142 1144 Figure 7: Updating a conference object: modifying the title of a 1145 conference 1147 Similarly, to remove the title of an existing conference, a 1148 confRequest/update carrying the following "confInfo" parameter would 1149 do the job.: 1151 1152 1153 1154 1155 1157 Figure 8: Updating a conference object: removing the title of a 1158 conference 1160 In the case of a confResponse/update with a response-code of "200", 1161 no additional information is REQUIRED in the response message, which 1162 means the return of confInfo parameter is OPTIONAL. A subsequent 1163 confRequest/retrieve transaction might provide the CCMP client with 1164 the current aspect of the conference upon the modification, or the 1165 Notification Protocol might address that task as well. A "200" 1166 response-code indicates that the conference object has been changed 1167 accordingly to the request by the conferencing server. The "version" 1168 parameter MUST be enclosed in the confResponse/update message, in 1169 order to let the client understand what is the actual current 1170 conference-object version, upon the applied modifications. An "409" 1171 response-code indicates that the changes reflected in the request 1172 "confInfo" are not feasible. This could be due to policies, 1173 requestor roles, specific privileges, unacceptable values etc., with 1174 the reason specific to a conferencing system and its configuration. 1175 Together with the "409" response-code, the "version" parameter MUST 1176 be attached in the confResponse/update, by this way allowing the 1177 client to eventually retrieve the current version of the target 1178 conference if the one she attempted to modify was not the most up-to- 1179 date. 1181 In the case of a confRequest with a "delete" operation, the 1182 "confObjID" representing the XCON-URI of the target conference MUST 1183 be included while the "confInfo" MUST NOT be included in the request. 1184 The conferencing server MUST ignore any "confInfo" parameter that is 1185 received within such a request. The confResponse MUST contain the 1186 same "confObjID" that was included in the confRequest. If the 1187 confResponse/delete operation contains a "200" response-code, the 1188 conference indicated in the "confObjID" has been successfully 1189 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1190 parameter. The "version" parameter SHOULD NOT be returned in any 1191 confResponse/delete. If the conferencing server cannot delete the 1192 conference referenced by the "confObjID" received in the confRequest 1193 because it is the parent of another conference object that is in use, 1194 the conferencing server MUST return a response-code of "425". 1196 A confRequest with an "operation" of "retrieve", "update" or "delete" 1197 carrying a "confObjID" which is not associated with one of the 1198 conferences (active or registered) the system is holding will 1199 generate, on the server's side, a confResponse message containing a 1200 "404" error code. This holds also for the case in which the 1201 mentioned "confObjID" is related to an existing conference object 1202 stored at the server, but associated with a blueprint or with a 1203 sidebar rather than an actual conference. 1205 The schema for the confRequest/confResponse pair is shown in 1206 Figure 9. 1208 1210 1211 1212 1213 1214 1215 1216 1217 1218 1220 1222 1224 1225 1226 1228 1230 1231 1232 1234 1236 1237 1238 1239 1240 1241 1242 1243 1244 1246 1248 1250 1251 1252 1254 1256 1257 1258 1260 Figure 9: Structure of the confRequest and confResponse messages 1262 5.3.5. usersRequest and usersResponse 1264 The "usersRequest" message allows a client to manipulate the 1265 element of the conference object represented by the "confObjID". The 1266 element contains the list of elements associated with 1267 conference participants, the list of the users to which access to the 1268 conference is allowed/denied, conference participation policies, etc. 1269 The "confObjID" MUST be included in a "usersRequest" message. 1271 A "usersInfo" parameter MAY be included in a usersRequest message 1272 depending upon the operation. If the "usersInfo" parameter is 1273 included in the usersRequest message, the parameter MUST be compliant 1274 with the field of the XCON data model. 1276 Two operations are allowed for a "usersRequest" message: 1278 1. "retrieve": In this case the request MUST NOT include a 1279 "usersInfo" parameter, while the successful response MUST contain 1280 the desired element in the "usersInfo" parameter. The 1281 conference server MUST ignore a "usersInfo" parameter if it is 1282 received in a request with a "retrieve" operation. 1284 2. update: In this case, the "usersInfo" parameter MUST contain the 1285 modifications to be applied to the referred element. If 1286 the "response-code" is "200", then the "usersInfo" parameter 1287 SHOULD NOT be returned. Any "usersInfo" parameter that is 1288 returned SHOULD be ignored. A "response-code" of "426" indicates 1289 that the conferencing client is not allowed to make the changes 1290 reflected in the "usersInfo" contained in the usersRequest 1291 message. This could be due to policies, roles, specific 1292 privileges, etc., with the reason specific to a conferencing 1293 system and its configuration. 1295 Operations of "create" and "delete" are not applicable to a 1296 usersRequest message and MUST NOT be considered by the server, which 1297 means that a "response-code" of "403" MUST be included in the 1298 usersResponse message. 1300 1302 1303 1304 1305 1306 1307 1308 1309 1310 1312 1314 1316 1317 1318 1320 1322 1323 1324 1326 1328 1329 1330 1331 1332 1333 1334 1335 1336 1338 1340 1342 1343 1344 1346 1348 1349 1350 1352 Figure 10: Structure of the usersRequest and usersResponse messages 1354 5.3.6. userRequest and userResponse 1356 A "userRequest" message is used to manipulate elements inside 1357 a conference document associated with a conference identified by the 1358 "confObjID" parameter. Besides retrieving information about a 1359 specific conference user, the message is used to request that the 1360 conference server either create, modify, or delete information about 1361 a user. A "userRequest" message MUST include the "confObjID", the 1362 "operation" parameter, and MAY include a "userInfo" parameter 1363 containing the detailed user's information depending upon the 1364 operation and whether the "userInfo" has already been populated for a 1365 specific user. Note that a user may not necessarily be a 1366 conferencing control client (i.e., some participants in a conference 1367 are not "XCON aware"). 1369 An XCON-USERID SHOULD be assigned to each and every user subscribed 1370 to the system. In such a way, a user who is not a conference 1371 participant can make requests (provided she has successfully passed 1372 authorization and authentication checks), like creating a conference, 1373 retrieving conference information, etc.. 1375 Conference users can be created in a number of different ways. In 1376 each of these cases the operation MUST be set to "create" in the 1377 userRequest message. Each of the userResponse messages for these 1378 cases MUST include the "confObjID", "confUserID", "operation" and 1379 "response-code" parameters. In the case of a response code of "200", 1380 the userResponse message MAY include the "userInfo" parameter 1381 depending upon the manner in which the user was created: 1383 o Conferencing client with an XCON-USERID adds itself to the 1384 conference: In this case, the "userInfo" parameter MAY be included 1385 in the userRequest. The "userInfo" parameter MUST contain a 1386 element (compliant with the XCON data model) and the 1387 "entity" attribute MUST be set to a value which represents the 1388 XCON-USERID of the user initiating the request. No additional 1389 parameters beyond those previously described are required in the 1390 userResponse message, in the case of a "response-code" of "200". 1392 o Conferencing client acts on behalf of a third user whose XCON- 1393 USERID is known: in this case, the "userInfo" parameter MUST be 1394 included in the userRequest. The "userInfo" parameter MUST 1395 contain a element and the "entity" attribute value MUST be 1396 set to the XCON-USERID of the third user in question. No 1397 additional parameters beyond those previously described are 1398 required in the userResponse message, in the case of a "response- 1399 code" of "200". 1401 o A conferencing client who has no XCON-USERID and who wants to 1402 enter, via CCMP, a conference whose identifier is known. In this 1403 case, a side-effect of the request is that the user is provided 1404 with a new XCON-USERID (created by the server) carried inside the 1405 "confUserID" parameter of the response. This is the only case in 1406 which a CCMP request can be valid though carrying a void 1407 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1408 in the request, providing at least a contact URI of the joining 1409 client, in order to let the focus instigate the signaling phase 1410 needed to add her to the conference. The mandatory "entity" 1411 attribute of the "userInfo" parameter in the request MUST be 1412 filled with a fake value with the user part of the XCON-USERID 1413 containing a value of AUTO_GENERATE_X as described in Section 4.3, 1414 to conform to the rules contained in the XCON data model XML 1415 schema. The messages (userRequest and userResponse) in this case 1416 should look like the following: 1418 Request fields: 1420 confUserID=null; 1421 confObjID=confXYZ; 1422 operation=create; 1423 userInfo= 1425 1426 1427 ... 1429 Response fields (in case of success): 1431 confUserID=user345; 1432 confObjID=confXYZ; 1433 operation=create; 1434 response-code=200; 1435 userInfo=null; //or the entire userInfo object 1437 Figure 11: userRequest and userResponse in the absence of an xcon- 1438 userid 1440 o Conferencing client is unaware of the XCON-USERID of a third user: 1441 In this case, the XCON-USERID in the request "confUserID" is the 1442 sender's one and the "entity" attribute of the attached userInfo 1443 is filled with the fake value 1444 "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for 1445 the third user MUST be returned to the client issuing the request 1446 in the "entity" attribute of the response "userInfo" parameter, if 1447 the "response-code" is "200". This scenario is intended to 1448 support both the case where a brand new conferencing system user 1449 is added to a conference by a third party (i.e. a user who is not 1450 yet provided with an XCON-USERID) and the case where the CCMP 1451 client issuing the request does not know the to-be-added user's 1452 XCON-USERID (which means such an identifier could already exist on 1453 the server's side for that user). In this last case, the 1454 conferencing server is in charge of avoiding XCON-URI duplicates 1455 for the same conferencing client, looking at key fields in the 1456 request provided "userInfo" parameter, such as the signalling URI: 1457 if the joining user is a brand new one, then the generation of a 1458 new XCON identifier is needed; otherwise, if that user is an 1459 existing one, the server must recover the corresponding XCON 1460 identifier. 1462 In the case of a userRequest with a "retrieve" operation, the 1463 "confObjID" representing the XCON-URI of the target conference MUST 1464 be included. The "confUserID", containing the CCMP client's xcon- 1465 userid, MUST also be included in the userRequest message. If the 1466 client wants to retrieve information about her profile in the 1467 specified conference, no "userInfo" parameter is needed in the 1468 retrieve request. On the other hand, if the client wants to obtain 1469 someone else's info within the given conference, she MUST include in 1470 the userRequest/retrieve a "userInfo" parameter whose "entity" 1471 attribute conveys the desired user's xcon-userid. If the 1472 userResponse for the "retrieve" operation contains a "response-code" 1473 of "200", the "userInfo" parameter MUST be included in the response. 1475 In case of a userRequest with an "update" operation, the "confObjID", 1476 "confUserID" and "userInfo" MUST be included in the request. The 1477 "userInfo" is of type "user-type" and contains all the changes to be 1478 applied to a specific element in the conference object 1479 identified by the "confObjID" in the userRequest message. The user 1480 to be modified is identified through the "entity" attribute of the 1481 "userInfo" parameter included in the request. In the case of a 1482 userResponse with a "response-code" of "200", no additional 1483 information is required in the "userResponse" message. A "response- 1484 code" of "200" indicates that the referenced user element has been 1485 updated by the conference server. A "response-code" of "426" 1486 indicates that the conferencing client is not allowed to make the 1487 changes reflected in the "userInfo" in the initial request. This 1488 could be due to policies, roles, specific privileges, etc., with the 1489 reason specific to a conferencing system and its configuration. 1491 In the case of a userRequest with a "delete" operation, the 1492 "confObjID" representing the XCON-URI of the target conference MUST 1493 be included. The "confUserID", containing the CCMP client's xcon- 1494 userid, MUST be included in the userRequest message. If the client 1495 wants to exit the specified conference, no "userInfo" parameter is 1496 needed in the delete request. On the other hand, if the client wants 1497 to remove another participant from the given conference, she MUST 1498 include in the userRequest/delete a "userInfo" parameter whose 1499 "entity" attribute conveys the xcon-userid of that participant. The 1500 userResponse MUST contain the same "confObjID" that was included in 1501 the userRequest. The userResponse MUST contain a "response-code" of 1502 "200" if the target element has been successfully deleted. If 1503 the userResponse for the "delete" operation contains a "response- 1504 code" of "200", the userResponse MUST NOT contain the "userInfo" 1505 parameter. 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1518 1520 1522 1523 1524 1526 1528 1529 1530 1532 1534 1535 1536 1537 1538 1539 1540 1541 1542 1544 1546 1548 1549 1550 1552 1554 1555 1557 1559 Figure 12: Structure of the userRequest and userResponse messages 1561 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1563 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1564 on the field of the conference object represented 1565 by the "confObjID". The "sidebarsByValRequest" message is of a 1566 "retrieve-only" type, so an "operation" parameter MUST NOT be 1567 included in a "sidebarsByValRequest" message. As with blueprints and 1568 conferences, also with sidebars, CCMP allows for the use of xpath 1569 filters whenever a selected subset of the sidebars available at the 1570 server's side has to be retrieved by the client. This applies both 1571 to sidebars by reference and to sidebars by value. A 1572 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1573 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1575 the client a "version" element related to the current version of the 1576 main conference object (i.e. the one whose identifier is contained in 1577 the "confObjId" field of the request) to which the sidebars in 1578 question are associated. The "sidebarsByValInfo" parameter contains 1579 the list of the conference objects associated with the sidebars by 1580 value derived from the main conference. The retrieved sidebars can 1581 then be updated or deleted using the "sidebarByValRequest" message, 1582 which is described in Section 5.3.8. 1584 1586 1587 1588 1589 1590 1591 1592 1593 1594 1596 1598 1601 1602 1603 1604 1606 1607 1608 1610 1612 1613 1614 1615 1616 1617 1618 1619 1620 1622 1624 1627 1628 1629 1631 1633 1634 1635 1637 Figure 13: Structure of the sidebarsByValRequest and 1638 sidebarsByValResponse messages 1640 5.3.8. sidebarByValRequest and sidebarByValResponse 1642 A sidebarByValRequest message MUST contain the "operation" parameter 1643 which discriminates among retrieval, creation, modification and 1644 deletion of a specific sidebar. The other required parameters depend 1645 upon the type of operation. 1647 In the case of a "create" operation, the "confObjID" parameter MUST 1648 be included in the sidebyValRequest message. In this case, the 1649 "confObjID" parameter contains the XCON-URI of the main conference in 1650 which the sidebar has to be created. If no "sidebarByValInfo" 1651 parameter is included, as envisaged in the XCON framework 1652 ([RFC5239]), the sidebar is created by cloning the main conference, 1653 following the implementation specific cloning rules. Otherwise, 1654 similarly to the case of direct creation, the sidebar conference 1655 object is built on the basis of the "sidebarByValInfo" parameter 1656 provided by the requestor. As a consequence of a sidebar-by-val 1657 creation, the conference server MUST update the main conference 1658 object reflected by the "confObjID" parameter in the 1659 sidebarbyValRequest/create message introducing the new sidebar object 1660 as a new new in the proper section . The 1661 newly created sidebar conference object MAY be included in the 1662 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1663 "response-code" is "200". The XCON-URI of the newly created sidebar 1664 MUST appear in the "confObjID" parameter of the response. The 1665 conference server can notify any conferencing clients that have 1666 subscribed to the conference event package, and are authorized to 1667 receive the notifications, of the addition of the sidebar to the 1668 conference. 1670 In the case of a "sidebarByVal" request with an operation of 1671 "retrieve", the URI for the conference object created for the sidebar 1672 (received in the response to a "create" operation or in a 1673 sidebarsByValResponse message) MUST be included in the "confObjID" 1674 parameter in the request. This "retrieve" operation is handled by 1675 the conference server in the same manner as a "retrieve" operation 1676 included in a confRequest message as detailed in Section 5.3.4. 1678 In the case of a "sidebarByVal" request with an operation of 1679 "update", the "sidebarByValInfo" MUST also be included in the 1680 request. The "confObjID" parameter contained in the request message 1681 identifies the specific sidebar instance to be updated. An "update" 1682 operation on the "sidebarByValInfo" is handled by the conference 1683 server in the same manner as an "update" operation on the confInfo 1684 included in a confRequest message as detailed in Section 5.3.4. A 1685 "sidebarByValResponse" message MUST carry back to the client a 1686 "version" element related to the current version of the sidebar whose 1687 identifier is contained in the "confObjId" field of the request. 1689 If an "operation" of "delete" is included in the sidebarByVal 1690 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1691 request. Any "sidebarByValInfo" included in the request MUST be 1692 ignored by the conference server. The URI for the conference object 1693 associated with the sidebar MUST be included in the "confObjID" 1694 parameter in the request. If the specific conferencing user as 1695 reflected by the "confUserID" in the request is authorized to delete 1696 the conference, the conference server deletes the conference object 1697 reflected by the "confObjID" parameter and updates the data in the 1698 conference object from which the sidebar was cloned. The conference 1699 server can notify any conferencing clients that have subscribed to 1700 the conference event package, and are authorized to receive the 1701 notifications, of the deletion of the sidebar to the conference. 1703 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1704 or "delete" carries a "confObjID" which is not associated with any 1705 existing sidebar-by-val, a confResponse message containing a "404" 1706 error code will be generated on the server's side. This holds also 1707 for the case in which the mentioned "confObjID" is related to an 1708 existing conference object stored at the server, but associated with 1709 a blueprint or with an actual conference or with a sidebar-by-ref 1710 rather than a sidebar-by-val. 1712 1714 1715 1716 1717 1718 1719 1720 1721 1722 1724 1726 1729 1730 1731 1733 1735 1736 1737 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1750 1752 1755 1756 1757 1759 1761 1762 1763 1765 Figure 14: Structure of the sidebarByValRequest and 1766 sidebarByValResponse messages 1768 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1770 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1771 invoked to retrieve the element of the conference 1772 object identified by the "confObjID" parameter. The 1773 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1774 "operation" parameter MUST NOT be included in a 1775 "sidebarsByRefRequest" message. In the case of a "response-code" of 1776 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1778 response. The element represents the set of URIs 1779 of the sidebars associated with the main conference, whose 1780 description (in the form of a standard XCON conference document) is 1781 external to the main conference itself. Through the retrieved URIs, 1782 it is then possible to access single sidebars using the 1783 "sidebarByRef" request message, described in Section 5.3.10. A 1784 "sidebarsByRefResponse" message MUST carry back to the client a 1785 "version" element related to the current version of the main 1786 conference object (i.e. the one whose identifier is contained in the 1787 "confObjId" field of the request) to which the sidebars in question 1788 are associated. 1790 1792 1793 1794 1795 1796 1797 1798 1799 1800 1802 1804 1807 1808 1809 1811 1813 1814 1815 1817 1819 1820 1821 1822 1823 1824 1825 1826 1827 1829 1831 1834 1835 1836 1838 1840 1841 1842 1844 Figure 15: Structure of the sidebarsByRefRequest and 1845 sidebarsByRefResponse messages 1847 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1849 A sidebarByRefRequest message MUST contain the "operation" parameter 1850 which discriminates among retrieval, creation, modification and 1851 deletion of a specific sidebar. The other required parameters depend 1852 upon the type of operation. 1854 In the case of a "create" operation, the "confObjID" parameter MUST 1855 be included in the sidebyRefRequest message. In this case, the 1856 "confObjID" parameter contains the XCON-URI of the main conference in 1857 which the sidebar has to be created. If no "sidebarByRefInfo" 1858 parameter is included, as envisaged in the XCON framework 1859 ([RFC5239]), the sidebar is created by cloning the main conference, 1860 following the implementation specific cloning rules. Otherwise, 1861 similarly to the case of direct creation, the sidebar conference 1862 object is built on the basis of the "sidebarByRefInfo" parameter 1863 provided by the requestor. If the creation of the sidebar is 1864 successful, the conference server MUST update the "sidebars-by-ref" 1865 element in the conference object from which the sidebar was created 1866 (i.e., as identified by the "confObjID" in the original sidebarByRef 1867 request), with the URI of the newly created sidebar. The newly 1868 created conference object MAY be included in the response in the 1869 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1870 URI for the conference object associated with the newly created 1871 sidebar object MUST appear in the "confObjID" parameter of the 1872 response. The conference server can notify any conferencing clients 1873 that have subscribed to the conference event package, and are 1874 authorized to receive the notifications, of the addition of the 1875 sidebar to the conference. 1877 In the case of a "sidebarByRef" request with an operation of 1878 "retrieve", the URI for the conference object created for the sidebar 1879 MUST be included in the "confObjID" parameter in the request. A 1880 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1881 conference server in the same manner as a "retrieve" operation on the 1882 confInfo included in a confRequest message as detailed in 1883 Section 5.3.4. 1885 In the case of a "sidebarByRef" request with an operation of 1886 "update", the URI for the conference object created for the sidebar 1887 MUST be included in the "confObjID" parameter in the request. The 1888 "sidebarByRefInfo" MUST also be included in the request in the case 1889 of an "operation" of "update". An "update" operation on the 1890 "sidebarByRefInfo" is handled by the conference server in the same 1891 manner as an "update" operation on the confInfo included in a 1892 confRequest message as detailed in Section 5.3.4. A 1893 "sidebarByRefResponse" message MUST carry back to the client a 1894 "version" element related to the current version of the sidebar whose 1895 identifier is contained in the "confObjId" field of the request. 1897 If an "operation" of "delete" is included in the sidebarByRef 1898 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1899 request. Any "sidebarByRefInfo" included in the request MUST be 1900 ignored by the conference server. The URI for the conference object 1901 for the sidebar MUST be included in the "confObjID" parameter in the 1902 request. If the specific conferencing user as reflected by the 1903 "confUserID" in the request is authorized to delete the conference, 1904 the conference server SHOULD delete the conference object reflected 1905 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1906 element in the conference object from which the sidebar was 1907 originally cloned. The conference server can notify any conferencing 1908 clients that have subscribed to the conference event package, and are 1909 authorized to receive the notifications, of the deletion of the 1910 sidebar. 1912 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1913 or "delete" carries a "confObjID" which is not associated with any 1914 existing sidebar-by-ref, a confResponse message containing a "404" 1915 error code will be generated on the server's side. This holds also 1916 for the case in which the mentioned "confObjID" is related to an 1917 existing conference object stored at the server, but associated with 1918 a blueprint or with an actual conference or with a sidebar-by-val 1919 rather than a sidebar-by-ref. 1921 1923 1924 1925 1926 1927 1928 1929 1930 1931 1933 1935 1938 1939 1940 1942 1944 1945 1946 1948 1950 1951 1952 1953 1954 1955 1956 1957 1958 1960 1962 1965 1966 1967 1969 1971 1972 1974 1976 Figure 16: Structure of the sidebarByRefRequest and 1977 sidebarByRefResponse messages 1979 5.3.11. extendedRequest and extendedResponse 1981 In order to facilitate the possibility of specifying new request/ 1982 response pairs for conference control, CCMP makes available the 1983 "extendedRequest" and "extendedResponse" messages. Such messages 1984 constitute a CCMP skeleton in which implementors can transport the 1985 information needed to realize conference control mechanisms not 1986 explicitly envisioned in the CCMP specification; these mechanisms are 1987 called, in this context, "extensions". Each extension is assumed to 1988 be characterized by an appropriate name that MUST be carried in the 1989 extendedRequest/extendedResponse pair in the provided 1990 field. Extension-specific information can be transported in the form 1991 of schema-defined XML elements inside the element present in 1992 both extendedRequest and extendedResponse. 1994 The conferencing client SHOULD be able to be informed about the 1995 extensions supported by a CCMP server and to recover the XML Schema 1996 defining the related specific elements by means of an optionsRequest/ 1997 optionsResponse CCMP transaction (see Section 5.3.12). 1999 The meaning of the common CCMP parameters inherited by the 2000 extendedRequest and extendedResponse from the basic CCMP request and 2001 response messages SHOULD be preserved and exploited appropriately 2002 while defining an extension. 2004 2006 2007 2008 2009 2010 2011 2012 2013 2014 2016 2018 2019 2020 2021 2023 2026 2027 2029 2031 2032 2033 2034 2035 2036 2037 2038 2039 2041 2043 2045 2046 2047 2050 2053 2054 2056 Figure 17: Structure of the extendedRequest and extendedResponse 2057 messages 2059 5.3.12. optionsRequest and optionsResponse 2061 The "optionsRequest" (Figure 18) message is used to retrieve general 2062 information about conference server capabilities. These capabilities 2063 include the standard CCMP messages (request/response pairs) and 2064 potential extension messages supported by the conference server. As 2065 such it is a basic CCMP message, rather than a specialization of the 2066 general CCMP request. 2068 The "optionsResponse" returns, in the appropriate field, a 2069 list of the supported CCMP message pairs as defined in this 2070 specification. These messages are in the form of a list, including each of the supported messages as reflected 2072 by elements. The "optionsResponse" message also 2073 allows for an , which is a list of additional 2074 message types in the form of elements that 2075 are currently undefined, to allow for future extensibility. The 2076 following information is provided for both types of messages: 2078 o (REQUIRED): in case of standard messages, it can be one of 2079 the ten standard message names defined in this document (i.e. 2080 "blueprintsRequest", "confsRequest", etc.). In case of 2081 extensions, this element MUST carry the same value of the 2082 inserted in the corresponding extendedRequest/ 2083 extendedResponse message pair 2085 o (OPTIONAL): this field is a list of 2086 entries, each representing the CRUD operation supported by the 2087 server for the message. If this element is absent, the client 2088 SHOULD assume the server is able to handle the entire set of CRUD 2089 operations or, in case of standard messages, all the operations 2090 envisioned for that message in this document. 2092 o (OPTIONAL): since all CCMP messages can potentially 2093 contain XML elements not envisioned in the CCMP schema (due to the 2094 presence of elements and attributes), a reference to a 2095 proper schema definition specifying such new elements/attributes 2096 can also be sent back to the clients by means of such field. If 2097 this element is absent, no new elements are introduced in the 2098 messages further than those explicitly defined in the CCMP 2099 specification. 2101 o (OPTIONAL): human readable information about the 2102 related message 2104 The only parameter needed in the optionsRequest is the sender 2105 confUserID, which is mirrored in the homologous parameter of the 2106 corresponding optionsResponse. 2108 The CCMP server MUST include the containing 2109 at least one element in the optionsResponse, since a CCMP 2110 server is REQUIRED to be able to handle both the request and response 2111 messages for at least one of the operations. 2113 2115 2116 2117 2118 2119 2121 2123 2124 2125 2126 2127 2128 2129 2130 2131 2133 2135 2138 2139 2140 2142 2144 2145 2146 2148 2150 2151 2152 2155 2158 2160 2161 2162 2164 2166 2167 2168 2171 2173 2174 2175 2177 2179 2180 2181 2184 2187 2189 2191 2193 2194 2195 2197 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2214 2216 2217 2218 2220 2221 2222 2224 Figure 18: Structure of the optionsRequest and optionsResponse 2225 messages 2227 5.4. CCMP Response Codes 2229 All CCMP response messages MUST include a "response-code". This 2230 document defines an IANA registry for the CCMP response codes as 2231 described in Section 12.5.2. The following summarizes the CCMP 2232 response codes: 2234 200 Success: Successful completion of the requested operation. 2236 400 Bad Request: Syntactically malformed request. 2238 401 Unauthorized: User not allowed to perform the required 2239 operation. 2241 403 Forbidden: Operation not allowed (e.g., cancellation of a 2242 blueprint). 2244 404 Object Not Found: Target conference object missing at the server 2245 (it refers to the "confObjID" parameter in the generic request 2246 message) 2248 409 Conflict: A generic error associated with all those situations 2249 in which a requested client operation cannot be successfully 2250 completed by the server. An example of such situation is when the 2251 modification of an object cannot be applied due to conflicts 2252 arising at the server's side, e.g. because the client version of 2253 the object is an obsolete one and the requested modifications 2254 collide with the up-to-date state of the object stored at the 2255 server. Such code would also be used if a client attempts to 2256 create an object (conference or user) with an entity that already 2257 exists. 2259 420 User Not Found: Target user missing at the server (it is related 2260 to the XCON-USERID in the "entity" attribute of the "userInfo" 2261 parameter when it is included in userRequests) 2263 421 Invalid confUserID: User missing at the server (this code is 2264 returned in the case of requests in which the "confUserID" of the 2265 sender is invalid). 2267 422 Invalid Conference Password: Target conference object's password 2268 contained in the request is wrong. 2270 423 Conference Password Required: "conference-password" missing in a 2271 request to access a password-protected conference object. 2273 424 Authentication Required: User's authentication information is 2274 missing or invalid. 2276 425 Forbidden Delete Parent: Cancel operation failed since the 2277 target object is a parent of child objects which depend on it, or 2278 because it effects, based on the "parent-enforceable" mechanism, 2279 the corresponding element in a child object. 2281 426 Forbidden Change Protected: Update refused by the server because 2282 the target element cannot be modified due to its implicit 2283 dependence on the value of a parent object ("parent-enforceable" 2284 mechanism). 2286 427 Invalid Domain Name: The domain name in an AUTO_GENERATE_X 2287 instance in the conference object is not within the CCMP server's 2288 domain of responsibility. 2290 500 Server Internal Error: The server cannot complete the required 2291 service due to a system internal error. 2293 501 Not Implemented: Operation envisaged in the protocol, but not 2294 implemented in the contacted server. 2296 510 Request Timeout: The time required to serve the request has 2297 exceeded the envisaged service threshold. 2299 511 Resources Not Available: This code is used when the CCMP server 2300 cannot execute a command because of resource issues, e.g. it 2301 cannot create a sub conference because the system has reached its 2302 limits on the number of sub conferences, or if a request for 2303 adding a new user fails because the max number of users has been 2304 reached for the conference or the max number of users has been 2305 reached for the conferencing system. 2307 The handling of a "response-code" of "404", "409", "420", "421", 2308 "425", "426" and "427" are only applicable to specific operations for 2309 specialized message responses and the details are provided in 2310 Section 5.3. The following table summarizes these response codes and 2311 the specialized message and operation to which they are applicable: 2313 +----------+-------------+--------------+-------------+-------------+ 2314 | Response | Create | Retrieve | Update | Delete | 2315 | code | | | | | 2316 +----------+-------------+--------------+-------------+-------------+ 2317 | 404 | userRequest | All retrieve | All update | All delete | 2318 | | sidebarBy | requests | requests | requests | 2319 | | ValRequest, | EXCEPT: | | | 2320 | | sidebarsBy | blueprints | | | 2321 | | RefRequest | Request, | | | 2322 | | | confsRequest | | | 2323 | -------- | ----------- | ------------ | ----------- | ----------- | 2324 | | - | | | | 2325 | 409 | N/A | N/A | All update | N/A | 2326 | | | | requests | | 2327 | -------- | ----------- | ----------- | ----------- | ----------- | 2328 | 420 | userRequest | userRequest | userRequest | userRequest | 2329 | | (3rd party | | | | 2330 | | invite with | | | | 2331 | | third user | | | | 2332 | | entity) (*) | | | | 2333 | -------- | ----------- | ----------- | ----------- | ----------- | 2334 | 421 | All create | All retrieve | All update | All delete | 2335 | | requests | requests | requests | requests | 2336 | | EXCEPT: | | | | 2337 | | userRequest | | | | 2338 | | with no | | | | 2339 | | confUserID | | | | 2340 | | (**) | | | | 2341 | -------- | ----------- | ----------- | ----------- | ----------- | 2342 | 425 | N/A | N/A | N/A | All delete | 2343 | | | | | request | 2344 | -------- | ----------- | ----------- | ----------- | ----------- | 2345 | 426 | N/A | N/A | All update | N/A | 2346 | | | | requests | | 2347 | -------- | ----------- | ----------- | ----------- | ----------- | 2348 | 427 | ConfRequest | N/A | All update | N/A | 2349 | | UserRequest | | requests | | 2350 +----------+-------------+--------------+-------------+-------------+ 2351 Table 2: Response codes and associated operations 2353 (*) "420" in answer to a "userRequest/create" operation: in the case 2354 of a third-party invite, this code can be returned if the 2355 "confUserID" (contained in the "entity" attribute of the "userInfo" 2356 parameter) of the user to be added is unknown. In the case above, if 2357 instead it is the "confUserID" of the sender of the request that is 2358 invalid, a "421" error code is returned to the client. 2360 (**) "421" is not sent in answers to "userRequest/create" messages 2361 having a "null" confUserID, since this case is associated with a user 2362 who is unaware of his own XCON-USERID, but wants to enter a known 2363 conference. 2365 In the case of a response code of "510", a conferencing client MAY 2366 re-attempt the request within a period of time that would be specific 2367 to a conference control client or conference control server. 2369 A response code of "400" indicates that the conference control client 2370 sent a malformed request, which is indicative of an error in the 2371 conference control client or in the conference control server. The 2372 handling is specific to the conference control client implementation 2373 (e.g., generate a log, display an error message, etc.). It is NOT 2374 RECOMMENDED that the client re-attempt the request in this case. 2376 Response codes such as "401" and "403" indicate the client does not 2377 have the appropriate permissions, or there is an error in the 2378 permissions: re-attempting the request would likely not succeed and 2379 thus it is NOT RECOMMENDED. 2381 Any unexpected or unknown "response-code" SHOULD be treated by the 2382 client in the same manner as a "500" "response-code", the handling of 2383 which is specific to the conference control client implementation. 2385 6. A complete example of the CCMP in action 2387 In this section a typical, not normative, scenario in which the CCMP 2388 comes into play is described, by showing the actual composition of 2389 the various CCMP messages. In the call flows of the example, the 2390 Conference Control Client is a CCMP-enabled client, whereas the 2391 Conference Control Server is a CCMP-enabled server. The "confUserID" 2392 of the client, Alice, is "xcon-userid:alice@example.com" and appears 2393 in all requests. The sequence of operations is as follows: 2395 1. Alice retrieves from the server the list of available blueprints 2396 (Section 6.1); 2398 2. Alice asks for detailed information about a specific blueprint 2399 (Section 6.2); 2401 3. Alice decides to create a new conference by cloning the retrieved 2402 blueprint (Section 6.3); 2404 4. Alice modifies information (e.g. XCON-URI, name, description) 2405 associated with the newly created blueprint (Section 6.4); 2407 5. Alice specifies a list of users to be contacted when the 2408 conference is activated (Section 6.5); 2410 6. Alice joins the conference (Section 6.6); 2412 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2413 "xcon-userid:Ciccio@example.com") join the conference 2414 (Section 6.7). 2416 8. Alice asks for the CCMP server capabilities (Section 6.8); 2418 9. Alice exploits an extension of the CCMP server (Section 6.9). 2420 Note, the examples do not include any details beyond the basic 2421 operation. 2423 In the following sections we deal with each of the above mentioned 2424 actions separately. 2426 6.1. Alice retrieves the available blueprints 2428 This section illustrates the transaction associated with retrieval of 2429 the blueprints, together with a dump of the two messages exchanged 2430 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2431 the figure, the "blueprintsResponse" message contains, in the 2432 "blueprintsInfo" parameter, information about the available 2433 blueprints, in the form of the standard XCON-URI of the blueprint, 2434 plus additional (and optional) information, like its display-text and 2435 purpose. 2437 Alice retrieves from the server the list of available blueprints: 2439 CCMP Client CCMP Server 2440 | | 2441 | CCMP blueprintsRequest message | 2442 | - confUserID: Alice | 2443 | - confObjID: (null) | 2444 |------------------------------------------------------>| 2445 | | 2446 | CMP blueprintsResponse message | 2447 | - confUserID: Alice | 2448 | - confObjID: (null) | 2449 | - response-code: 200 | 2450 | - blueprintsInfo: bp123,bp124,.. | 2451 |<------------------------------------------------------| 2452 | | 2453 . . 2454 . . 2456 1. blueprintsRequest message: 2458 2459 2463 2465 xcon-userid:alice@example.com 2466 2467 2468 2470 2. blueprintsResponse message from the server: 2472 2473 2477 2480 xcon-userid:alice@example.com 2481 200 2482 2483 2484 2485 xcon:AudioRoom@example.com 2486 AudioRoom 2487 Simple Room: 2488 conference room with public access, 2489 where only audio is available, more users 2490 can talk at the same time 2491 and the requests for the AudioFloor 2492 are automatically accepted. 2493 2494 2495 2496 xcon:VideoRoom@example.com 2497 VideoRoom 2498 Video Room: 2499 conference room with public access, 2500 where both audio and video are available, 2501 8 users can talk and be seen at the same time, 2502 and the floor requests are automatically accepted. 2503 2504 2505 2506 xcon:AudioConference1@example.com 2507 AudioConference1 2508 Public Audio Conference: 2509 conference with public access, 2510 where only audio is available, 2511 only one user can talk at the same time, 2512 and the requests for the AudioFloor MUST 2513 be accepted by a Chair. 2514 2515 2516 2517 xcon:VideoConference1@example.com 2518 VideoConference1 2519 Public Video Conference: conference 2520 where both audio and video are available, 2521 only one user can talk 2522 2523 2524 2525 xcon:AudioConference2@example.com 2526 AudioConference2 2527 Basic Audio Conference: 2528 conference with private access, 2529 where only audio is available, 2530 only one user can talk at the same time, 2531 and the requests for the AudioFloor MUST 2532 be accepted by a Chair. 2533 2534 2535 2536 2537 2539 2541 Figure 19: Getting blueprints from the server 2543 6.2. Alice gets detailed information about a specific blueprint 2545 This section illustrates the second transaction in the overall flow. 2546 In this case, Alice, who now knows the XCON-URIs of the blueprints 2547 available at the server, makes a drill-down query, in the form of a 2548 CCMP "blueprintRequest" message, to get detailed information about 2549 one of them (the one called with XCON-URI 2550 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2551 Notice that the response contains, in the "blueprintInfo" parameter, 2552 a document compliant with the standard XCON data model. 2554 Alice retrieves detailed information about a specified blueprint: 2556 CCMP Client CCMP Server 2557 | | 2558 | CCMP blueprintRequest message | 2559 | - confUserID: Alice | 2560 | - confObjID: bp123 | 2561 | - operation: retrieve | 2562 | - blueprintInfo: (null) | 2563 |------------------------------------------------------>| 2564 | | 2565 | CCMP blueprintResponse message | 2566 | - confUserID: Alice | 2567 | - confObjID: bp123 | 2568 | - operation: retrieve | 2569 | - response-code: 200 | 2570 | - blueprintInfo: bp123Info | 2571 |<------------------------------------------------------| 2572 | | 2573 . . 2574 . . 2576 1. blueprintRequest message: 2578 2579 2583 2585 xcon-userid:alice@example.com 2586 xcon:AudioRoom@example.com 2587 retrieve 2588 2589 2590 2592 2. blueprintResponse message from the server: 2594 2595 2599 2601 xcon-userid:alice@example.com 2602 xcon:AudioRoom@example.com 2603 retrieve 2604 200 2605 Success 2606 2607 2608 2609 AudioRoom 2610 2611 2612 audio stream 2613 audio 2614 2615 2616 2617 2618 allow 2619 2620 2621 confirm 2622 2623 2624 audioLabel 2625 2626 2627 2628 2629 2631 2632 2634 Figure 20: Getting info about a specific blueprint 2636 6.3. Alice creates a new conference through a cloning operation 2638 This section illustrates the third transaction in the overall flow. 2639 Alice decides to create a new conference by cloning the blueprint 2640 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2641 retrieved detailed information through the "blueprintRequest" 2642 message. This is achieved by sending a "confRequest/create" message 2643 having the blueprint's URI in the "confObjID" parameter. The picture 2644 shows such transaction. Notice that the response contains, in the 2645 "confInfo" parameter, the document associated with the newly created 2646 conference, which is compliant with the standard XCON data model. 2647 The "confObjID" in the response is set to the XCON-URI of the new 2648 conference (in this case, "xcon:8977794@example.com"). We also 2649 notice that this value is equal to the value of the "entity" 2650 attribute of the element of the document 2651 representing the newly created conference object. 2653 Alice creates a new conference by cloning the 2654 "xcon:AudioRoom@example.com" blueprint: 2656 CCMP Client CCMP Server 2657 | | 2658 | CCMP confRequest message | 2659 | - confUserID: Alice | 2660 | - confObjID: AudioRoom | 2661 | - operation: create | 2662 | - confInfo: (null) | 2663 |------------------------------------------------------>| 2664 | | 2665 | CCMP confResponse message | 2666 | - confUserID: Alice | 2667 | - confObjID: newConfId | 2668 | - operation: create | 2669 | - response-code: 200 | 2670 | - version: 1 | 2671 | - confInfo: newConfInfo | 2672 |<------------------------------------------------------| 2673 | | 2674 . . 2675 . . 2677 1. confRequest message: 2679 2680 2684 2687 xcon-userid:alice@example.com 2688 xcon:AudioRoom@example.com 2689 create 2690 2691 2692 2694 2. confResponse message from the server: 2696 2697 2701 2703 xcon-userid:alice@example.com 2704 xcon:8977794@example.com 2705 create 2706 200 2707 Success 2708 1 2709 2710 2711 2712 2713 New conference by Alice cloned from AudioRoom 2714 2715 2716 2717 audio stream 2718 audio 2719 2720 2722 2723 2724 allow 2725 2726 2727 confirm 2728 2729 2730 333 2731 2732 2733 2734 2735 2736 2737 2739 Figure 21: Creating a new conference by cloning a blueprint 2741 6.4. Alice updates conference information 2743 This section illustrates the fourth transaction in the overall flow. 2744 Alice decides to modify some of the details associated with the 2745 conference she just created. More precisely, she changes the 2746 element under the element of 2747 the document representing the conference. This is achieved through a 2748 "confRequest/update" message carrying the fragment of the conference 2749 document to which the required changes have to be applied. As shown 2750 in the picture, the response contains a code of "200", which 2751 acknowledges the modifications requested by the client, while also 2752 updating the conference version number from 1 to 2, as reflected in 2753 the "version" parameter. 2755 Alice updates information about the conference she just created: 2757 CCMP Client CCMP Server 2758 | | 2759 | CCMP confRequest message | 2760 | - confUserID: Alice | 2761 | - confObjID: 8977794 | 2762 | - operation: update | 2763 | - confInfo: confUpdates | 2764 |------------------------------------------------------>| 2765 | | 2766 | CCMP confResponse message | 2767 | - confUserID: Alice | 2768 | - confObjID: 8977794 | 2769 | - operation: update | 2770 | - response-code: 200 | 2771 | - version: 2 | 2772 | - confInfo: (null) | 2773 |<------------------------------------------------------| 2774 | | 2775 . . 2776 . . 2778 1. confRequest message: 2780 2781 2785 2788 xcon-userid:alice@example.com 2789 xcon:8977794@example.com 2790 update 2791 2792 2793 2794 2795 Alice's conference 2796 2797 2798 2799 2800 2801 2803 2. confResponse message from the server: 2805 2806 2810 2812 xcon-userid:alice@example.com 2813 xcon:8977794@example.com 2814 update 2815 200 2816 Success 2817 2 2818 2819 2820 2822 Figure 22: Updating conference information 2824 6.5. Alice inserts a list of users in the conference object 2826 This section illustrates the fifth transaction in the overall flow. 2827 Alice modifies the under the element in 2828 the document associated with the conference she created. To the 2829 purpose, she exploits the "usersRequest" message provided by the 2830 CCMP. The picture below shows the transaction. 2832 Alice updates information about the list of users to whom access to 2833 the conference is permitted: 2835 CCMP Client CCMP Server 2836 | | 2837 | CCMP usersRequest message | 2838 | - confUserID: Alice | 2839 | - confObjID: 8977794 | 2840 | - operation: update | 2841 | - usersInfo: usersUpdates | 2842 |------------------------------------------------------>| 2843 | | 2844 | CCMP usersResponse message | 2845 | - confUserID: Alice | 2846 | - confObjID: 8977794 | 2847 | - operation: update | 2848 | - response-code: 200 | 2849 | - version: 3 | 2850 | - usersInfo: (null) | 2851 |<------------------------------------------------------| 2852 | | 2853 . . 2854 . . 2856 1. usersRequest message: 2858 2859 2863 2865 xcon-userid:alice@example.com 2866 xcon:8977794@example.com 2867 update 2868 2869 2870 2871 2873 2875 2877 2878 2879 2880 2881 2883 2. usersResponse message from the server: 2885 2886 2890 2892 xcon-userid:alice@example.com 2893 xcon:8977794@example.com 2894 retrieve 2895 200 2896 Success 2897 3 2898 2899 2900 2901 Figure 23: Updating the list of allowed users for the conference 2902 'xcon:8977794@example.com' 2904 6.6. Alice joins the conference 2906 This section illustrates the sixth transaction in the overall flow. 2907 Alice uses the CCMP to add herself to the newly created conference. 2908 This is achieved through a "userRequest/create" message containing, 2909 in the "userInfo" parameter, a element compliant with the XCON 2910 data model representation. Notice that such element includes 2911 information about the user's Address of Records, as well as her 2912 current end-point. The picture below shows the transaction. Notice 2913 how the "confUserID" parameter is equal to the "entity" attribute of 2914 the element, which indicates that the request issued by 2915 the client is a first-party one. 2917 Alice joins the conference by issuing a "userRequest/create" message 2918 with her own id to the server: 2920 CCMP Client CCMP Server 2921 | | 2922 | CCMP userRequest message | 2923 | - confUserID: Alice | 2924 | - confObjID: 8977794 | 2925 | - operation: create | 2926 | - userInfo: AliceUserInfo | 2927 |------------------------------------------------------>| 2928 | | 2929 | CCMP userResponse message | 2930 | - confUserID: Alice | 2931 | - confObjID: 8977794 | 2932 | - operation: create | 2933 | - response-code: 200 | 2934 | - version: 4 | 2935 | - userInfo: (null) | 2936 |<------------------------------------------------------| 2937 | | 2938 . . 2939 . . 2941 1. userRequest message: 2943 2944 2948 2950 xcon-userid:alice@example.com 2951 xcon:8977794@example.com 2952 create 2953 2954 2955 2956 2957 2958 mailto:Alice83@example.com 2959 2960 email 2961 2962 2963 2964 2965 2966 2967 2969 2. userResponse message from the server: 2971 2972 2976 2978 xcon-userid:alice@example.com 2979 xcon:8977794@example.com 2980 create 2981 200 2982 Success 2983 4 2984 2985 2986 2988 Figure 24: Alice joins the conference through the CCMP 2990 6.7. Alice adds a new user to the conference 2992 This section illustrates the seventh and last transaction in the 2993 overall flow. Alice uses the CCMP to add a new conferencing system 2994 user, Ciccio, to the conference. This "third-party" request is 2995 realized through a "userRequest/create" message containing, in the 2996 "userInfo" parameter, a element compliant with the XCON data 2997 model representation. Notice that such element includes information 2998 about Ciccio's Address of Records, as well as his current end-point, 2999 but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as 3000 discussed in Section 4.3, since the XCON-USERID is initially unknown 3001 to Alice. Thus, the conference server is in charge of generating a 3002 new XCON-USERID for the user Alice indicates (i.e, Ciccio), and 3003 returning it in the "entity" attribute of the "userInfo" parameter 3004 carried in the response, as well as adding the user to the 3005 conference. The picture below shows the transaction. 3007 Alice adds user "Ciccio" to the conference by issuing a third-party 3008 "userRequest/create" message to the server: 3010 CCMP Client CCMP Server 3011 | | 3012 | CCMP userRequest message | 3013 | - confUserID: Alice | 3014 | - confObjID: 8977794 | 3015 | - operation: create | 3016 | - userInfo: dummyUserID, CiccioUserInfo | 3017 |------------------------------------------------------>| 3018 | | 3019 | CCMP optionsResponse message | 3020 | - confUserID: Alice | 3021 | - confObjID: 8977794 | 3022 | - operation: create | 3023 | - response-code: 200 | 3024 | - version: 5 | 3025 | - userInfo: userIDCiccio, | 3026 | CiccioUserInfo | 3027 | | 3028 |<------------------------------------------------------| 3029 | | 3030 . . 3031 . . 3033 1. "third party" userRequest message from Alice: 3035 3036 3040 3042 xcon-userid:alice@example.com 3043 xcon:8977794@example.com 3044 create 3045 3046 3047 3048 3049 3050 mailto:Ciccio@example.com 3051 3052 email 3053 3054 3055 3056 3057 3058 3059 3061 2. "third party" userResponse message from the server: 3063 3064 3068 3070 xcon-userid:alice@example.com 3071 xcon:8977794@example.com 3072 create 3073 200 3074 5 3075 3076 3077 3078 3079 3080 mailto:Ciccio@example.com 3081 3082 email 3084 3085 3086 3087 3088 3089 3090 3092 Figure 25: Alice adds a new user to the conference through the CCMP 3094 6.8. Alice asks for the CCMP server capabilities 3096 This section illustrates how Alice can discover which standard CCMP 3097 messages and what extensions are supported by the CCMP server she 3098 interacts with through an optionsRequest/optionsResponse transaction. 3100 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 3101 confUserID parameter. Looking at the element in the 3102 received optionsResponse, Alice infers the following server 3103 capabilities as regards standard CCMP messages: 3105 o the server doesn't support sidebarsByValRequest nor 3106 sidebarByValRequest messages, since they do not appear in the 3107 ; 3109 o the only implemented operation for the blueprintRequest message is 3110 "retrieve", since no other entries are included in the 3111 related field. 3113 By analyzing the , Alice discovers the server 3114 implements a bluePrint extension, referred to as "confSummaryRequest" 3115 in this example. This extension allows Alice to recover via CCMP a 3116 brief description of a specific conference; the XML elements involved 3117 in this extended conference control transaction are available at the 3118 URL indicated in the element and the only operation 3119 provided by this extension is "retrieve". To better understand how 3120 Alice can exploit the "confSummaryRequest" extension via CCMP, see 3121 Section 6.9. 3123 The figure below shows the optionsRequest/optionsResponse message 3124 exchange between Alice and the CCMP server. 3126 CCMP Client CCMP Server 3127 | | 3128 | CCMP optionsRequest message | 3129 | - confUserID: Alice | 3130 |------------------------------------------------------>| 3131 | | 3132 | CCMP userResponse message | 3133 | - confUserID: Alice | 3134 | - response-code: 200 | 3135 | - options (list of both | 3136 | standard and extended | 3137 | supported messages) | 3138 |<------------------------------------------------------| 3139 | | 3140 . . 3141 . . 3143 1. optionsRequest (Alice asks for CCMP server capabilities) 3145 3146 3150 3152 xcon-userid:alice@example.com 3153 3154 3156 2. optionsResponse (the server returns the list of its conference 3157 control capabilities) 3159 3160 3164 3166 xcon-userid:alice@example.com 3167 200 3168 success 3169 3170 3171 3172 3173 blueprintsRequest 3174 3175 3176 blueprintRequest 3177 3178 retrieve 3179 3180 3181 3182 confsRequest 3183 3184 3185 confRequest 3186 3187 3188 usersRequest 3189 3190 3191 userRequest 3192 3193 3194 sidebarsByRefRequest 3195 3196 3197 sidebarByRefRequest 3198 3199 3200 3201 3202 confSummaryRequest 3203 3204 retrieve 3205 3206 3207 http://example.com/ccmp-extension-schema.xsd 3208 3209 3210 confSummaryRequest is intented 3211 to allow the requestor to retrieve 3212 a brief description 3213 of the conference indicated in the 3214 confObjID request parameter 3215 3216 3217 3218 3219 3220 3222 3224 Figure 26: Alice asks for the server control capabilities 3226 6.9. Alice exploits a CCMP server extension 3228 In this section, a very simple example of CCMP extension support is 3229 provided. Alice can recover information about this and other server- 3230 supported extensions by issuing an optionsRequest (see Section 6.8). 3232 The extension in question is named "confSummaryRequest" and allows a 3233 CCMP client to obtain from the CCMP server synthetic information 3234 about a specific conference. The conference summary is carried in 3235 the form of an XML element as follows: 3237 3238 3242 3244 3245 3246 3247 3248 3249 3250 3251 3253 3255 Figure 27: Example of XML Schema defining an extension parameter 3256 (ccmp-extension-schema.xsd) 3258 As it can be inferred from the schema file, the element 3259 contains conference information related to: 3261 o title 3263 o status (active or registered) 3265 o participation modality (if everyone is allowed to participate, the 3266 boolean element is set to "true") 3268 o involved media 3270 In order to retrieve a conference summary related to the conference 3271 she participates in, Alice then sends to the CCMP server an 3272 extendedRequest with a "confSummaryRequest" , 3273 specifying the conference xcon-uri in the confObjID request 3274 parameter, as depicted in the figure below. 3276 CCMP Client CCMP Server 3277 | | 3278 | CCMP extendedRequest message | 3279 | - confUserID: Alice | 3280 | - confObjID: 8977794 | 3281 | - operation: retrieve | 3282 | - extensionName: confSummaryRequest | 3283 |------------------------------------------------------>| 3284 | | 3285 | CCMP extendedResponse message | 3286 | - confUserID: Alice | 3287 | - confObjID: 8977794 | 3288 | - operation: retrieve | 3289 | - response-code: 200 | 3290 | - extensionName: | 3291 | confSummaryRequest | 3292 | - confSummary | 3293 |<------------------------------------------------------| 3294 | | 3295 . . 3296 . . 3298 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3300 3301 3305 3307 xcon-userid:alice@example.com 3308 xcon:8977794@example.com 3309 retrieve 3310 3311 confRequestSummary 3312 3313 3314 3316 2. extendedResponse (the server provides Alice with a brief description 3317 of the desired conference) 3319 3320 3324 3326 xcon-userid:alice@example.com 3327 xcon:8977794@example.com 3328 retrieve 3329 200 3330 success 3331 3332 confSummaryRequest 3333 3334 Alice's conference 3335 active 3336 true 3337 audio 3338 3339 3340 3341 3343 Figure 28: Alice exploits the 'confSummaryRequest' extension 3345 7. Locating a Conference Control Server 3347 If a conference control client is not pre-configured to use a 3348 specific conference control server for the requests, the client MUST 3349 first discover the conference control server before it can send any 3350 requests. The result of the discovery process, is the address of the 3351 server supporting conferencing. In this document, the result is an 3352 http: or https: URI, which identifies a conference server. 3354 DNS is RECOMMENDED to be used to locate a conference server in the 3355 case that the client is not pre-configured to use a specific 3356 conference server. U-NAPTR resolution for conferencing takes a 3357 domain name as input and produces a URI that identifies the 3358 conferencing server. This process also requires an Application 3359 Service tag and an Application Protocol tag, which differentiate 3360 conferencing-related NAPTR records from other records for that 3361 domain. 3363 Section 12.4.1 defines an Application Service tag of "XCON", which is 3364 used to identify the centralized conferencing (XCON) server for a 3365 particular domain. The Application Protocol tag "CCMP", defined in 3366 Section 12.4.2, is used to identify an XCON server that understands 3367 the CCMP protocol. 3369 The NAPTR records in the following example Figure 29 demonstrate the 3370 use of the Application Service and Protocol tags. Iterative NAPTR 3371 resolution is used to delegate responsibility for the conferencing 3372 service from "zonea.example.com." and "zoneb.example.com." to 3373 "outsource.example.com.". 3375 zonea.example.com. 3376 ;; order pref flags 3377 IN NAPTR 100 10 "" "XCON-CCMP" ( ; service 3378 "" ; regex 3379 outsource.example.com. ; replacement 3380 ) 3381 zoneb.example.com. 3382 ;; order pref flags 3383 IN NAPTR 100 10 "" "XCON-CCMP" ( ; service 3384 "" ; regex 3385 outsource.example.com. ; replacement 3386 ) 3387 outsource.example.com. 3388 ;; order pref flags 3389 IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service 3390 "!*.!https://confs.example.com/!" ; regex 3391 . ; replacement 3392 ) 3394 Figure 29: Sample XCON-CCMP Service NAPTR Records 3396 Details for the "XCON" Application Service tag and the "CCMP" 3397 Application Protocol tag are included in Section 12.4. 3399 8. Managing Notifications 3401 As per [RFC5239], the CCMP is one of the following four protocols 3402 which have been formally identified within the XCON framework: 3404 Conference Control Protocol: between Conference and Media Control 3405 Client and Conference Server. Such protocol is the subject of the 3406 present document. 3408 Binary floor Control Protocol: between the Floor Control Client and 3409 the Floor Control Server. Such protocol is the BFCP, specified in 3410 [RFC4582]. 3412 Call Signaling Protocol: between the Call Signaling Client and the 3413 Focus. Such protocol can be either SIP or any other call 3414 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3415 a conferencing session. 3417 Notification Protocol: between the Notification Client and the XCON 3418 Notification Service. This specification does not define a new 3419 notification protocol. For clients that use SIP as the call 3420 signaling protocol, the XCON event package 3421 [I-D.ietf-xcon-event-package] MUST be used by the client for 3422 notifications of changes in the conference data as described 3423 below. 3425 The CCMP protocol specified in this document is a pro-active one and 3426 is used by a conferencing client to send requests to a conferencing 3427 server in order to retrieve information about the conference objects 3428 stored by the server and to potentially manipulate them. However, a 3429 complete conferencing solution is not prohibited from providing 3430 clients with a means for receiving asynchronous updates about the 3431 status of the objects available at the server. The notification 3432 protocol, while conceptually independent of all the mentioned 3433 companion protocols, can nonetheless be chosen in a way that is 3434 consistent with the overall protocol architecture characterizing a 3435 specific deployment, as discussed in the following. 3437 When the conference control client uses SIP [RFC3261] as the 3438 signaling protocol to participate in the conference, SIP event 3439 notification can be used. In such a case, the conference control 3440 client MUST implement the Conference event package for XCON 3441 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3442 conferencing clients as is SIP for signaling per the XCON Framework 3443 [RFC5239]. 3445 In the case where the interface to the conference server is entirely 3446 web based, there is a common mechanism for web-based systems that 3447 could be used - a "call back". With this mechanism, the conference 3448 client provides the conference server with an HTTP URL which is 3449 invoked when a change occurs. This is a common implementation 3450 mechanism for e-commerce. This works well in the scenarios whereby 3451 the conferencing client is a web server that provides the graphical 3452 HTML user interface and uses CCMP as the backend interface to the 3453 conference server. And, this model can co-exist with the SIP event 3454 notification model. PC-based clients behind NATs could provide a SIP 3455 event URI, whereas web-based clients using CCMP in the backend would 3456 probably find the HTTP call back approach much easier. The details 3457 of this approach are out of scope for the CCMP per se, thus the 3458 expectation is that a future specification will document this 3459 solution. 3461 9. HTTP Transport 3463 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3464 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3465 conforming conference Server and Conferencing client MUST support. 3467 Although CCMP uses HTTP as a transport, it uses a strict subset of 3468 HTTP features, and due to the restrictions of some features, a 3469 conferencing server might not be a fully compliant HTTP server. It 3470 is intended that a conference server can easily be built using an 3471 HTTP server with extensibility mechanisms, and that a conferencing 3472 client can trivially use existing HTTP libraries. This subset of 3473 requirements helps implementors avoid ambiguity with the many options 3474 the full HTTP protocol offers. 3476 Support of HTTP authentication [RFC2617] and cookies [RFC6265] is 3477 OPTIONAL for a conferencing client that conforms to this 3478 specification. These mechanism are unnecessary because CCMP requests 3479 carry their own authentication information (in the "subject" field; 3480 see Section 5.1). A conferencing client SHOULD include support for 3481 HTTP proxy authentication. 3483 A CCMP request is carried in the body of an HTTP POST request. The 3484 conferencing client MUST include a Host header in the request. 3486 The MIME type of CCMP request and response bodies is "application/ 3487 ccmp+xml". The conference server and conferencing client MUST 3488 provide this value in the HTTP Content-Type and Accept header fields. 3489 If the conference server does not receive the appropriate Content- 3490 Type and Accept header fields, the conference server SHOULD fail the 3491 request, returning a 406 (not acceptable) response. CCMP responses 3492 SHOULD include a Content-Length header. 3494 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3495 header in CCMP requests. The conference server MAY return 501 (not 3496 implemented) errors if either of these HTTP features are used. In 3497 the case that the conference server receives a request from the 3498 conferencing client containing a If-* (conditional) header, the 3499 conference server SHOULD return a 412 (precondition failed) response. 3501 The POST method is the only method REQUIRED for CCMP. If a 3502 conference server chooses to support GET or HEAD, it SHOULD consider 3503 the kind of application doing the GET. Since a conferencing client 3504 only uses a POST method, the GET or HEAD MUST be either an escaped 3505 URL (e.g., somebody found a URL in protocol traces or log files and 3506 fed it into their browser) or somebody doing testing/ debugging. The 3507 conference server could provide information in the CCMP response 3508 indicating that the URL corresponds to a conference server and only 3509 responds to CCMP POST requests or the conference server could instead 3510 try to avoid any leak of information by returning a very generic HTTP 3511 error message such as 405 (method not allowed). 3513 The conference server populates the HTTP headers of responses so that 3514 they are consistent with the contents of the message. In particular, 3515 the "CacheControl" header SHOULD be set to disable caching of any 3516 conference information by HTTP intermediaries. Otherwise, there is 3517 the risk of stale information and/or the unauthorized disclosure of 3518 the information. The HTTP status code MUST indicate a 2xx series 3519 response for all CCMP Response and Error messages. 3521 The conference server MAY redirect a CCMP request. A conference 3522 server MUST NOT include CCMP responses in a 3xx response. A 3523 conferencing client MUST handle redirects, by using the Location 3524 header provided by the server in a 3xx response. When redirecting, 3525 the conferencing client MUST observe the delay indicated by the 3526 Retry-After header. The conferencing client MUST authenticate the 3527 server that returns the redirect response before following the 3528 redirect. A conferencing client SHOULD authenticate the conference 3529 server indicated in a redirect. 3531 The conference server SHOULD support persistent connections and 3532 request pipelining. If pipelining is not supported, the conference 3533 server MUST NOT allow persistent connections. The conference server 3534 MUST support termination of a response by the closing of a 3535 connection. 3537 Implementations of CCMP that implement HTTP transport MUST implement 3538 transport over TLS [RFC2818]. TLS provides message integrity and 3539 confidentiality between the conference control client and the 3540 conference control server. The conferencing client MUST implement 3541 the server authentication method described in HTTPS [RFC2818]. The 3542 device uses the URI obtained during conference server discovery to 3543 authenticate the server. The details of this authentication method 3544 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3545 the conferencing client SHOULD fail a request if server 3546 authentication fails. 3548 10. Security Considerations 3550 As identified in the XCON framework [RFC5239], there are a wide 3551 variety of potential attacks related to conferencing, due to the 3552 natural involvement of multiple endpoints and the capability to 3553 manipulate the data on the conference server using CCMP. Examples of 3554 attacks include the following: an endpoint attempting to listen to 3555 conferences in which it is not authorized to participate, an endpoint 3556 attempting to disconnect or mute other users, and theft of service by 3557 an endpoint in attempting to create conferences it is not allowed to 3558 create. 3560 The following summarizes the security considerations for CCMP: 3562 1. The client MUST determine the proper conference server. The 3563 conference server discovery is described in Section 7. 3565 2. The client MUST connect to the proper conference server. The 3566 mechanisms for addressing this security consideration are 3567 described in Section 10.1. 3569 3. The protocol MUST support a confidentiality and integrity 3570 mechanism. As described in Section 9, implementations of CCMP 3571 MUST implement the HTTP transport over TLS [RFC2818]. 3573 4. There are security issues associated with the authorization to 3574 perform actions on the conferencing system to invoke specific 3575 capabilities. A conference server SHOULD ensure that only 3576 authorized entities can manipulate the conference data. The 3577 mechanisms for addressing this security consideration are 3578 described in Section 10.2. 3580 5. The privacy and security of the identity of a user in the 3581 conference MUST be assured. The mechanisms to ensure the 3582 security and privacy of identity are discussed in Section 10.3. 3584 6. A final issue is related to Denial of Service (DoS) attacks on 3585 the conferencing server itself. The recommendations to minimize 3586 the potential and impact of DoS attacks are discussed in 3587 Section 10.4. 3589 Of the considerations listed above, items 1 and 3 are addressed 3590 within the referenced sections earlier in this document. The 3591 remaining security considerations are addressed in detail in the 3592 following sections. 3594 10.1. Assuring that the Proper Conferencing Server has been contacted 3596 Section 7 describes a mechanism using DNS by which a conference 3597 client discovers a conference server. A primary concern is spoofed 3598 DNS replies, thus the use of DNSSEC is RECOMMENDED to ensure that the 3599 client receives a valid response from the DNS server in cases where 3600 this is a concern. 3602 When the CCMP transaction is conducted using TLS [RFC5246], the 3603 conference server can authenticate its identity, either as a domain 3604 name or as an IP address, to the conference client by presenting a 3605 certificate containing that identifier as a subjectAltName (i.e., as 3606 an iPAddress or dNSName, respectively). Any implementation of CCMP 3607 MUST be capable of being transacted over TLS so that the client can 3608 request the above authentication. Note that in order for the 3609 presented certificate to be valid at the client, the client MUST be 3610 able to validate the certificate following the procedures in 3611 [RFC2818] in the case of HTTP as a transport. In particular, the 3612 validation path of the certificate must end in one of the client's 3613 trust anchors, even if that trust anchor is the conference server 3614 certificate itself. If the client has external information as to the 3615 expected identity or credentials of the proper conference server, the 3616 authentication checks described above MAY be omitted. 3618 10.2. User Authentication and Authorization 3620 Many policy authorization decisions are based on the identity of the 3621 user or the role that a user may have. The conferencing server MUST 3622 implement mechanisms for authentication of users to validate their 3623 identity. There are several ways that a user might authenticate its 3624 identity to the system. For users joining a conference using one of 3625 the call signaling protocols, the user authentication mechanisms for 3626 the specific protocol can be used. For example, in the case of a 3627 user joining the conference using SIP signaling, the user 3628 authentication as defined in [RFC3261] MUST be used. For the case of 3629 users joining the conference using the CCMP, the CCMP Request 3630 messages provide a subject field which contains a username and 3631 password, which can be used for authentication. Since the CCMP 3632 messages are RECOMMENDED to be carried over TLS, this information can 3633 be sent securely. 3635 The XCON Framework [RFC5239] provides an overview of other 3636 authorization mechanisms. In the cases where a user is authorized 3637 via multiple mechanisms, it is RECOMMENDED that the conference server 3638 associate the authorization of the CCMP interface with other 3639 authorization mechanisms - e.g., PSTN users that join with a PIN and 3640 control the conference using CCMP. When a conference server presents 3641 the identity of authorized users, it MAY provide information about 3642 the way the identity was proven or verified by the system. A 3643 conference server can also allow a completely unauthenticated user 3644 into the system - this information SHOULD also be communicated to 3645 interested parties. 3647 Once a user is authenticated and authorized through the various 3648 mechanisms available on the conference server, the conference server 3649 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3650 associate the XCON-USERID with any signaling specific user 3651 identifiers that were used for authentication and authorization. 3652 This XCON-USERID can be provided to a specific user through the 3653 conference notification interface and MUST be provided to users that 3654 interact with the conferencing system using the CCMP (i.e., in the 3655 appropriate CCMP response messages). The XCON-USERIDs for each user/ 3656 participant in the conference are contained in the "entity" attribute 3657 in the "user" element in the conference object. The XCON-USERID is 3658 REQUIRED for any subsequent operations by the user on the conference 3659 object and is carried in the confUserID parameter in the CCMP 3660 requests and responses. 3662 Note that the policy management of an XCON-compliant conference 3663 system is out of the scope of this document, as well as of the XCON 3664 WG. However, the specification of a policy management framework is 3665 realizable with the overall XCON architecture, in particular with 3666 regards to a Role Based Access Control (RBAC) approach. In RBAC, the 3667 following elements are identified: (i) Users; (ii) Roles; (iii) 3668 Objects; (iv) Operations; (v) Permissions. For all of the above 3669 elements a direct mapping exists onto the main XCON entities. As an 3670 example, RBAC objects map onto XCON data model objects and RBAC 3671 operations map onto CCMP operations. 3673 Future documents can define an RBAC framework for XCON, by first 3674 focusing on the definition of roles and then specifying the needed 3675 permission policy sets and role policy sets (used to associate policy 3676 permission sets with specific roles). With these policies in place, 3677 access to a conference object compliant with the XCON data model can 3678 be appropriately controlled. As far as assigning users to roles, the 3679 Users in the RBAC model relate directly to the "users" element in the 3680 conference object. The "users" element is comprised of "user" 3681 elements representing a specific user in the conferencing system. 3682 Each "user" element contains an "entity" attribute with the XCON- 3683 USERID and a "role" element. Thus, each authorized user (as 3684 represented by an XCON-USERID) can be associated with a "role" 3685 element. 3687 10.3. Security and Privacy of Identity 3689 An overview of the required privacy and anonymity for users of a 3690 conferencing system are provided in the XCON Framework [RFC5239]. 3691 The security of the identity in the form of the XCON-USERID is 3692 provided in the CCMP protocol through the use of TLS. 3694 The conference server SHOULD support the mechanism to ensure the 3695 privacy of the XCON-USERID. The conference client indicates the 3696 desired level of privacy by manipulation of the "provide-anonymity" 3697 element defined in the XCON data model 3698 ([I-D.ietf-xcon-common-data-model]. The "provide-anonymity" element 3699 controls the degree to which a user reveals their identity. The 3700 following summarizes the values for the "provide-anonymity" element 3701 that the client includes in their requests: 3703 "hidden": Ensures that other participants are not aware that there 3704 is an additional participant (i.e., the user issuing the request) 3705 in the conference. This could be used in cases of users that are 3706 authorized with a special role in a conference (e.g., a supervisor 3707 in a call center environment). 3709 "anonymous": Ensures that other participants are aware that there 3710 is another participant (i.e., the user issuing the request), 3711 however, the other participants are not provided information as to 3712 the identity of the user. 3714 "semi-private": Ensures that the user's identity is only to be 3715 revealed to other participants or users that have a higher level 3716 authorization (e.g., a conferencing system can be configured such 3717 that a human administrator can see all users). 3719 If the client desires privacy, the conference client SHOULD include 3720 the "provide-anonymity" element in the "confInfo" parameter in a CCMP 3721 confRequest message with an "update" or "create" operation or in the 3722 "userInfo" parameter in a CCMP userRequest message with an "update" 3723 or "create" operation. If the "provide-anonymity" element is not 3724 included in the conference object, then other users can see the 3725 participant's identity. Participants are made aware of other 3726 participants that are "anonymous" or "semi-private" when they perform 3727 subsequent operations on the conference object or retrieve the 3728 conference object or when they receive subsequent notifications. 3730 Note, that independent of the level of anonymity requested by the 3731 user, the identity of the user is always known by the conferencing 3732 system as that is required to perform the necessary authorization as 3733 described in Section 10.2. The degree to which human administrators 3734 can see the information can be controlled using policies (e.g., some 3735 information in the data model can be hidden from human 3736 administrators). 3738 10.4. Mitigating DoS Attacks 3740 [RFC4732] provides an overview of possible DoS attacks. In order to 3741 minimize the potential for DoS attacks, it is RECOMMENDED that 3742 conferencing systems require user authentication and authorization 3743 for any client participating in a conference. This can be 3744 accomplished through the use of the mechanisms described in 3745 Section 10.2, as well as by using the security mechanisms associated 3746 with the specific signaling (e.g., SIPS) and media protocols (e.g., 3747 SRTP). In addition, Section 4.4 describes the use of a timer 3748 mechanism to alleviate the situation whereby CCMP messages pend 3749 indefinitely, thus increasing the potential that pending requests 3750 continue to increase when is a server is receiving more requests than 3751 it can process. 3753 11. XML Schema 3755 This section gives the XML Schema Definition 3756 [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the 3757 "application/ccmp+xml" format. This is presented as a formal 3758 definition of the "application/ccmp+xml" format. A new XML 3759 namespace, a new XML schema, and the MIME type for this schema are 3760 registered with IANA as described in Section 12. Note that this XML 3761 Schema Definition is not intended to be used with on-the-fly 3762 validation of the presence XML document. Whitespaces are included in 3763 the schema to conform to the line length restrictions of the RFC 3764 format without having a negative impact on the readability of the 3765 document. Any conforming processor should remove leading and 3766 trailing white spaces. 3768 3770 3778 3780 3783 3784 3786 3788 3789 3790 3792 3793 3795 3797 3799 3800 3802 3804 3806 3808 3810 3812 3813 3814 3816 3818 3819 3820 3822 3823 3825 3826 3827 3828 3830 3832 3835 3838 3840 3842 3844 3845 3846 3848 3850 3852 3853 3854 3855 3856 3857 3858 3859 3860 3862 3864 3866 3867 3868 3870 3872 3873 3875 3877 3879 3880 3881 3882 3883 3884 3885 3886 3887 3889 3891 3893 3894 3895 3897 3899 3900 3901 3903 3905 3906 3907 3908 3909 3910 3911 3912 3913 3915 3917 3919 3920 3921 3924 3926 3927 3928 3930 3932 3933 3934 3935 3936 3937 3938 3939 3940 3942 3944 3946 3947 3948 3950 3952 3953 3954 3956 3958 3959 3960 3961 3962 3963 3964 3965 3966 3968 3970 3971 3972 3973 3975 3977 3978 3979 3981 3983 3984 3985 3986 3987 3988 3989 3990 3991 3993 3995 3997 3998 3999 4001 4003 4004 4005 4007 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4020 4023 4024 4025 4027 4029 4030 4031 4033 4035 4036 4037 4038 4039 4040 4041 4042 4043 4045 4047 4050 4051 4052 4054 4056 4057 4058 4060 4062 4063 4064 4065 4066 4067 4068 4069 4070 4072 4074 4077 4078 4079 4081 4083 4084 4085 4087 4089 4090 4091 4092 4093 4094 4095 4096 4097 4099 4101 4104 4105 4106 4108 4110 4111 4112 4113 4115 4116 4117 4118 4119 4120 4121 4122 4123 4125 4127 4129 4130 4131 4133 4135 4136 4138 4140 4141 4142 4143 4144 4145 4147 4149 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4162 4164 4165 4166 4168 4170 4171 4172 4174 4176 4177 4178 4179 4180 4181 4182 4183 4184 4186 4188 4190 4191 4192 4194 4196 4197 4198 4200 4202 4203 4204 4205 4206 4207 4209 4210 4211 4213 4215 4217 4218 4219 4221 4223 4224 4225 4227 4229 4230 4231 4232 4233 4234 4235 4236 4237 4239 4241 4243 4244 4245 4247 4249 4250 4251 4253 4255 4256 4257 4258 4259 4260 4261 4262 4263 4265 4267 4269 4270 4271 4273 4275 4276 4277 4279 4281 4282 4283 4284 4285 4286 4287 4288 4289 4291 4293 4295 4296 4297 4299 4301 4302 4303 4304 4306 4307 4308 4309 4310 4311 4312 4313 4314 4316 4318 4321 4322 4323 4325 4327 4328 4329 4331 4333 4334 4335 4336 4337 4338 4339 4340 4341 4343 4345 4348 4349 4350 4353 4355 4356 4357 4359 4361 4362 4363 4364 4365 4366 4367 4368 4369 4371 4373 4376 4377 4378 4380 4382 4383 4384 4386 4388 4389 4390 4391 4392 4393 4394 4395 4396 4398 4400 4403 4404 4405 4407 4409 4410 4411 4413 4415 4416 4417 4418 4419 4420 4421 4422 4423 4425 4427 4429 4430 4431 4433 4436 4437 4439 4441 4442 4443 4444 4445 4446 4447 4448 4450 4452 4454 4457 4458 4459 4461 4463 4464 4465 4467 4469 4471 4472 4473 4474 4475 4477 4479 4480 4481 4482 4483 4484 4485 4486 4488 4490 4491 4492 4494 4496 4499 4500 4501 4503 4505 4506 4507 4510 4513 4515 4516 4517 4519 4521 4522 4523 4526 4528 4529 4530 4532 4534 4535 4536 4539 4542 4543 4544 4546 4547 4548 4550 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4567 4569 4570 4571 4573 4574 4575 4577 4579 4580 4581 4584 4586 4587 4588 4590 4592 4593 4594 4595 4598 4599 4602 4604 4605 4606 4608 4610 Figure 30 4612 12. IANA Considerations 4614 This document registers a new XML namespace, a new XML schema, and 4615 the MIME type for the schema. This document also registers the 4616 "XCON" Application Service tag and the "CCMP" Application Protocol 4617 tag. This document also defines registries for the CCMP operation 4618 types and response codes. 4620 12.1. URN Sub-Namespace Registration 4622 This section registers a new XML namespace, 4623 ""urn:ietf:params:xml:ns:xcon-ccmp"". 4625 URI: "urn:ietf:params:xml:ns:xcon-ccmp" 4627 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4628 Mary Barnes (mary.ietf.barnes@gmail.com). 4630 XML: 4632 BEGIN 4633 4634 4636 4637 4638 CCMP Messages 4639 4640 4641

Namespace for CCMP Messages

4642

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

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

See RFCXXXX.

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