idnits 2.17.1 draft-ietf-xcon-ccmp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2009) is 5272 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) == Unused Reference: 'RFC3966' is defined on line 3744, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-examples' is defined on line 3754, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-14 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-10) exists of draft-ietf-xcon-examples-01 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Standards Track C. Boulton 5 Expires: May 16, 2010 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 November 12, 2009 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-04 15 Abstract 17 The Centralized Conferencing Manipulation Protocol (CCMP) can create, 18 retrieve, change and delete objects describing a centralized 19 conference, such as state and capabilities of the conference, 20 participants, and their roles. The conference information is 21 contained in XML documents and fragments conforming to the 22 centralized conferencing data model schema. Even though the goal of 23 the CCMP is to appropriately manage conference state, the mechanisms 24 upon which the protocol itself is built are based on a state-less 25 request/response paradigm. Conferencing clients send requests to 26 conference servers, which respond to the client with the conference 27 information. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on May 16, 2010. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. XCON Conference Control System Architecture . . . . . . . . . 7 73 4.1. Conference Objects . . . . . . . . . . . . . . . . . . . . 8 74 4.2. Conference Users . . . . . . . . . . . . . . . . . . . . . 8 75 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10 77 5.2. Implementation Approach . . . . . . . . . . . . . . . . . 12 78 6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13 80 6.2. CCMP Response Message Type . . . . . . . . . . . . . . . . 14 81 6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 82 6.3.1. blueprintsRequest and blueprintsResponse . . . . . . . 19 83 6.3.2. confsRequest and confsResponse . . . . . . . . . . . . 21 84 6.3.3. blueprintRequest and blueprintResponse . . . . . . . . 22 85 6.3.4. confRequest and confResponse . . . . . . . . . . . . . 24 86 6.3.5. usersRequest and usersResponse . . . . . . . . . . . . 27 87 6.3.6. userRequest and userResponse . . . . . . . . . . . . . 30 88 6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . . 34 89 6.3.8. sidebarByValRequest and sidebarByValResponse . . . . . 36 90 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . . 39 91 6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . . 41 92 6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 44 93 7. A complete example of the CCMP in action . . . . . . . . . . . 48 94 7.1. Alice retrieves the available blueprints . . . . . . . . . 48 95 7.2. Alice gets detailed information about a specific 96 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 51 97 7.3. Alice creates a new conference through a cloning 98 operation . . . . . . . . . . . . . . . . . . . . . . . . 53 99 7.4. Alice updates conference information . . . . . . . . . . . 55 100 7.5. Alice inserts a list of users in the conference object . . 57 101 7.6. Alice joins the conference . . . . . . . . . . . . . . . . 59 102 7.7. Alice adds a new user to the conference . . . . . . . . . 61 103 8. Locating a Conference Control Server . . . . . . . . . . . . . 64 104 9. Managing Notifications . . . . . . . . . . . . . . . . . . . . 66 105 10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 67 106 11. Security Considerations . . . . . . . . . . . . . . . . . . . 69 107 11.1. Assuring that the Proper Conferencing Server has been 108 contacted . . . . . . . . . . . . . . . . . . . . . . . . 70 109 11.2. User Authentication and Authorization . . . . . . . . . . 70 110 11.3. Security and Privacy of Identity . . . . . . . . . . . . . 71 111 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 72 112 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 113 13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 83 114 13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 83 115 13.3. MIME Media Type Registration for 'application/ccmp+xml' . 84 116 13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 85 117 13.4.1. Registration of a Conference Control Server 118 Application Service Tag . . . . . . . . . . . . . . . 85 119 13.4.2. Registration of a Conference Control Server 120 Application Protocol Tag for CCMP . . . . . . . . . . 85 121 13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 86 122 13.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 86 123 13.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 87 124 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 125 15. Changes since last Version . . . . . . . . . . . . . . . . . . 91 126 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93 127 16.1. Normative References . . . . . . . . . . . . . . . . . . . 93 128 16.2. Informative References . . . . . . . . . . . . . . . . . . 93 129 Appendix A. Appendix A: Other protocol models and transports 130 considered for CCMP . . . . . . . . . . . . . . . . . 95 131 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 95 132 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 96 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 135 1. Introduction 137 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 138 defines a signaling-agnostic framework, naming conventions and 139 logical entities required for building advanced conferencing systems. 140 The XCON Framework introduces the conference object as a logical 141 representation of a conference instance, representing the current 142 state and capabilities of a conference. 144 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 145 this document allows authenticated and authorized users to create, 146 manipulate and delete conference objects. Operations on conferences 147 include adding and removing participants, changing their roles, as 148 well as adding and removing media streams and associated end points. 150 The CCMP implements the client-server model within the XCON 151 Framework, with the conferencing client and conference control server 152 acting as client and server, respectively. The CCMP uses HTTP 153 [RFC2616] as the protocol to transfer the CCMP requests and 154 responses, which contain the domain-specific XML-encoded data objects 155 defined in the Conference Information Data Model for Centralized 156 Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model]. 157 Other protocol models such as the use of a REST (REpresentational 158 State Transfer) architectural style [REST] were considered. 160 Section 4 provides an overview of the Conference Control 161 functionality of the XCON framework, together with a description of 162 the main targets CCMP deals with, namely conference objects and 163 conference users. A general description of the operations associated 164 with protocol messages is given in Section 5 together with 165 implementation details. A complete example of the operation of the 166 CCMP, describing a typical call flow associated with conference 167 creation and manipulation, is provided in Section 7. Section 12 168 provides the XML schema. 170 2. Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 3. Terminology 178 In additon to the terms defined in the Framework for Centralized 179 Conferencing [RFC5239], this document uses the following terms and 180 acronyms: 182 CRUD: CRUD stands for Create/Read/Update/Delete and indicates a 183 design pattern supporting creating, retrieving, updating and 184 destroying objects. 186 REST: REpresentational State Transfer (REST) is an architectural 187 style, i.e., a coordinated set of architectural constraints. REST 188 is based on the consideration that a software architecture can 189 often be specified as an appropriate configuration of components, 190 data and connectors, all coordinated through constraining their 191 mutual relationships. Coordination and constraints help achieve a 192 desired set of architectural properties. [REST] 194 SOAP: Simple Object Access Protocol defined in 195 [W3C.REC-soap12-part1-20030624] and 196 [W3C.REC-soap12-part2-20030624]. 198 4. XCON Conference Control System Architecture 200 CCMP supports the XCON framework . Figure 1 depicts a subset of the 201 "Conferencing System Logical Decomposition" architecture from the 202 XCON framework document. It illustrates the role that CCMP assumes 203 within the overall centralized architecture. 205 ........................................................ 206 . Conferencing System . 207 . . 208 . +---------------------------------------+ . 209 . | C O N F E R E N C E O B J E C T | . 210 . +-+-------------------------------------+ | . 211 . | C O N F E R E N C E O B J E C T | | . 212 . +-+-------------------------------------+ | | . 213 . | C O N F E R E N C E O B J E C T | | | . 214 . | | |-+ . 215 . | |-+ . 216 . +---------------------------------------+ . 217 . ^ . 218 . | . 219 . v . 220 . +-------------------+ . 221 . | Conference Control| . 222 . | Server | . 223 . +-------------------+ . 224 . ^ . 225 .........................|.............................. 226 | 227 |Conference 228 |Control 229 |Manipulation 230 |Protocol 231 | 232 .........................|.............................. 233 . V . 234 . +----------------+ . 235 . | Conference | . 236 . | Control | . 237 . | Client | . 238 . +----------------+ . 239 . . 240 . Conferencing Client . 241 ........................................................ 243 Figure 1: Conference Client Interaction 245 CCMP serves as the Conference Control Protocol, allowing the 246 conference control client to interface with the conference object 247 maintained by the conferencing system, as represented in Figure 1. 248 Conference Control is one part of functionality for advanced 249 conferencing supported by a conferencing client. Other functions are 250 discussed in the XCON framework and related documents. 252 Conference object and conference users do represent key elements 253 involved in Conference Control operations. Their identifiers are 254 widely used for creating the CCMP requests and responses. Such 255 identifiers, used in CCMP for the conference object (XCON-URI) and 256 conference user (XCON-USERID), are introduced in the XCON framework 257 and defined in the XCON data model [I-D.ietf-xcon-common-data-model]. 258 The main conference objects and users features are briefly described 259 in the following subsections. 261 4.1. Conference Objects 263 Conference objects feature a simple dynamic inheritance-and-override 264 mechanism. Conference objects are linked into a tree known as 265 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 266 node inherits attributes from its parent node. The roots of these 267 inheritance trees are also known as "blueprints". Nodes in the 268 inheritance tree can be active conferences or simply descriptions 269 that do not currently have any resources associated with them. An 270 object can mark certain of its properties as unalterable, so that 271 they cannot be overridden. 273 The schema for the conference object is defined in the XCON data 274 model. Conference objects are uniquely identified by the XCON-URI. 275 A client MAY specify a parent object (a conference or blueprint) from 276 which to inherit values. 278 4.2. Conference Users 280 Each conference can have zero or more users. All conference 281 participants are users, but some users may have only administrative 282 functions and do not contribute or receive media. Users are added 283 one user at a time to simplify error reporting. When a conference is 284 cloned from a parent object, users are inherited as well, so that it 285 is easy to set up a conference that has the same set of participants 286 or a common administrator. The Conference Control Server creates 287 individual users, assigning them a unique Conference User Identifier 288 (XCON-USERID). 290 A variety of elements defined in the common element 291 as specified in the XCON data model are used to determine how a 292 specific user expects and is allowed to join a conference as a 293 participant or as a user with specific privileges (e.g., observer). 294 For example, each element representing a user in the 295 conference shows a "method" attribute which 296 defines how the user is expected to join the conference, i.e. 297 "dial-in" for users that are allowed to dial, "dial-out" for users 298 that the conference focus will be trying to reach. "dial-in" is the 299 default. If the conference is currently active, dial-out users are 300 contacted immediately; otherwise, they are contacted at the start of 301 the conference. The conference control protocol provides a mean to 302 manipulate these and other kinds of user-related features. 304 The conference control server assigns a unique Conference User 305 Identifier (XCON-USERID) to each conferencing system user. The 306 conference control server uses the XCON-USERID to change or delete 307 elements. Depending upon policies and privileges, specific 308 conference control clients MAY also manipulate elements. 310 5. Protocol Overview 312 CCMP is a client-server, XML-based, state-less protocol, which has 313 been specifically conceived to provide users with the necessary means 314 for the creation, retrieval, modification and deletion of conference 315 objects. 317 Section 5.1 specifies the basic operations that can create, retrieve, 318 modify and delete conference-related information in a centralized 319 conference. The core set of objects manipulated in the CCMP protocol 320 includes conference blueprints, the conference object, users, and 321 sidebars. 323 Conference-related information is encapsulated into CCMP messages in 324 the form of documents or document fragments compliant with the XCON 325 data model representation. Implementation details are presented in 326 Section 5.2 328 5.1. Protocol Operations 330 The main operations provided by CCMP belong in four general 331 categories: 333 create: for the creation of a conference, a conference user, a 334 sidebar, or a blueprint. 336 retrieve: to get information about the current state of either a 337 conference object (be it an actual conference or a blueprint, or a 338 sidebar) or a conference user. A retrieve operation can also be 339 used to obtain the XCON-URIs of the active conferences and/or 340 blueprints available at the server. 342 update: to modify the current features of a specified conference or 343 conference user. 345 delete: to remove from the system a conference object or a 346 conference user. 348 Thus, the main targets of CCMP operations are: 350 o conference objects associated with either active or registered 351 conferences, 353 o conference objects associated with blueprints, 355 o conference objects associated with sidebars, both embedded in the 356 main conference (i.e. elements) and external 357 to it (i.e. elements), 359 o elements associated with conference users, 361 o the list of XCON-URIs related to conferences and blueprints 362 available at the server, for which only retrieval operations are 363 allowed. 365 Each operation in the protocol model is atomic and either succeeds or 366 fails as a whole. The conference server MUST ensure that the 367 operations are atomic in that the operation invoked by a specific 368 conference client completes prior to another client's operation on 369 the same conference object. The details for this data locking 370 functionality are out of scope for the CCMP protocol specification 371 and are implementation specific for a conference server. Thus, the 372 conference server first checks all the parameters, before making any 373 changes to the internal representation of the conference object. For 374 example, it would be undesirable to change the of the 375 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 377 can modify the same conference objects, conference clients SHOULD 378 first obtain the current object from the conference server and then 379 update the relevant data elements in the conference object prior to 380 invoking a specific operation on the conference server. In order to 381 effectively manage modifications to conference data, a versioning 382 approach is exploited in the CCMP. More precisely, each conference 383 object is associated with a version number indicating the most up to 384 date view of the conference at the server's side. Such version 385 number is reported to the clients when answering their requests. A 386 client willing to make modifications to a conference object has to 387 send an update message to the server. In case the modifications are 388 all successfully applied, the server sends back to the client a 389 "success" response which also carries information about the current 390 server-side version of the modified object. With such approach, a 391 client which is working on version "X" of a conference object and 392 finds inside a "success" response a version number which is "X+1" can 393 be sure that the version it was aware of was the most up to date. On 394 the other hand, if the "success" response carries back a version 395 which is at least "X+2", the client can detect that the object that 396 has been modified at the server's side was more up to date than the 397 one it was working upon. This is clearly due to the effect of 398 concurrent modification requests issued by independent clients. 399 Hence, for the sake of having available the latest version of the 400 modified object, the client can send to the conference server a 401 further "retrieve" request. In no case a copy of the conference 402 object available at the server is returned to the client as part of 403 the update response message. Such a copy can always be obtained 404 through an ad-hoc "retrieve" message. Based on the above 405 considerations, all CCMP response messages except those associated 406 with the retrieval of either the list of blueprints or the list of 407 conferences will have to contain a mandatory "version" parameter. 408 This does not hold for request messages, for which the "version" 409 parameter is not at all required, since it represents useless 410 information for the server: as long as the required modifications can 411 be applied to the target conference object with no conflicts, the 412 server does not care whether or not the client had an up to date view 413 of the information stored at its side. This said, it stands clear 414 that a client which has subscribed at the server, through the XCON 415 event package [I-D.ietf-xcon-event-package], to notifications about 416 conference object modifications, will always have the most up to date 417 version of that object available at his side. 419 5.2. Implementation Approach 421 There have been a number of different proposals as to the most 422 suitable implementation solution for the CCMP. A non-exhaustive 423 summary of the most interesting ones is provided in Appendix A. The 424 solution for the CCMP defined in this document is viewed as a good 425 compromise amongst the most notable past candidates and is referred 426 to as "HTTP transport plus CCMP body". With this approach, CCMP is 427 able to take advantage of existing HTTP functionality. As with SOAP, 428 the CCMP uses a "single HTTP verb" for transport (i.e. a single 429 transaction type for each request/response pair); this allows 430 decoupling CCMP messages from HTTP messages. Similarly, as with any 431 RESTful approach, CCMP messages are inserted directly in the body of 432 HTTP messages, thus avoiding any unnecessary processing and 433 communication burden associated with further intermediaries. With 434 this approach, no modification to the CCMP messages/operations is 435 required to use a different transport protocol. 437 The remainder of this document focuses on the selected approach. The 438 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 439 POST operations and retrieves responses from the body of HTTP "200 440 OK" messages. CCMP messages have a MIME-type of "application/ 441 ccmp+xml", which appears inside the "Content-Type" and "Accept" 442 fields of HTTP requests and responses. Section 10 provides the 443 complete requirements for an HTTP implementation to support the CCMP. 445 6. CCMP messages 447 CCMP messages are either requests or responses. The general CCMP 448 request message is defined in Section 6.1. The general CCMP response 449 message is defined in Section 6.2. The details of the specific 450 message type which is carried in the CCMP request and response 451 messages are described in Section 6.3. CCMP response codes are 452 listed in Section 6.4 454 6.1. CCMP Request Message Type 456 A CCMP request message is comprised of the following parameters: 458 confUserId: An optional parameter containing the XCON-USERID of the 459 client. The "confUserID" parameter is used to determine if the 460 conference control client has the authority to perform the 461 operation, as well as other Authorization, Authentication and 462 Accounting (AAA) procedures. The attribute is REQUIRED in the 463 CCMP request and response messages with the exception of the case 464 of a user who has no XCON-USERID and who wants to enter, via CCMP, 465 a conference whose identifier is known. In such case, a side- 466 effect of the request is that the user is provided with an 467 appropriate XCON-USERID. An example of the above mentioned case 468 will be provided in Section 6.3.6. 470 confObjId: An optional parameter containing the XCON-URI of the 471 target conference object. 473 operation: An optional parameter refining the type of specialized 474 request message. The "operation" parameter is REQUIRED in all 475 requests except for the "blueprintsRequest" and "confsRequest" 476 specialized messages. 478 password: An optional parameter that MUST be inserted in all 479 requests whose target conference object is password-protected (as 480 per the element in 481 [I-D.ietf-xcon-common-data-model]). 483 specialized request message: This is specialization of the generic 484 request message (e.g., blueprintsRequest), containing parameters 485 that are dependent on the specific request sent to the server. A 486 specialized request message MUST be included in the CCMP request 487 message. The details for the specialized messages and associated 488 parameters are provided in Section 6.3. 490 492 494 495 496 498 499 501 503 505 506 508 510 512 514 515 517 Figure 2: Structure of CCMP Request messages 519 6.2. CCMP Response Message Type 521 A CCMP response message is comprised of the following parameters: 523 confUserId: A mandatory parameter in CCMP response messages 524 containing the XCON-USERID of the conferencing client who issued 525 the CCMP request message. 527 confObjId: An optional parameter containing the XCON-URI of the 528 target conference object. 530 operation: An optional parameter for CCMP response messages. This 531 parameter is REQUIRED in all responses except for the 532 "blueprintsResponse" and "confsResponse" specialized messages. 534 response-code: A mandatory parameter containing the response code 535 associated with the request. The response code MUST be chosen 536 from the codes listed in Section 6.4. 538 response-string: An optional reason string associated with the 539 response. In case of an error, in particular, such string can be 540 used to provide the client with detailed information about the 541 error itself. 543 specialized response message: This is specialization of the generic 544 response message, containing parameters that are dependent on the 545 specific request sent to the server (e.g., blueprintsResponse). A 546 specialized response message SHOULD be included in the CCMP 547 response message, except in an error situation where the CCMP 548 request message did not contain a valid specialized message. In 549 this case, the conference server MUST return a responseCode of 550 "badRequest". The details for the specialized messages and 551 associated parameters are provided in Section 6.3. 553 555 557 558 559 561 562 564 566 568 569 571 573 575 577 579 581 582 584 Figure 3: Structure of CCMP Response message 586 6.3. Detailed messages 588 Based on the request and response message structures described in 589 Section 6.1 and Section 6.2, the following summarizes the specialized 590 CCMP request/response types described in this document: 592 1. blueprintsRequest/blueprintsResponse 594 2. confsRequest/confsResponse 596 3. blueprintRequest/blueprintResponse 598 4. confRequest/confResponse 599 5. usersRequest/usersResponse 601 6. userRequest/userResponse 603 7. sidebarsByValRequest/sidebarsByValResponse 605 8. sidebarsByRefRequest/sidebarsByRefResponse 607 9. sidebarByValRequest/sidebarByValResponse 609 10. sidebarByRefRequest/sidebarByRefResponse 611 These CCMP request/response pairs use the fundamental CCMP operations 612 as defined in Section 5.1 to manipulate the conference data. Table 1 613 summarizes the CCMP operations and corresponding actions that are 614 valid for a specific CCMP request type, noting that neither the 615 blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse 616 require an "operation" parameter. The corresponding response MUST 617 contain the same operation. Note that some entries are labeled "N/A" 618 indicating the operation is invalid for that request type. In the 619 case of an "N/A*", the operation MAY be allowed for specific 620 privileged users or system administrators, but is not part of the 621 functionality included in this document. 623 +---------------+------------+------------+------------+------------+ 624 | Operation | Retrieve | Create | Update | Delete | 625 | ------------- | | | | | 626 | -Request Type | | | | | 627 +---------------+------------+------------+------------+------------+ 628 | blueprintsReq | Get list | N/A | N/A | N/A | 629 | uest | of | | | | 630 | | blueprints | | | | 631 | | | | | | 632 | ------------- | ---------- | ---------- | ---------- | ---------- | 633 | | | | | | 634 | blueprintRequ | Get | N/A* | N/A* | N/A* | 635 | est | blueprint | | | | 636 | | | | | | 637 | ------------- | ---------- | ---------- | ---------- | ---------- | 638 | | | | | | 639 | confsRequest | Get list | N/A | N/A | N/A | 640 | | of confs | | | | 641 | | (active, | | | | 642 | | etc.) | | | | 643 | | | | | | 644 | ------------- | ---------- | ---------- | ---------- | ---------- | 645 | | | | | | 646 | confRequest | Gets | Creates | Changes | Deletes | 647 | | conference | conference | conference | conference | 648 | | object or | object | object | Object as | 649 | | blueprint | | | a whole | 650 | | | | | | 651 | ------------- | ---------- | ---------- | ---------- | ---------- | 652 | | | | | | 653 | usersRequest | Gets | N/A | Changes | N/A | 654 | | specific | | specified | | 655 | | users | | users | | 656 | | element | | element | | 657 | | | | | | 658 | ------------- | ---------- | ---------- | ---------- | ---------- | 659 | | | | | | 660 | userRequest | Gets | Adds a | Changes | Deletes | 661 | | specific | user to a | specified | user | 662 | | user | conf (**) | user | element as | 663 | | element | | element | a whole | 664 | | | | | | 665 | ------------- | ---------- | ---------- | ---------- | ---------- | 666 | | | | | | 667 | sidebarsByVal | Gets | N/A | N/A | N/A | 668 | Request | sidebars-b | | | | 669 | | y -val | | | | 670 | | element | | | | 671 | ------------- | ---------- | ---------- | ---------- | ---------- | 672 | | | | | | 673 | sidebarsByRef | Gets | N/A | N/A | N/A | 674 | Request | sidebars-b | | | | 675 | | y -ref | | | | 676 | | element | | | | 677 | | | | | | 678 | ------------- | ---------- | ---------- | ---------- | ---------- | 679 | | | | | | 680 | sidebarByValR | Gets a | Creates a | Adds or | Removes/ | 681 | equest | sidebar | sidebar by | modifies a | deletes | 682 | | element | cloning | sidebar | entire | 683 | | | existing | | sidebar | 684 | | | conf | | | 685 | | | object | | | 686 | | | | | | 687 | ------------- | ---------- | ---------- | ---------- | ---------- | 688 | | | | | | 689 | sidebarByRefR | Gets a | Creates | Adds or | Removes/ | 690 | equest | sidebar | sidebar by | modifies | deletes | 691 | | element | cloning | sidebar | entire | 692 | | | existing | | sidebar | 693 | | | conf | | | 694 | | | object | | | 695 +---------------+------------+------------+------------+------------+ 697 Table 1: Request Type Operation Specific Processing 699 (**): This operation can involve the creation of an XCON-UserID, if 700 the sender does not add it in the "confUserId" parameter, or if the 701 "entity" field of the userInfo parameter is void. 703 Additional parameters included in the specialized CCMP request/ 704 response messages are detailed in the subsequent sections. 706 6.3.1. blueprintsRequest and blueprintsResponse 708 A "blueprintsRequest" (Figure 4) message is sent to request the list 709 of XCON-URIs associated with the available blueprints from the 710 conference server. Such URIs can be subsequently used by the client 711 to access detailed information about a specified blueprint with a 712 specific "blueprintRequest" message per Section 6.3.3. A 713 "blueprintsRequest" message REQUIRES no additional parameters beyond 714 those specified for the basic CCMP request message. The "confObjId" 715 and "operation" parameters MUST NOT be included in the request or 716 response for this transaction. 718 The associated "blueprintsResponse" message SHOULD contain, as shown 719 in Figure 4, a "blueprintsInfo" parameter containing the above 720 mentioned XCON-URI list. If the "blueprintsInfo" parameter is empty, 721 the conference control client MAY attempt to use a local default 722 blueprint to create conferences. However, the handling in this 723 situation is specific to the conference control client 724 implementation. 726 727 728 729 730 731 733 734 735 736 737 738 739 740 741 742 744 746 749 750 751 753 754 756 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 757 messages 759 6.3.2. confsRequest and confsResponse 761 A "confsRequest" message is used to retrieve, from the server, the 762 list of XCON-URIs associated with active and registered conferences A 763 "confsRequest" message REQUIRES no additional parameters beyond those 764 specified for the basic CCMP request message. The "confObjId" 765 parameter MUST NOT be included in the confsRequest message. The 766 "confsRequest" message is of a "retrieve-only" type, since the sole 767 purpose is to collect information available at the conference server. 768 Thus, an "operation" parameter MUST NOT be included in a 769 "confsRequest" message. The associated "confsResponse" message 770 SHOULD contain the list of XCON-URIs in the "confsInfo" parameter. A 771 user, upon receipt of the response message, can interact with the 772 available conference objects through further CCMP messages. 774 775 776 777 778 779 781 782 783 784 785 786 787 788 789 790 792 794 796 797 798 800 801 802 Figure 5: Structure of the confsRequest and confsResponse messages 804 6.3.3. blueprintRequest and blueprintResponse 806 Through a "blueprintRequest", a client can manipulate the conference 807 object associated with a specified blueprint. The request MUST 808 include an "operation" parameter and a "confObjId" parameter. The 809 "confObjId" parameter MUST contain the XCON-URI of the blueprint, 810 which might have been previously retrieved through a 811 "blueprintsRequest" message. The blueprintRequest message SHOULD NOT 812 contain an "operation" parameter other than "retrieve". The 813 "create", "update" and "delete" operations SHOULD NOT be included in 814 a "blueprintRequest" message except in the case of privileged users 815 (e.g. the conference server administration staff). 817 In the case of responseCode of "success" for a "retrieve" operation, 818 the "blueprintInfo" parameter MUST be included in the 819 "blueprintResponse" message. The "blueprintInfo" parameter contains 820 the conference document associated with the blueprint as identified 821 by the "confObjID" parameter specified in the blueprintRequest. 823 If a response code fo "objectNotFound" is received in a 824 "blueprintResponse" message, a conference control client may attempt 825 to retrieve another conference blueprint if more than one had been 826 received in the "blueprintsResponse" message. If there was only one 827 blueprint in the "blueprintsResponse" initially, then the client 828 should send another "blueprintsRequest" message to determine if there 829 may be new or additional blueprints for the specific conferencing 830 system. If this "blueprintsResponse" message contains no blueprints, 831 the handling is specific to the conference control client. 833 834 835 836 837 838 839 840 841 842 844 846 848 849 850 852 853 855 856 857 858 859 860 861 862 863 864 866 868 870 871 872 873 874 876 Figure 6: Structure of the blueprintRequest and blueprintResponse 877 messages 879 6.3.4. confRequest and confResponse 881 With a "confRequest" message, CCMP clients can manipulate conference 882 objects associated with either active or registered conferences 883 (blueprints or reservations). The request MUST include an 884 "operation" parameter. Depending upon the type of "operation" a 885 "confObjId" parameter MAY be included. The "confObjId" parameter 886 contains the XCON-URI of the specific active or registered 887 conference. The requirements for inclusion of "confInfo" parameter 888 depends upon the specific "operation" in the confRequest/confResponse 889 and are detailed below. The detailed information included in the 890 "confInfo" parameter MUST follow the rules as specified in the XCON 891 Data Model document [I-D.ietf-xcon-common-data-model]. 893 To create a new conference through a "confRequest" message, two 894 approaches can be considered: 896 1. Creation through explicit cloning: the "confObjId" parameter MUST 897 contain the XCON-URI of the blueprint to be cloned, while the 898 "confInfo" parameter MUST NOT be included in the confRequest; 900 2. Creation through implicit cloning (also known as "direct 901 creation"): the "confObjId" parameter MUST NOT be included in the 902 request, whereas the "confInfo" parameter describing the 903 conference to be created MUST be included in the confRequest. 905 In both cases, the confResponse, for a successful completion of a 906 "create" operation, contains a responseCode of "success" and MUST 907 contain the XCON-URI of the created conference in the "confObjID" 908 parameter. In addition, the "confInfo" parameter transporting the 909 created conference document MAY be included. Obviously, the newly 910 created object can be manipulated by the client through a subsequent 911 "update" operation. For example, after the creation and addition of 912 the participants, the creator may want to lock the conference object. 913 This can be accomplished with a confRequest with an operation of 914 "update" by setting the "locked" element in the confInfo included in 915 the confRequest message described below. 917 In the case of a confRequest with a "retrieve" operation, the 918 "confObjId" representing the XCON-URI of the target conference the 919 conference control client MUST be included and the "confInfo" 920 parameter SHOULD NOT be included in the request. The conferencing 921 server MUST ignore any "confInfo" parameter that is received in a 922 "confRequest" and this "confInfo" parameter MUST NOT be included in 923 the confResponse. If the confResponse for the "retrieve" operation 924 contains a responseCode of "success", the "confInfo" parameter MUST 925 be included in the response. The "confInfo" parameter MUST contain 926 the entire conference document describing the target conference 927 object in its current state. 929 In case of a confRequest with an "update" operation, the "confInfo" 930 and "confObjID" MUST be included in the request. The "confInfo" 931 represents an object of type "conference-type" containing all the 932 changes to be applied to the conference whose identifier is 933 "confObjId". In the case of a confResponse with a responseCode of 934 "success", no additional information is required in the 935 "confResponse" message. A responseCode of "success" indicates that 936 the referenced conference document has been changed by the conference 937 server. A responseCode of "changeFailedProtected" indicates that the 938 conferencing client is not allowed to make the changes reflected in 939 the "confInfo" in the initial request. This could be due to 940 policies, roles, specific privileges, etc.), with the reason specific 941 to a conferencing system and its configuration. Thus, it is 942 RECOMMENDED that the client continue using the previous version of 943 the "confInfo", if the conference was active. If the conference was 944 not active, it is RECOMMENDED that the client revert to an original 945 version of the blueprint or use another blueprint - one previously 946 retrieved with a blueprintRequest or one obtained via a new 947 blueprintsRequest/blueprintRequest sequence. 949 In the case of a confRequest with a "delete" operation, the 950 "confObjId" representing the XCON-URI of the target conference MUST 951 be included and the "confInfo" SHOULD NOT be included in the request. 952 The conferencing server MUST ignore any "confInfo" parameter that is 953 received. The confResponse MUST contain the same "confObjId" that 954 was included in the confRequest. The confResponse MUST contain a 955 responseCode of "success" if the targeted conference is successfully 956 deleted. If the confResponse for the "retrieve" operation contains a 957 responseCode of "success", the confResponse SHOULD NOT contain the 958 "confInfo" parameter. If the conferencing server cannot delete the 959 conference referenced by the "confObjId" received in the confRequest 960 because it is the parent of another conference object that is in use, 961 the conferencing server MUST return a responseCode of 962 "deleteParentFailed". 964 The schema for the confRequest/confResponse pair is shown in 965 Figure 7. 967 968 969 970 971 972 973 974 975 976 978 980 982 983 984 986 987 989 990 991 992 993 994 995 996 997 998 1000 1002 1004 1005 1006 1007 1008 1010 Figure 7: Structure of the confRequest and confResponse messages 1012 The following provides an example of the "confInfo" parameter 1013 required to change the title of a conference: 1015 1016 1017 New conference title 1018 1019 1021 Figure 8: Updating a conference object: modifying the title of a 1022 conference 1024 Similarly, to remove the title of an existing conference, an "update" 1025 operation carrying the following "confInfo" parameter would do the 1026 job. 1028 1029 1030 1031 1032 1034 Figure 9: Updating a conference object: removing the title of a 1035 conference 1037 6.3.5. usersRequest and usersResponse 1039 Through a usersRequest message the CCMP client manipulates the 1040 element of the conference document associated with the 1041 conference identified by the "confObjId" parameter. Inside the 1042 element, along with the list of conference users, there is 1043 information that the client may be interested in controlling, such as 1044 the lists of users to which access to the conference is allowed/ 1045 denied, conference participation policies, etc.; for this reason, a 1046 customized message has been designed to allow for the manipulation of 1047 this specific part of a conference document. 1049 A "usersInfo" parameter MAY be included in a usersRequest message 1050 depending upon the operation. If the "usersInfo" parameter is 1051 included in the usersRequest message, the parameter MUST be compliant 1052 with the field of the XCON data model. 1054 Two operations are allowed for a "usersRequest" message: 1056 1. "retrieve": In this case the request MUST NOT include a 1057 "usersInfo" parameter, while a successful response MUST contain 1058 the desired element in the "usersInfo" parameter. The 1059 conference server MUST be ignore a "usersInfo" parameter if it is 1060 received in a request with a "retrieve" operation. 1062 2. update: In this case, the "usersInfo" parameter MUST contain the 1063 modifications to be applied to the referred element. If 1064 the responseCode is "success", then the "usersInfo" parameter 1065 SHOULD NOT be returned. Any "usersInfo" parameter that is 1066 returned SHOULD be ignored. A responseCode of 1067 "changeFailedProtected" indicates that the conferencing client is 1068 not allowed to make the changes reflected in the "usersInfo" in 1069 usersRequest message. This could be due to policies, roles, 1070 specific privileges, etc.), with the reason specific to a 1071 conferencing system and its configuration. Thus, it is 1072 RECOMMENDED that the client continue using the previous version 1073 of the "usersInfo". 1075 Operations of "create" and "delete" are not applicable to a 1076 usersRequest message and MUST NOT be considered by the server, which 1077 means that a responseCode of "forbidden" MUST be included in the 1078 usersResponse message. 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1091 1093 1095 1096 1097 1099 1100 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1113 1115 1117 1118 1119 1120 1121 1123 Figure 10: Structure of the usersRequest and usersResponse messages 1125 6.3.6. userRequest and userResponse 1127 A "userRequest" message is used to manipulate elements inside 1128 a conference document associated with a conference identified by the 1129 "confObjId" parameter. Besides retrieving information about a 1130 specific conference user, the message is used to request that the 1131 conference server either create, modify, or delete information about 1132 a user. A "userRequest" message MUST include the "confObjID", the 1133 "operation" parameter, and MAY include a "userInfo" parameter 1134 containing the detailed user's information depending upon the 1135 operation and whether the "userInfo" has already been populated for a 1136 specific user. Note that a user may not necessarily be a 1137 conferencing control client (i.e., some participants in a conference 1138 are not "XCON aware"). 1140 An XCON-USERID SHOULD be assigned to each and every user subscribed 1141 to the system. In such a way, a user who is not a conference 1142 participant can make requests (provided she has successfully passed 1143 AAA checks), like creating a conference, retrieving conference 1144 information, etc.. 1146 Conference users can be created in a number of different ways. In 1147 each of these cases the operation MUST be set to "create" in the 1148 userRequest message. Each of the userResponse messages for these 1149 cases MUST include the "confObjID", "confUserID", "operation" and 1150 "responseCode" parameters. In the case of a response code of 1151 "success", the userResponse message MAY include the "userInfo" 1152 parameter depending upon the manner in which the user was created: 1154 o Conferencing client with an XCON-USERID adds itself to the 1155 conference: In this case, the "userInfo" parameter MAY be included 1156 in the userRequest. The "userInfo" parameter MUST contain a 1157 element (compliant with the XCON data model) and the 1158 "entity" attribute MUST be set to a value which represents the 1159 XCON-USERID of the user initiating the request. No additional 1160 parameters beyond those previously described are required in the 1161 userResponse message, in the case of a responseCode of "success". 1163 o Conferencing client acts on behalf of a third user whose XCON- 1164 USERID is known: in this case, the "userInfo" parameter MUST be 1165 included in the userRequest. The "userInfo" parameter MUST 1166 contain a element and the "entity" attribute value MUST be 1167 set to the XCON-USERID of the third user in question. No 1168 additional parameters beyond those previously described are 1169 required in the userResponse message, in the case of a 1170 responseCode of "success". 1172 o A conferencing client who has no XCON-USERID and who wants to 1173 enter, via CCMP, a conference whose identifier is known. In such 1174 case, a side-effect of the request is that the user is provided 1175 with an appropriate XCON-USERID. The involved messages 1176 (userRequest and userResponse) in such case should look like the 1177 following: 1179 Request fields: 1181 confUserId=null; 1182 confObjId=confXYZ; 1183 operation=create; 1184 userInfo= 1186 1187 1188 ... 1190 Response fields (in case of success): 1192 confUserId=user345; 1193 confObjId=confXYZ; 1194 operation=create; 1195 response-code=success; 1196 userInfo=null; //or the entire userInfo object 1198 Figure 11: userRequest and userResponse in the absence of an xcon- 1199 userid 1201 o Conferencing client is unaware of the XCON-USERID of a third user: 1202 In this case, the "entity" attribute MUST NOT be included in the 1203 request. The XCON-USERID generated by the conference server for 1204 such a user MUST also be returned to the client as the value of 1205 the "entity" attribute in the "userInfo" parameter of the response 1206 if the responseCode is "success". This scenario is mainly 1207 intended to support the case whereby an XCON aware client is added 1208 to a conference by a third party, e.g. the chairperson of the 1209 conference. 1211 o Conferencing client obtains a new user profile in the context of a 1212 conference: this case is handled in the same manner as the 1213 previous case associated with the creation of a user on behalf of 1214 a third party when the XCON-USERID is unknown, thus indicating to 1215 the conference server that the client wants a new XCON-USERID and 1216 associated "userInfo" parameter to be allocated and populated 1217 respectively. 1219 In the case of a userRequest with a "retrieve" operation, the 1220 "confObjId" representing the XCON-URI of the target conference MUST 1221 be included. The "confUserId" MUST be included in the userRequest 1222 message. This "confUserId" indicates the specific element in 1223 XCON data model, as reflected by the "entity" attribute in the 1224 element that the conference client is requesting to retrieve. The 1225 "userInfo" parameter MUST NOT be included in the request. The 1226 conferencing server MUST ignore any "userInfo" parameter that is 1227 received in a "userRequest" and this "userInfo" parameter MUST NOT be 1228 included in the userResponse. If the userResponse for the "retrieve" 1229 operation contains a responseCode of "success", the "userInfo" 1230 parameter MUST be included in the response. 1232 In case of a userRequest with an "update" operation, the "confObjID", 1233 "confUserID" and "userInfo" MUST be included in the request. The 1234 "userInfo" is of type "user-type" and contains all the changes to be 1235 applied to a specific element in the conference object 1236 identified by the "confObjId" in the userRequest message. In the 1237 case of a user Response with a responseCode of "success", no 1238 additional information is required in the "confResponse" message. A 1239 responseCode of "success" indicates that the referenced user element 1240 has been updated by the conference server. A responseCode of 1241 "changeFailedProtected" indicates that the conferencing client is not 1242 allowed to make the changes reflected in the "userInfo" in the 1243 initial request. This could be due to policies, roles, specific 1244 privileges, etc., with the reason specific to a conferencing system 1245 and its configuration. Thus, it is RECOMMENDED that the client 1246 continue using the previous version of the "userInfo". 1248 In the case of a userRequest with a "delete" operation, the 1249 "confObjId" representing the XCON-URI of the target conference and 1250 the "confUserID" associated with the specific element (i.e., 1251 matching the "entity" attribute) that the conferencing client is 1252 requesting to be deleted MUST be included in the userRequest message. 1253 The userResponse MUST contain the same "confObjId" that was included 1254 in the userRequest. The userResponse MUST contain a responseCode of 1255 "success" if the target element has been successfully deleted. 1256 If the userResponse for the "delete" operation contains a 1257 responseCode of "success", the userResponse MUST NOT contain the 1258 "userInfo" parameter. 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1271 1273 1275 1276 1277 1279 1280 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1293 1295 1297 1298 1299 1300 1301 1303 Figure 12: Structure of the userRequest and userResponse messages 1305 6.3.7. sidebarsByValRequest and sidebarsByValResponse 1307 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1308 on the field of the conference object represented 1309 by the "confObjId". The "sidebarsByValRequest" message is of a 1310 "retrieve-only" type, so an "operation" parameter MUST NOT be 1311 included in a "sidebarsByValRequest" message. A 1312 "sidebarsByValResponse" with a responseCode of "success" MUST contain 1313 a "sidebarsByValInfo" parameter containing the desired element. The "sidebarsByValInfo" parameter contains the list of 1315 the conference objects associated with the sidebars by value derived 1316 from the main conference. The retrieved sidebars can then be updated 1317 or deleted using the "sidebarByValRequest" message, which is 1318 described in Section 6.3.8. 1320 1322 1323 1324 1325 1326 1327 1328 1329 1330 1332 1334 1337 1338 1339 1341 1342 1344 1346 1347 1348 1349 1350 1351 1352 1353 1354 1356 1358 1361 1362 1363 1365 1366 1367 Figure 13: Structure of the sidebarsByValRequest and 1368 sidebarsByValResponse messages 1370 6.3.8. sidebarByValRequest and sidebarByValResponse 1372 A sidebarByValRequest message MUST contain the "operation" parameter 1373 which discriminates among retrieval, creation, modification and 1374 deletion of a specific sidebar. The other required parameters depend 1375 upon the type of operation. 1377 In the case of a "create" operation, the "confObjId" parameter MUST 1378 be included in the sidebyValRequest message. In this case, the 1379 "confObjID" parameter contains the XCON-URI of the main conference in 1380 which the sidebar is to be created. The "sidebarByValInfo" parameter 1381 SHOULD NOT be included in the request, since, as envisaged in the 1382 XCON framework ([RFC5239]), sidebars are always created by cloning 1383 the main conference. Any "sidebarByValInfo" included in the request 1384 MUST be ignored. The conference server sets the "active" element to 1385 "false" of the cloned conference to reflect that it is a "reserved" 1386 conference. The conference server MUST update the conference object 1387 reflected by the "confObjID" parameter, in the sidebarbyVal request 1388 message, from which the sidebar was created to reflect the newly 1389 created sidebar. The newly created conference object MAY be included 1390 in the response in the "sidebarByValInfo" parameter, if the 1391 responseCode is "success". The URI of the conference object 1392 associated with the newly created sidebar object MUST appear in the 1393 "confObjId" parameter of the response. The conference server can 1394 notify any conferencing clients that have subscribed to the 1395 conference event package, and are authorized to receive the 1396 notifications, of the addition of the sidebar to the conference. 1398 In the case of a "sidebarByVal" request with an operation of 1399 "retrieve", the URI for the conference object created for the sidebar 1400 (received in the response to a "create" operation or in a 1401 sidebarsByValResponse message) MUST be included in the "confObjID" 1402 parameter in the request. This "retrieve" operation is handled by 1403 the conference server in the same manner as a "retrieve" operation 1404 included in a confRequest message as detailed in Section 6.3.4. 1406 In the case of a "sidebarByVal" request with an operation of 1407 "update", the "sidebarByValInfo" MUST also be included in the 1408 request. The "confObjID" parameter contained in the request message 1409 identifies the specific sidebar instance to be updated. An "update" 1410 operation on the "sidebarByValInfo" is handled by the conference 1411 server in the same manner as an "update" operation on the confInfo 1412 included in a confRequest message as detailed in Section 6.3.4. 1414 If an "operation" of "delete" is included in the sidebarByVal 1415 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1416 request. Any "sidebarByValInfo" included in the request MUST be 1417 ignored by the conference server. The URI for the conference object 1418 associated with the sidebar MUST be included in the "confObjID" 1419 parameter in the request. If the specific conferencing user as 1420 reflected by the "confUserID" in the request is authorized to delete 1421 the conference, the conference server deletes the conference object 1422 reflected by the "confObjID" parameter and updates the data in the 1423 conference object from which the sidebar was cloned. The conference 1424 server can notify any conferencing clients that have subscribed to 1425 the conference event package, and are authorized to receive the 1426 notifications, of the deletion of the sidebar to the conference. 1428 1430 1431 1432 1433 1434 1435 1436 1437 1438 1440 1442 1445 1446 1447 1449 1450 1452 1454 1455 1456 1457 1458 1459 1460 1461 1462 1464 1466 1469 1470 1471 1473 1474 1475 Figure 14: Structure of the sidebarByValRequest and 1476 sidebarByValResponse messages 1478 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1480 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1481 invoked to retrieve the element of the conference 1482 object identified by the "confObjId" parameter. The 1483 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1484 "operation" parameter MUST NOT be included in a 1485 "sidebarsByRefRequest" message. In the case of a responseCode of 1486 "success", the "sidebarsByRefInfo" parameter, containing the 1487 element of the conference object, MUST be included 1488 in the response. The element represents the set of 1489 URIs of the sidebars associated with the main conference, whose 1490 description (in the form of a standard XCON conference document) is 1491 external to the main conference itself. Through the retrieved URIs, 1492 it is then possible to access single sidebars using the 1493 "sidebarByRef" request message, described in Section 6.3.10. 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1506 1508 1511 1512 1513 1515 1516 1518 1520 1521 1522 1523 1524 1525 1526 1527 1528 1530 1532 1535 1536 1537 1539 1540 1541 Figure 15: Structure of the sidebarsByRefRequest and 1542 sidebarsByRefResponse messages 1544 6.3.10. sidebarByRefRequest and sidebarByRefResponse 1546 A sidebarByRefRequest message MUST contain the "operation" parameter 1547 which discriminates among retrieval, creation, modification and 1548 deletion of a specific sidebar. The other required parameters depend 1549 upon the type of operation. 1551 In the case of an "operation of "create", the "confObjId" parameter 1552 representing the XCON-URI of the conference from which the sidebar is 1553 to be created (cloned) MUST be included in all sidebarByRefRequest 1554 messages. The "sidebarByRefInfo" parameter SHOULD NOT be included in 1555 the request, since, as envisaged in the XCON framework ([RFC5239]), 1556 sidebars are always created by cloning the main conference. Any 1557 "sidebarByRefInfo" included in the request MUST be ignored. If the 1558 creation of the sidebar is successful, the conference server MUST 1559 update the "sidebars-by-ref" element in the conference object from 1560 which the sidebar was created (i.e., as identified by the "confObjID" 1561 in the original sidebarByRef request), with the URI for the newly 1562 created sidebar. The newly created conference object MAY be included 1563 in the response in the "sidebarByRefInfo" parameter with a 1564 responseCode "success". The URI for the conference object associated 1565 with the newly created sidebar object MUST appear in the "confObjID" 1566 parameter of the response. The conference server can notify any 1567 conferencing clients that have subscribed to the conference event 1568 package, and are authorized to receive the notifications, of the 1569 addition of the sidebar to the conference. 1571 In the case of a "sidebarByRef" request with an operation of 1572 "retrieve", the URI for the conference object created for the sidebar 1573 MUST be included in the "confObjID" parameter in the request. A 1574 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1575 conference server in the same manner as a "retrieve" operation on the 1576 confInfo included in a confRequest message as detailed in 1577 Section 6.3.4. 1579 In the case of a "sidebarByRef" request with an operation of 1580 "update", the URI for the conference object created for the sidebar 1581 MUST be included in the "confObjID" parameter in the request. The 1582 "sidebarByRefInfo" MUST also be included in the request in the case 1583 of an "operation" of "update". An "update" operation on the 1584 "sidebarByRefInfo" is handled by the conference server in the same 1585 manner as an "update" operation on the confInfo included in a 1586 confRequest message as detailed in Section 6.3.4. 1588 If an "operation" of "delete" is included in the sidebarByRef 1589 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1590 request. Any "sidebarByRefInfo" included in the request MUST be 1591 ignored by the conference server. The URI for the conference object 1592 for the sidebar MUST be included in the "confObjID" parameter in the 1593 request. If the specific conferencing user as reflected by the 1594 "confUserID" in the request is authorized to delete the conference, 1595 the conference server SHOULD delete the conference object reflected 1596 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1597 element in the conference object from which the sidebar was 1598 originally cloned. The conference server can notify any conferencing 1599 clients that have subscribed to the conference event package, and are 1600 authorized to receive the notifications, of the deletion of the 1601 sidebar. 1603 1605 1606 1607 1608 1609 1610 1611 1612 1613 1615 1617 1620 1621 1622 1624 1625 1627 1629 1630 1631 1632 1633 1634 1635 1636 1637 1639 1641 1644 1645 1646 1648 1649 1650 Figure 16: Structure of the sidebarByRefRequest and 1651 sidebarByRefResponse messages 1653 6.4. CCMP Response Codes 1655 All CCMP response messages MUST include a "responseCode". The 1656 following summarizes the CCMP response codes: 1658 success: Successful completion of the requested operation. 1660 badRequest: Syntactically malformed request. 1662 objectNotFound: Target conference object missing at the server (it 1663 refers to the "confObjId" parameter in the generic request 1664 message) 1666 userNotFound: Target user missing at the server (it is related to 1667 the XCON-USERID in the "entity" attribute of the "userInfo" 1668 parameter when it is included in userRequests) 1670 invalidConfUserID: User missing at the server (this code is returned 1671 in the case of requests in which the "confUserID" of the sender is 1672 invalid). 1674 invalidPassword: Target conference object's password contained in 1675 the request is wrong. 1677 passwordRequired: Conference password missing in a request to access 1678 a password-protected conference object. 1680 unauthorized: User not allowed to perform the required operation. 1682 forbidden: Operation not allowed (e.g., cancellation of a 1683 blueprint). 1685 forbiddenDeleteParent: Cancel operation failed since the target 1686 object is a parent of child objects which depend on it, or because 1687 it effects, based on the "parent-enforceable" mechanism, the 1688 corresponding element in a child object. 1690 forbiddenChangeProtected: Update refused by the server because the 1691 target element cannot be modified due to its implicit dependence 1692 on the value of a parent object ("parent-enforceable" mechanism). 1694 requestTimeout: The time required to serve the request has exceeded 1695 the envisaged service threshold. 1697 serverInternalError: The server cannot complete the required service 1698 due to a system internal error. 1700 notImplemented: Operation envisaged in the protocol, but not 1701 implemented in the contacted server. 1703 updateFailed A generic error associated with all those situations in 1704 which a requested "update" cannot be successfully completed by the 1705 server. An example of such situation is when the modification of 1706 an object cannot be applied due to conflicts arising at the 1707 server's side (e.g. because the client version of the object is an 1708 obsolete one and the requested modifications collide with the up- 1709 to-date state of the object stored at the server). 1711 The handling of a "responseCode" of "objectNotFound", "userNotFound", 1712 "deleteParentFailed" and "changeFailedProtected" are only applicable 1713 to specific operations for specialized message responses and the 1714 details are provided in Section 6.3. The following table summarizes 1715 these "responseCodes" and the specialized message and operation to 1716 which they are applicable: 1718 +---------------+------------+------------+------------+------------+ 1719 | Response code | Create | Retrieve | Update | Delete | 1720 +---------------+------------+------------+------------+------------+ 1721 | updateFailed | N/A | N/A | All update | N/A | 1722 | | | | requests | | 1723 | | | | | | 1724 | ------------- | ---------- | ---------- | ---------- | ---------- | 1725 | | | | | | 1726 | objectNotFoun | userReques | All | All update | All delete | 1727 | d | t, | retrieve | requests | requests | 1728 | | sidebarBy | requests, | | | 1729 | | ValRequest | EXCEPT: | | | 1730 | | sidebars | blueprints | | | 1731 | | ByRefReque | Request, | | | 1732 | | st | confsRequ | | | 1733 | | | est | | | 1734 | | | | | | 1735 | ------------- | ---------- | ---------- | ---------- | ---------- | 1736 | | | | | | 1737 | userNotFound | userReques | userReques | userReques | userReques | 1738 | | t(3rd part | t | t | t | 1739 | | yinvite | | | | 1740 | | with thir | | | | 1741 | | duser | | | | 1742 | | entity) | | | | 1743 | | (*) | | | | 1744 | | | | | | 1745 | ------------- | ---------- | ---------- | ---------- | ---------- | 1746 | | | | | | 1747 | invalidConfUs | All create | All | All update | All delete | 1748 | erID | requests, | retrieve | requests | requests | 1749 | | EXCEPT: | requests | | | 1750 | | userReques | | | | 1751 | | twith no | | | | 1752 | | confUserI | | | | 1753 | | D(**) | | | | 1754 | | | | | | 1755 | ------------- | ---------- | ---------- | ---------- | ---------- | 1756 | | | | | | 1757 | forbiddenDele | N/A | N/A | N/A | All delete | 1758 | teParent | | | | request | 1759 | | | | | | 1760 | ------------- | ---------- | ---------- | ---------- | ---------- | 1761 | | | | | | 1762 | forbiddenChan | N/A | N/A | All update | N/A | 1763 | geProtected | | | requests | | 1764 +---------------+------------+------------+------------+------------+ 1766 Table 2: Response codes and associated operations 1768 (*) "userNotFound" in answer to a "userRequest/create" operation: in 1769 the case of a third-party invite, this code can be returned if the 1770 "confUserId" (contained in the "entity" attribute of the "userInfo" 1771 parameter) of the user to be added is unknown. In the case above, if 1772 instead it is the "confUserID" of the sender of the request that is 1773 invalid, an "invalidConfUserID" error code is returned to the client. 1775 (**) "invalidConfUserID" is not sent in answers to "userRequest/ 1776 create" messages having a "null" confUserId, since this case is 1777 associated with a user who is unaware of his own XCON-USERID, but 1778 wants to enter a known conference. 1780 In the case of a response code of "requestTimeout", a conferencing 1781 client MAY re-attempt the request within a period of time that would 1782 be specific to a conference control client or conference control 1783 server. 1785 A response code of "badRequest" indicates that the conference control 1786 client sent a malformed request, which is indicative of an error in 1787 the conference control client or in the conference control server. 1788 The handling is specific to the conference control client 1789 implementation (e.g., generate a log, display an error message, 1790 etc.). It is NOT RECOMMENDED that the client re-attempt the request 1791 in this case. 1793 Response codes such as "unauthorized" and "forbidden" indicate the 1794 client does not have the appropriate permissions, or there is an 1795 error in the permissions: re-attempting the request would likely not 1796 succeed and thus it is NOT RECOMMENDED. 1798 Any unexpected or unknown responseCode SHOULD be treated by the 1799 client in the same manner as a "serverInternalError" responseCode, 1800 the handling of which is specific to the conference control client 1801 implementation. 1803 7. A complete example of the CCMP in action 1805 [spromano-09] This section has to be updated, since we added the 1806 "operation" parameter in response messages. Hence, we first have to 1807 update the schema file; then, we have to change the excrpts in this 1808 section. 1810 In this section a typical scenario in which the CCMP comes into play 1811 is described, by showing the actual composition of the various CCMP 1812 messages. In the call flows of the example, the Conference Control 1813 Client is a CCMP-enabled client, whereas the Conference Control 1814 Server is a CCMP-enabled server. The "confUserId" of the client is 1815 "Alice" and appears in all requests. The sequence of operations is 1816 as follows: 1818 1. Alice retrieves from the server the list of available blueprints 1819 (Section 7.1); 1821 2. Alice asks for detailed information about a specific blueprint 1822 (Section 7.2); 1824 3. Alice decides to create a new conference by cloning the retrieved 1825 blueprint (Section 7.3); 1827 4. Alice modifies information (e.g. XCON-URI, name, description) 1828 associated with the newly created blueprint (Section 7.4); 1830 5. Alice specifies a list of users to be contacted when the 1831 conference is activated (Section 7.5); 1833 6. Alice joins the conference (Section 7.6); 1835 7. Alice lets a new user (whose "confUserId" is "Ciccio") join the 1836 conference (Section 7.7). 1838 Note, the examples do not include any details beyond the basic 1839 operation. 1841 In the following sections we deal with each of the above mentioned 1842 actions separately. 1844 7.1. Alice retrieves the available blueprints 1846 This section illustrates the transaction associated with retrieval of 1847 the blueprints, together with a dump of the two messages exchanged 1848 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 1849 the figure, the "blueprintsResponse" message contains, in the 1850 "blueprintsInfo" parameter, information about the available 1851 blueprints, in the form of the standard XCON-URI of the blueprint, 1852 plus additional (and optional) information, like its display-text and 1853 purpose. 1855 Alice retrieves from the server the list of available blueprints: 1857 CCMP Client CCMP Server 1858 | | 1859 | CCMP blueprintsRequest message | 1860 | - confUserID: Alice | 1861 | - confObjId: (null) | 1862 |------------------------------------------------------>| 1863 | | 1864 | CMP blueprintsResponse message | 1865 | - confUserID: Alice | 1866 | - confObjId: (null) | 1867 | - responseCode: success | 1868 | - blueprintsInfo: bp123,bp124,.. | 1869 |<------------------------------------------------------| 1870 | | 1871 . . 1872 . . 1874 1. blueprintsRequest message: 1876 1877 1880 1882 xcon-userid:Alice@example.com 1883 1884 1886 2. blueprintsResponse message from the server: 1888 1889 1893 1897 xcon-userid:Alice@example.com 1898 success 1899 1900 1901 1902 xcon:AudioRoom@example.com 1903 AudioRoom 1904 Simple Room: 1905 conference room with public access, 1906 where only audio is available, more users 1907 can talk at the same time 1908 and the requests for the AudioFloor 1909 are automatically accepted. 1910 1911 1912 1913 xcon:VideoRoom@example.com 1914 VideoRoom 1915 Video Room: 1916 conference room with public access, 1917 where both audio and video are available, 1918 8 users can talk and be seen at the same time, 1919 and the floor requests are automatically accepted. 1920 1921 1922 1923 xcon:AudioConference1@example.com 1924 AudioConference1 1925 Public Audio Conference: 1926 conference with public access, 1927 where only audio is available, 1928 only one user can talk at the same time, 1929 and the requests for the AudioFloor MUST 1930 be accepted by a Chair. 1931 1932 1933 1934 xcon:VideoConference1@example.com 1935 VideoConference1 1936 Public Video Conference: conference 1937 where both audio and video are available, 1938 only one user can talk 1939 1940 1941 1942 xcon:AudioConference2@example.com 1943 AudioConference2 1944 Basic Audio Conference: 1946 conference with private access, 1947 where only audio is available, 1948 only one user can talk at the same time, 1949 and the requests for the AudioFloor MUST 1950 be accepted by a Chair. 1951 1952 1953 1954 1955 1956 1958 Figure 17: Getting blueprints from the server 1960 7.2. Alice gets detailed information about a specific blueprint 1962 This section illustrates the second transaction in the overall flow. 1963 In this case, Alice, who now knows the XCON-URIs of the blueprints 1964 available at the server, makes a drill-down query, in the form of a 1965 CCMP "blueprintRequest" message, to get detailed information about 1966 one of them (the one called with XCON-URI 1967 "xcon:AudioRoom@example.com"). The picture shows such transaction. 1968 Notice that the response contains, in the "blueprintInfo" parameter, 1969 a document compliant with the standard XCON data model. 1971 Alice retrieves detailed information about a specified blueprint: 1973 CCMP Client CCMP Server 1974 | | 1975 | CCMP blueprintRequest message | 1976 | - confUserID: Alice | 1977 | - confObjId: bp123 | 1978 | - operation: retrieve | 1979 | - blueprintInfo: (null) | 1980 |------------------------------------------------------>| 1981 | | 1982 | CCMP blueprintResponse message | 1983 | - confUserID: Alice | 1984 | - confObjId: bp123 | 1985 | - operation: retrieve | 1986 | - responseCode: success | 1987 | - blueprintInfo: bp123Info | 1988 |<------------------------------------------------------| 1989 | | 1990 . . 1991 . . 1993 1. blueprintRequest message: 1995 1996 2000 2002 xcon-userid:Alice@example.com 2003 xcon:AudioRoom@example.com 2004 retrieve 2005 2006 2007 2009 2. blueprintResponse message from the server: 2011 2012 2016 2018 xcon-userid:Alice@example.com 2019 xcon:AudioRoom@example.com 2020 retrieve 2021 success 2022 2023 2024 2025 AudioRoom 2026 2 2027 2028 2029 audio 2030 2031 2032 2033 2034 allow 2035 2036 2037 confirm 2038 2039 2040 2041 2042 2043 2044 2045 2046 2048 Figure 18: Getting info about a specific blueprint 2050 7.3. Alice creates a new conference through a cloning operation 2052 This section illustrates the third transaction in the overall flow. 2053 Alice decides to create a new conference by cloning the blueprint 2054 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2055 retrieved detailed information through the "blueprintRequest" 2056 message. This is achieved by sending a "confRequest/create" message 2057 having the blueprint's URI in the "confObjId" parameter. The picture 2058 shows such transaction. Notice that the response contains, in the 2059 "confInfo" parameter, the document associated with the newly created 2060 conference, which is compliant with the standard XCON data model. 2061 The "confObjId" in the response is set to the XCON-URI of the new 2062 conference (in this case, "xcon:8977794@example.com"). We also 2063 notice that this value is equal to the value of the "entity" 2064 attribute of the element of the document 2065 representing the newly created conference object. 2067 Alice creates a new conference by cloning the 2068 "xcon:AudioRoom@example.com" blueprint: 2070 CCMP Client CCMP Server 2071 | | 2072 | CCMP confRequest message | 2073 | - confUserID: Alice | 2074 | - confObjId: AudioRoom | 2075 | - operation: create | 2076 | - confInfo: (null) | 2077 |------------------------------------------------------>| 2078 | | 2079 | CCMP confResponse message | 2080 | - confUserID: Alice | 2081 | - confObjId: newConfId | 2082 | - operation: create | 2083 | - responseCode: success | 2084 | - confInfo: newConfInfo | 2085 |<------------------------------------------------------| 2086 | | 2087 . . 2088 . . 2090 1. confRequest message: 2092 2093 2097 2100 xcon-userid:Alice@example.com 2101 xcon:AudioRoom@example.com 2102 create 2103 2104 2105 2107 2. confResponse message from the server: 2109 2110 2114 2117 xcon-userid:Alice@example.com 2118 xcon:8977794@example.com 2119 create 2120 success 2121 2122 2123 2124 2125 New conference by Alice cloned from AudioRoom 2126 2127 2128 2129 2130 xcon:8977794@example.com 2131 2132 2133 conference xcon-uri 2134 2135 2136 8601 2137 2138 2139 2140 10 2141 2142 2143 audio 2144 2145 2146 2147 2148 allow 2149 2150 2151 2152 confirm 2153 2154 2155 2156 2157 2158 2159 2160 2162 Figure 19: Creating a new conference by cloning a blueprint 2164 7.4. Alice updates conference information 2166 This section illustrates the fourth transaction in the overall flow. 2167 Alice decides to modify some of the details associated with the 2168 conference she just created. More precisely, she changes the 2169 element under the element of 2170 the document representing the conference. This is achieved through a 2171 "confRequest/update" message carrying the fragment of the conference 2172 document to which the required changes have to be applied. As shown 2173 in the picture, the response contains a code of "success", which 2174 acknowledges the modifications requested by the client. 2176 Alice updates information about the conference she just created: 2178 CCMP Client CCMP Server 2179 | | 2180 | CCMP confRequest message | 2181 | - confUserID: Alice | 2182 | - confObjId: 8977794 | 2183 | - operation: update | 2184 | - confInfo: confUpdates | 2185 |------------------------------------------------------>| 2186 | | 2187 | CCMP confResponse message | 2188 | - confUserID: Alice | 2189 | - confObjId: 8977794 | 2190 | - operation: update | 2191 | - responseCode: success | 2192 | - confInfo: (null) | 2193 |<------------------------------------------------------| 2194 | | 2195 . . 2196 . . 2198 1. confRequest message: 2200 2201 2205 2208 xcon-userid:Alice@example.com 2209 xcon:8977794@example.com 2210 update 2211 2212 2213 2214 2215 Alice's conference 2217 2218 2219 2220 2221 2222 2224 2. confResponse message from the server: 2226 2227 2231 2233 xcon-userid:Alice@example.com 2234 xcon:8977794@example.com 2235 update 2236 success 2237 2238 2239 2241 Figure 20: Updating conference information 2243 7.5. Alice inserts a list of users in the conference object 2245 This section illustrates the fifth transaction in the overall flow. 2246 Alice modifies the under the element in 2247 the document associated with the conference she created. To the 2248 purpose, she exploits the "usersRequest" message provided by the 2249 CCMP. The picture below shows the transaction. 2251 Alice updates information about the list of users to whom access to 2252 the conference is permitted: 2254 CCMP Client CCMP Server 2255 | | 2256 | CCMP usersRequest message | 2257 | - confUserID: Alice | 2258 | - confObjId: 8977794 | 2259 | - operation: update | 2260 | - usersInfo: usersUpdates | 2261 |------------------------------------------------------>| 2262 | | 2263 | CCMP usersResponse message | 2264 | - confUserID: Alice | 2265 | - confObjId: 8977794 | 2266 | - operation: update | 2267 | - responseCode: success | 2268 | - usersInfo: (null) | 2269 |<------------------------------------------------------| 2270 | | 2271 . . 2272 . . 2274 1. usersRequest message: 2276 2277 2281 2283 xcon-userid:Alice@example.com 2284 xcon:8977794@example.com 2285 update 2286 2287 2288 2289 2291 2293 2295 2296 2297 2298 2299 2301 2. usersResponse message from the server: 2303 2304 2308 2310 xcon-userid:Alice@example.com 2311 xcon:8977794@example.com 2312 update 2313 success 2314 2315 2316 2318 Figure 21: Updating the list of allowed users for the conference 2319 'xcon:8977794@example.com' 2321 7.6. Alice joins the conference 2323 This section illustrates the sixth transaction in the overall flow. 2324 Alice uses the CCMP to add herself to the newly created conference. 2325 This is achieved through a "userRequest/create" message containing, 2326 in the "userInfo" parameter, a element compliant with the XCON 2327 data model representation. Notice that such element includes 2328 information about the user's Address of Records, as well as her 2329 current end-point. The picture below shows the transaction. Notice 2330 how the "confUserId" parameter is equal to the "entity" attribute of 2331 the element, which indicates that the request issued by 2332 the client is a first-party one. 2334 Alice joins the conference by issuing a "userRequest/create" message 2335 with her own id to the server: 2337 CCMP Client CCMP Server 2338 | | 2339 | CCMP userRequest message | 2340 | - confUserID: Alice | 2341 | - confObjId: 8977794 | 2342 | - operation: create | 2343 | - userInfo: AliceUserInfo | 2344 |------------------------------------------------------>| 2345 | | 2346 | CCMP userResponse message | 2347 | - confUserID: Alice | 2348 | - confObjId: 8977794 | 2349 | - operation: create | 2350 | - responseCode: success | 2351 | - userInfo: (null) | 2352 |<------------------------------------------------------| 2353 | | 2354 . . 2355 . . 2357 1. userRequest message: 2359 2360 2364 2366 xcon-userid:Alice@example.com 2367 xcon:8977794@example.com 2368 create 2369 2370 2371 2372 2373 2374 mailto:Alice83@example.com 2375 2376 email 2377 2378 2379 2380 2381 2382 2383 2385 2. userResponse message from the server: 2387 2388 2392 2394 xcon-userid:Alice@example.com 2395 xcon:8977794@example.com 2396 create 2397 success 2398 2399 2400 2402 Figure 22: Alice joins the conference through the CCMP 2404 7.7. Alice adds a new user to the conference 2406 This section illustrates the seventh and last transaction in the 2407 overall flow. Alice uses the CCMP to add a new user to the 2408 conference. This is achieved through a "userRequest/create" message 2409 containing, in the "userInfo" parameter, a element compliant 2410 with the XCON data model representation. Notice that such element 2411 includes information about the user's Address of Records, as well as 2412 his current end-point. The picture below shows the transaction. 2413 Notice how the "confUserId" parameter in the request is Alice's id, 2414 whereas the element has no "entity" attribute and contains 2415 information about a different user, thus indicating that the request 2416 issued by the client is a third-party one. This is also reflected in 2417 the response coming from the server, which this time contains a 2418 "confUserID" parameter representing the conference user id of the 2419 user just added to the conference with Alice's third-party request. 2421 Alice adds user "Ciccio" to the conference by issuing a third-party 2422 "userRequest/create" message to the server: 2424 CCMP Client CCMP Server 2425 | | 2426 | CCMP userRequest message | 2427 | - confUserID: Alice | 2428 | - confObjId: 8977794 | 2429 | - operation: create | 2430 | - userInfo: CiccioUserInfo | 2431 |------------------------------------------------------>| 2432 | | 2433 | CCMP userResponse message | 2434 | - confUserID: ciccio | 2435 | - confObjId: 8977794 | 2436 | - operation: create | 2437 | - responseCode: success | 2438 | - userInfo: (null) | 2439 |<------------------------------------------------------| 2440 | | 2441 . . 2443 . . 2445 1. "third party" userRequest message from Alice: 2447 2448 2452 2454 xcon-userid:Alice@example.com 2455 xcon:8977794@example.com 2456 create 2457 2458 2459 2460 2461 2462 mailto:ciccio@pernacchio.com 2463 2464 email 2465 2466 2467 2468 2469 2470 2471 2473 2. "third party" userResponse message form the server: 2475 2476 2480 2482 xcon-userid:ciccio@example.com 2483 xcon:8977794@example.com 2484 create 2485 success 2486 2487 2488 2489 Figure 23: Alice adds a new user to the conference through the CCMP 2491 8. Locating a Conference Control Server 2493 If a conference control client is not pre-configured to use a 2494 specific conference control server for the requests, the client MUST 2495 first discover the conference control server before it can send any 2496 requests. The result of the discovery process, is the address of the 2497 server supporting conferencing. In this document, the result is an 2498 http: or https: URI, which identifies a conference server. 2500 This document proposes the use of DNS to locate the conferencing 2501 server. U-NAPTR resolution for conferencing takes a domain name as 2502 input and produces a URI that identifies the conferencing server. 2503 This process also requires an Application Service tag and an 2504 Application Protocol tag, which differentiate conferencing-related 2505 NAPTR records from other records for that domain. 2507 Section 13.4.1 defines an Application Service tag of "XCON", which is 2508 used to identify the centralized conferencing (XCON) server for a 2509 particular domain. The Application Protocol tag "CCMP", defined in 2510 Section 13.4.2, is used to identify an XCON server that understands 2511 the CCMP protocol. 2513 The NAPTR records in the following example Figure 24 demonstrate the 2514 use of the Application Service and Protocol tags. Iterative NAPTR 2515 resolution is used to delegate responsibility for the conferencing 2516 service from "zonea.example.com." and "zoneb.example.com." to 2517 "outsource.example.com.". 2519 zonea.example.com. 2520 ;; order pref flags 2521 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2522 "" ; regex 2523 outsource.example.com. ; replacement 2524 ) 2525 zoneb.example.com. 2526 ;; order pref flags 2527 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2528 "" ; regex 2529 outsource.example.com. ; replacement 2530 ) 2531 outsource.example.com. 2532 ;; order pref flags 2533 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 2534 "!*.!https://confs.example.com/!" ; regex 2535 . ; replacement 2536 ) 2537 Figure 24: Sample XCON:CCMP Service NAPTR Records 2539 Details for the "XCON" Application Service tag and the "CCMP" 2540 Application Protocol tag are included in Section 13.4. 2542 9. Managing Notifications 2544 In cases where the conference control client uses SIP [RFC3261] as 2545 the signaling protocol to participate in the conference, SIP event 2546 notification can be used. This would REQUIRE the conference control 2547 client to implement the Conference event package for XCON 2548 [I-D.ietf-xcon-event-package]. This is the default mechanism for 2549 conferencing clients as is SIP for signaling per the XCON Framework 2550 [RFC5239]. 2552 In the case where the interface to the conference server is entirely 2553 web based, there is a common mechanism for web-based systems that 2554 could be used - a "call back". With this mechanism, the conference 2555 client provides the conference server with an HTTP URL which is 2556 invoked when a change occurs. This is a common implementation 2557 mechanism for e-commerce. This works well in the scenarios whereby 2558 the conferencing client is a web server that provides the graphical 2559 HTML user interface and uses CCMP as the backend interface to the 2560 conference server. And, this model can co-exist with the SIP event 2561 notification model. PC-based clients behind NATs could provide a SIP 2562 event URI, whereas web servers would probably find the HTTP model 2563 much easier to program. The details of this approach are out of 2564 scope for the CCMP per se, thus the expectation is that a future 2565 specification will document this solution. 2567 10. HTTP Transport 2569 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 2570 [RFC2818] as transport mechanisms for the CCMP protocol, which a 2571 conforming conference Server and Conferencing client MUST support. 2573 Although CCMP uses HTTP as a transport, it uses a strict subset of 2574 HTTP features, and due to the restrictions of some features, a 2575 conferencing server may not a fully compliant HTTP server. It is 2576 intended that a conference server can easily be built using an HTTP 2577 server with extensibility mechanisms, and that a conferencing client 2578 can trivially use existing HTTP libraries. This subset of 2579 requirements helps implementors avoid ambiguity with the many options 2580 the full HTTP protocol offers. 2582 A conferencing client that conforms to this specification is not 2583 required to support HTTP authentication [RFC2617] or cookies 2584 [RFC2965]. These mechanism are unnecessary because CCMP requests 2585 carry their own authentication information (in the "confUserId" and 2586 "password" fields; see Section 7.2.1). 2588 A CCMP request is carried in the body of an HTTP POST request. The 2589 conferencing client MUST include a Host header in the request. 2591 The MIME type of CCMP request and response bodies is "application/ 2592 ccmp+xml". The conference server and conferencing client MUST 2593 provide this value in the HTTP Content-Type and Accept header fields. 2594 If the conference server does not receive the appropriate Content- 2595 Type and Accept header fields, the conference server SHOULD fail the 2596 request, returning a 406 (not acceptable) response. CCMP responses 2597 SHOULD include a Content-Length header. 2599 Conferencing clients MUST NOT use the "Expect" header or the "Range" 2600 header in CCMP requests. The conference server MAY return 501 (not 2601 implemented) errors if either of these HTTP features are used. In 2602 the case that the conference server receives a request from the 2603 conferencing client containing a If-* (conditional) header, the 2604 conference server SHOULD return a 412 (precondition failed) response. 2606 The POST method is the only method REQUIRED for CCMP. If a 2607 conference server chooses to support GET or HEAD, it SHOULD consider 2608 the kind of application doing the GET. Since a conferencing client 2609 only uses a POST method, the GET or HEAD MUST be either an escaped 2610 URL (e.g., somebody found a URL in protocol traces or log files and 2611 fed it into their browser) or somebody doing testing/ debugging. The 2612 conference server could provide information in the CCMP response 2613 indicating that the URL corresponds to a conference server and only 2614 responds to CCMP POST requests or the conference server could instead 2615 try to avoid any leak of information by returning a very generic HTTP 2616 error message such as 405 (method not allowed). 2618 The conference server populates the HTTP headers of responses so that 2619 they are consistent with the contents of the message. In particular, 2620 the "CacheControl" header SHOULD be set to disable caching of any 2621 conference information by HTTP intermediaries. Otherwise, there is 2622 the risk of stale information and/or the unauthorized disclosure of 2623 the information. The HTTP status code MUST indicate a 2xx series 2624 response for all CCMP Response and Error messages. 2626 The conference server MAY redirect a CCMP request. A conferencing 2627 client MUST handle redirects, by using the Location header provided 2628 by the server in a 3xx response. When redirecting, the conferencing 2629 client MUST observe the delay indicated by the Retry-After header. 2630 The conferencing client MUST authenticate the server that returns the 2631 redirect response before following the redirect. A conferencing 2632 client SHOULD authenticate the conference server indicated in a 2633 redirect. 2635 The conference server SHOULD support persistent connections and 2636 request pipelining. If pipelining is not supported, the conference 2637 server MUST NOT allow persistent connections. The conference server 2638 MUST support termination of a response by the closing of a 2639 connection. 2641 Implementations of CCMP that implement HTTP transport MUST implement 2642 transport over TLS [RFC2818]. TLS provides message integrity and 2643 confidentiality between the conference control client and the 2644 conference control server. The conferencing client MUST implement 2645 the server authentication method described in HTTPS [RFC2818]. The 2646 device uses the URI obtained during conference server discovery to 2647 authenticate the server. The details of this authentication method 2648 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 2649 the conferencing client SHOULD fail a request if server 2650 authentication fails. 2652 11. Security Considerations 2654 As identified in the XCON framework [RFC5239], there are a wide 2655 variety of potential attacks related to conferencing, due to the 2656 natural involvement of multiple endpoints and the capability to 2657 manipulate the data on the conference server using CCMP. Examples of 2658 attacks include the following: an endpoint attempting to listen to 2659 conferences in which it is not authorized to participate, an endpoint 2660 attempting to disconnect or mute other users, and theft of service by 2661 an endpoint in attempting to create conferences it is not allowed to 2662 create. 2664 The following summarizes the security considerations for CCMP: 2666 1. The client MUST determine the proper conference server. The 2667 conference server discovery is described in Section 8. 2669 2. The client MUST connect to the proper conference server. The 2670 mechanisms for addressing this security consideration are 2671 described in Section 11.1. 2673 3. The protocol MUST support a confidentiality and integrity 2674 mechanism. As described in Section 10, implementations of CCMP 2675 MUST implement the HTTP transport over TLS [RFC2818]. 2677 4. There are security issues associated with the authorization to 2678 perform actions on the conferencing system to invoke specific 2679 capabilities. A conference server SHOULD ensure that only 2680 authorized entities can manipulate the conference data. The 2681 mechanisms for addressing this security consideration are 2682 described in Section 11.2. 2684 5. The privacy and security of the identity of a user in the 2685 conference MUST be assured. The mechanisms to ensure the 2686 security and privacy of identity are discussed in Section 11.3. 2688 6. A final issue is related to Denial of Service (DoS) attacks on 2689 the conferencing server itself. In order to minimize the 2690 potential for DoS attacks, it is RECOMMENDED that conferencing 2691 systems require user authentication and authorization for any 2692 client participating in a conference. This can be accomplished 2693 through the use of the mechanisms described in Section 11.2, as 2694 well as by using the security mechanisms associated with the 2695 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 2697 11.1. Assuring that the Proper Conferencing Server has been contacted 2699 When the CCMP transaction is conducted using TLS [RFC5246], the 2700 conference server can authenticate its identity, either as a domain 2701 name or as an IP address, to the conference client by presenting a 2702 certificate containing that identifier as a subjectAltName (i.e., as 2703 an iPAddress or dNSName, respectively). With the use of HTTP as a 2704 transport for CCMP, this is exactly the authentication described by 2705 TLS [RFC2818]. If the client has external information as to the 2706 expected identity or credentials of the proper conference server 2707 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 2708 implementation of CCMP MUST be capable of being transacted over TLS 2709 so that the client can request the above authentication, and a 2710 conference server implementation MUST include this feature. Note 2711 that in order for the presented certificate to be valid at the 2712 client, the client must be able to validate the certificate. In 2713 particular, the validation path of the certificate must end in one of 2714 the client's trust anchors, even if that trust anchor is the 2715 conference server certificate itself. 2717 11.2. User Authentication and Authorization 2719 Many policy authorization decisions are based on the identity of the 2720 user or the role that a user may have. The conferencing server MUST 2721 implement mechanisms for authentication of users to validate their 2722 identity. There are several ways that a user might authenticate its 2723 identity to the system. For users joining a conference using one of 2724 the call signaling protocols, the user authentication mechanisms for 2725 the specific protocol can be used. For the case of users joining the 2726 conference using the CCMP, TLS is RECOMMENDED. 2728 The XCON Framework [RFC5239] provides an overview of other 2729 authorization mechanisms. In the cases where a user is authorized 2730 via multiple mechanisms, it is RECOMMENDED that the conference server 2731 correlate the authorization of the CCMP interface with other 2732 authorization mechanisms - e.g., PSTN users that join with a PIN and 2733 control the conference using CCMP. When a conference server presents 2734 the identity of authorized users, it MAY provide information about 2735 the way the identity was proven or verified by the system. A 2736 conference server can also allow a completely unauthenticated user 2737 into the system - this information SHOULD also be communicated to 2738 interested parties. 2740 Once a user is authenticated and authorized through the various 2741 mechanisms available on the conference server, the conference server 2742 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 2743 associate the XCON-USERID with any signaling specific user 2744 identifiers that were used for authentication and authorization. 2746 This XCON-USERID can be provided to a specific user through the 2747 conference notification interface and MUST be provided to users that 2748 interact with the conferencing system using the CCMP (i.e., in the 2749 appropriate CCMP response messages). This conference user identifier 2750 is REQUIRED for any subsequent operations on the conference object. 2752 11.3. Security and Privacy of Identity 2754 An overview of the required privacy and anonymity for users of a 2755 conferencing system are provided in the XCON Framework [RFC5239]. 2756 The security of the identity in the form of the XCON-USERID is 2757 provided in the CCMP protocol through the use of TLS. 2759 The conference server SHOULD provide mechanisms to ensure the privacy 2760 of the XCON-USERID. This is accomplished by the conference client 2761 manipulation of the "provide-anonymity" element defined in the XCON 2762 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 2763 anonymity" element controls the degree to which a user reveals their 2764 identity. The conference client MUST set the "provide-anonymity" 2765 element to "hidden" if the user does not want other participants to 2766 even be aware that there is an additional participant in the 2767 conference. The conference client MUST set the "provide-anonymity" 2768 field to "private" if the user wants to be entirely "anonymous" 2769 (i.e., other participants are aware that there is another 2770 participant, but have no information as to their identity). The 2771 conference client MUST set the "provide-anonymity" field to "semi- 2772 private" if their identity is only to be revealed to other 2773 participants or users that have a higher level authorization (e.g., a 2774 conferencing system can be configured such that an administrator can 2775 see all users). To provide the required privacy, the conference 2776 client SHOULD include the "provide-anonymity" element in the 2777 "confInfo" parameter in a CCMP confRequest message with an "update" 2778 or "create" operation or in the "userInfo" parameter in a CCMP 2779 userRequest message with an "update" or "create" operation, to ensure 2780 the user is provided the appropriate level of privacy. If the 2781 "provide-anonymity" element is not included in the conference object, 2782 then other users can see the participant's identity. 2784 12. XML Schema 2786 This section provides the XML schema definition of the "application/ 2787 ccmp+xml" format. 2789 2790 2799 2802 2805 2806 2808 2810 2811 2812 2814 2815 2817 2819 2820 2821 2823 2824 2826 2827 2829 2830 2832 2834 2837 2839 2840 2842 2843 2844 2845 2846 2847 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2860 2862 2865 2866 2867 2870 2871 2873 2874 2875 2876 2877 2878 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2891 2893 2895 2896 2897 2900 2901 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2914 2916 2917 2918 2919 2923 2924 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2937 2939 2941 2942 2943 2946 2947 2949 2951 2952 2953 2954 2955 2957 2958 2959 2960 2961 2962 2964 2966 2967 2968 2969 2970 2972 2973 2974 2975 2977 2979 2982 2983 2984 2987 2988 2990 2992 2993 2994 2995 2996 2997 2998 2999 3000 3002 3004 3007 3008 3009 3012 3013 3015 3017 3019 3020 3022 3024 3027 3029 3032 3035 3036 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3049 3051 3054 3055 3056 3058 3059 3061 3062 3063 3064 3065 3066 3067 3069 3070 3071 3073 3075 3078 3079 3080 3082 3083 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3096 3098 3100 3101 3102 3105 3106 3108 3109 3110 3111 3112 3113 3114 3115 3116 3118 3120 3122 3124 3125 3126 3127 3128 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3141 3143 3145 3146 3147 3148 3149 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3162 3164 3165 3166 3167 3168 3169 3171 3173 3174 3175 3176 3177 3178 3179 3180 3181 3183 3185 3188 3189 3190 3192 3193 3195 3197 3198 3199 3200 3201 3202 3203 3204 3205 3207 3209 3212 3213 3214 3216 3217 3219 3221 3222 3223 3224 3225 3226 3227 3228 3229 3231 3233 3236 3237 3238 3240 3241 3243 3245 3246 3247 3248 3249 3250 3251 3252 3253 3255 3257 3260 3261 3262 3264 3265 3267 3269 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3291 3293 3294 3295 3296 3297 3298 3299 3300 3301 3303 Figure 25 3305 13. IANA Considerations 3307 This document registers a new XML namespace, a new XML schema, and 3308 the MIME type for the schema. This document also registers the 3309 "XCON" Application Service tag and the "CCMP" Application Protocol 3310 tag. This document also defines registries for the CCMP operation 3311 types and response codes. 3313 13.1. URN Sub-Namespace Registration 3315 This section registers a new XML namespace, 3316 ""urn:ietf:params:xml:ns:xcon:ccmp"". 3318 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 3320 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 3321 Mary Barnes (mary.barnes@nortel.com). 3323 XML: 3325 BEGIN 3326 3327 3329 3330 3331 CCMP Messages 3332 3333 3334

Namespace for CCMP Messages

3335

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

3336 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3337 with the RFC number for this specification.]] 3338

See RFCXXXX.

3339 3340 3341 END 3343 13.2. XML Schema Registration 3345 This section registers an XML schema as per the guidelines in 3346 [RFC3688]. 3348 URI: urn:ietf:params:xml:schema:xcon:ccmp 3350 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3351 Barnes (mary.barnes@nortel.com). 3353 Schema: The XML for this schema can be found as the entirety of 3354 Section 12 of this document. 3356 13.3. MIME Media Type Registration for 'application/ccmp+xml' 3358 This section registers the "application/ccmp+xml" MIME type. 3360 To: ietf-types@iana.org 3362 Subject: Registration of MIME media type application/ccmp+xml 3364 MIME media type name: application 3366 MIME subtype name: ccmp+xml 3368 Required parameters: (none) 3370 Optional parameters: charset 3371 Indicates the character encoding of enclosed XML for which the 3372 default is UTF-8. 3374 Encoding considerations: Uses XML, which can employ 8-bit 3375 characters, depending on the character encoding used. See RFC 3376 3023 [RFC3023], section 3.2. 3378 Security considerations: This content type is designed to carry 3379 protocol data related conference control. Some of the data could 3380 be considered private and thus should be protected. 3382 Interoperability considerations: None. 3384 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 3385 replace XXXX with the RFC number for this specification.]] 3387 Applications which use this media type: Centralized Conferencing 3388 control clients and servers. 3390 Additional Information: Magic Number(s): (none) 3391 File extension(s): .xml 3392 Macintosh File Type Code(s): (none) 3394 Person & email address to contact for further information: Mary 3395 Barnes 3397 Intended usage: LIMITED USE 3399 Author/Change controller: The IETF 3401 Other information: This media type is a specialization of 3402 application/xml [RFC3023], and many of the considerations 3403 described there also apply to application/ccmp+xml. 3405 13.4. DNS Registrations 3407 Section 13.4.1 defines an Application Service tag of "XCON", which is 3408 used to identify the centralized conferencing (XCON) server for a 3409 particular domain. The Application Protocol tag "CCMP", defined in 3410 Section 13.4.2, is used to identify an XCON server that understands 3411 the CCMP protocol. 3413 13.4.1. Registration of a Conference Control Server Application Service 3414 Tag 3416 This section registers a new S-NAPTR/U-NAPTR Application Service tag 3417 for XCON, as mandated by [RFC3958]. 3419 Application Service Tag: XCON 3421 Intended usage: Identifies a server that supports centralized 3422 conferencing. 3424 Defining publication: RFCXXXX 3426 Contact information: The authors of this document 3428 Author/Change controller: The IESG 3430 13.4.2. Registration of a Conference Control Server Application 3431 Protocol Tag for CCMP 3433 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 3434 for the CCMP protocol, as mandated by [RFC3958]. 3436 Application Service Tag: CCMP 3438 Intended Usage: Identifies the Centralized Conferencing (XCON) 3439 Manipulation Protocol. 3441 Applicable Service Tag(s): XCON 3442 Terminal NAPTR Record Type(s): U 3444 Defining Publication: RFCXXXX 3446 Contact Information: The authors of this document 3448 Author/Change Controller: The IESG 3450 13.5. CCMP Protocol Registry 3452 This document requests that the IANA create a new registry for the 3453 CCMP protocol including an initial registry for operation types and 3454 response codes. 3456 13.5.1. CCMP Message Types 3458 The CCMP messages are described in Section 5.1 and defined in the XML 3459 schema in Section 12. The following summarizes the requested 3460 registry: 3462 Related Registry: CCMP Message Types Registry 3464 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3465 with the RFC number for this specification.] 3467 Registration/Assignment Procedures: New CCMP message types are 3468 allocated on a specification required basis. 3470 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3471 Barnes (mary.barnes@nortel.com). 3473 This section pre-registers the following initial CCMP message types: 3475 blueprintsRequest: Used by a conference control client to query a 3476 conferencing system for its capabilities, in terms of available 3477 conference blueprints. 3479 blueprintsResponse: The blueprintsResponse returns a list of 3480 blueprints supported by the specific conference server. 3482 confsRequest: Used by a conference control client to query a 3483 conferencing system for its scheduled/active conferences. 3485 confsResponse: The "confsResponse" returns the list of the currently 3486 activated/scheduled conferences at the server. 3488 confRequest: The "confRequest" is used to create a conference object 3489 and/or to request an operation on the conference object as a 3490 whole. 3492 confResponse: The "confResponse" indicates the result of the 3493 operation on the conference object as a whole. 3495 userRequest: The "userRequest" is used to request an operation on 3496 the "user" element in the conference object. 3498 userResponse: The "userResponse" indicates the result of the 3499 requested operation on the "user" element in the conference 3500 object. 3502 usersRequest This "usersRequest" is used to manipulate the "users" 3503 element in the conference object, including parameters such as the 3504 "allowed-users-list", "join-handling", etc. 3506 usersResponse: This "usersResponse" indicates the result of the 3507 request to manipulate the "users" element in the conference 3508 object. 3510 sidebarRequest: This "sidebarRequest" is used to retrieve the 3511 information related to a sidebar or to create, change or delete a 3512 specific sidebar. 3514 sidebarResponse: This "sidebarResponse" indicates the result of the 3515 sidebarRequest. 3517 13.5.2. CCMP Response Codes 3519 The following summarizes the requested registry for CCMP Response 3520 codes: 3522 Related Registry: CCMP Response Code Registry 3524 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3525 with the RFC number for this specification.] 3527 Registration/Assignment Procedures: New response codes are allocated 3528 on a first-come/first-serve basis with specification required. 3530 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3531 Barnes (mary.barnes@nortel.com). 3533 This section pre-registers the following thirteen initial response 3534 codes as described above in Section 5.1: 3536 success: This code indicates that the request was successfully 3537 processed. 3539 updateFailed: This code indicates that a requested "update" cannot 3540 be successfully completed by the server. An example of such 3541 situation is when the modification of an object cannot be applied 3542 due to conflicts arising at the server's side (e.g. because the 3543 client version of the object is an obsolete one and the requested 3544 modifications collide with the up-to-date state of the object 3545 stored at the server). 3547 badRequest: This code indicates that the request was badly formed in 3548 some fashion. 3550 unauthorized: This code indicates that the user was not authorized 3551 for the specific operation on the conference object. 3553 forbidden: This code indicates that the specific operation is not 3554 valid for the target conference object. 3556 objectNotFound: This code indicates that the specific conference 3557 object was not found. 3559 userNotFound: This code is returned in answer to a "userRequest/ 3560 create" operation, in the case of a third-party invite, when the 3561 "confUserId" (contained in the "entity" attribute of the 3562 "userInfo" parameter) of the user to be added is unknown. 3564 invalidConfUserID: This code is returned in the case of requests in 3565 which the "confUserID" of the sender is invalid. 3567 invalidPassword: This code is returned in response to all requests 3568 wishing to access/manipulate a password-protected conference 3569 object, when the "password" parameter contained in the request is 3570 wrong. 3572 passwordRequired: This code is returned in response to all requests 3573 wishing to access/manipulate a password-protected conference 3574 object, when the "password" parameter is missing in the request. 3576 forbiddenDeleteParent: This code indicates that the conferencing 3577 system cannot delete the specific conference object because it is 3578 a parent for another conference object. 3580 forbiddenChangeProtected: This code indicates that the target 3581 conference object cannot be changed (e.g., due to policies, roles, 3582 privileges, etc.). 3584 requestTimeout: This code indicates that the request could not be 3585 processed within a reasonable time, with the time specific to a 3586 conferencing system implementation. 3588 serverInternalError: This code indicates that the conferencing 3589 system experienced some sort of internal error. 3591 notImplemented: This code indicates that the specific operation is 3592 not implemented on that conferencing system. 3594 14. Acknowledgments 3596 The authors appreciate the feedback provided by Dave Morgan, Pierre 3597 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 3598 Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special 3599 thanks go to Roberta Presta for her invaluable contribution to this 3600 document. Roberta has worked on the specification of the CCMP 3601 protocol at the University of Napoli for the preparation of her 3602 Master thesis. She has also implemented the CCMP prototype used for 3603 the trials and from which the dumps provided in Section 7 have been 3604 extracted. 3606 15. Changes since last Version 3608 NOTE TO THE RFC-Editor: Please remove this section prior to 3609 publication as an RFC. 3611 The following summarizes the changes between the WG 03 and the 04: 3613 1. Re-organized document based on feedback from Richard Barnes. 3615 2. Editorial clarifications and nits, including those identified by 3616 Richard and Simo Veikkolainen. 3618 The following summarizes the changes between the WG 02 and the 03: 3620 1. Clarified that the confUserID is optional in the generic CCMP 3621 request message for a userRequest with a "create" operation. 3623 2. Added responseCode (error cases) handling - a general section for 3624 each of the operations (as part of CCMP Response Code section), 3625 so we don't need to re-iterate for each of the messages and 3626 message specific cases as appropriate (e.g., deleteParentFailed, 3627 modified) 3629 3. Moved "operation" parameter to be part of general CCMP request 3630 and response messages since it is used for more than one message 3631 type. And, it's necessary to define before describing the 3632 operation specific responseCode handling. 3634 4. Revised normative statements for the various protocol messages 3635 and operations - e.g., messages MUST include parameter x versus 3636 SHOULD, adding text for handling of cases where the SHOULDs don't 3637 happen and the SHOULD NOTs do. Added descriptions for all the 3638 operation types, as appropriate. 3640 5. Added lots more details in the security section. 3642 6. Added section to describe requirements for an HTTP implementation 3643 to support CCMP. 3645 7. Updated section on notifications - XCON SIP event package is 3646 default, with some discussion of an HTTP callback mechanism 3647 (ffs). 3649 8. Misc editorial nits: qualifying message names in the text, etc., 3650 etc., etc. 3652 The following summarizes the changes between the WG 01 and the 02: 3654 1. Changed the basic approach from REST to HTTP as a transport. 3655 This impacted most of the document - i.e., a major rewrite - 02 3656 is closer to 00 than the 01. 3658 2. Added full example based on prototype. 3660 The following summarizes the changes between the WG 00 and the 01: 3662 1. Changed the basic approach from using SOAP to REST - the 3663 fundamentals are the same in terms of schema, basic operations. 3664 This impacted most sections, in particular introduction and 3665 motivation. 3667 2. Added new request types - blueprintsRequest, blueprintRequest and 3668 confsRequest. The first replaces the optionsRequest and the 3669 latter allows the client to get a list of all active conferences. 3671 3. Merged all requests into the basic operations table. Added 3672 summary of RESTful examples (referenced by the basic operations 3673 table. 3675 4. Added examples showing RESTful approach - i.e., HTTP methods for 3676 message exchange. 3678 5. Removed requestID from the schema (it should be handle by the 3679 transport - e.g., HTTP). Updated schema (based on current 3680 prototype - it still needs another revision. 3682 6. Added placeholders for Notifications and Role Based Access 3683 Control. 3685 7. Added some text for discovery using DNS (including IANA 3686 registrations) 3688 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 3689 informational section. 3691 16. References 3693 16.1. Normative References 3695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3696 Requirement Levels", BCP 14, RFC 2119, March 1997. 3698 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3699 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3700 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3702 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3703 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3704 Authentication: Basic and Digest Access Authentication", 3705 RFC 2617, June 1999. 3707 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3709 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3710 Mechanism", RFC 2965, October 2000. 3712 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3713 January 2004. 3715 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3716 Centralized Conferencing", RFC 5239, June 2008. 3718 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3719 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3721 [I-D.ietf-xcon-common-data-model] 3722 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3723 "Conference Information Data Model for Centralized 3724 Conferencing (XCON)", draft-ietf-xcon-common-data-model-14 3725 (work in progress), November 2009. 3727 16.2. Informative References 3729 [REST] Fielding, "Architectural Styles and the Design of Network- 3730 based Software Architectures", 2000. 3732 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 3733 Types", RFC 3023, January 2001. 3735 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3736 A., Peterson, J., Sparks, R., Handley, M., and E. 3737 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3738 June 2002. 3740 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 3741 Service Location Using SRV RRs and the Dynamic Delegation 3742 Discovery Service (DDDS)", RFC 3958, January 2005. 3744 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 3745 RFC 3966, December 2004. 3747 [I-D.ietf-xcon-event-package] 3748 Camarillo, G., Srinivasan, S., Even, R., and J. 3749 Urpalainen, "Conference Event Package Data Format 3750 Extension for Centralized Conferencing (XCON)", 3751 draft-ietf-xcon-event-package-01 (work in progress), 3752 September 2008. 3754 [I-D.ietf-xcon-examples] 3755 Barnes, M., Boulton, C., Miniero, L., Presta, R., and S. 3756 Romano, "Centralized Conferencing Manipulation Protocol 3757 (CCMP) Call Flow Examples", draft-ietf-xcon-examples-01 3758 (work in progress), July 2009. 3760 [W3C.REC-soap12-part1-20030624] 3761 Nielsen, H., Gudgin, M., Moreau, J., Mendelsohn, N., and 3762 M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", 3763 World Wide Web Consortium FirstEdition REC-soap12-part1- 3764 20030624, June 2003, 3765 . 3767 [W3C.REC-soap12-part2-20030624] 3768 Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. 3769 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 3770 Web Consortium FirstEdition REC-soap12-part2-20030624, 3771 June 2003, 3772 . 3774 Appendix A. Appendix A: Other protocol models and transports considered 3775 for CCMP 3777 The operations on the objects can be implemented in at least two 3778 different ways, namely as remote procedure calls - using SOAP as 3779 described in Appendix A.1 and by defining resources following a 3780 RESTful architecture Appendix A.2. 3782 In both approaches, servers will have to recreate their internal 3783 state representation of the object with each update request, checking 3784 parameters and triggering function invocations. In the SOAP 3785 approach, it would be possible to describe a separate operation for 3786 each atomic element, but that would greatly increase the complexity 3787 of the protocol. A coarser-grained approach to the CCMP does require 3788 that the server process XML elements in updates that have not changed 3789 and that there can be multiple changes in one update. 3791 For CCMP, the resource (REST) model might appear more attractive, 3792 since the conference operations fit the CRUD approach. 3794 Neither of these approaches were considered ideal as SOAP was not 3795 considered to be general purpose enough for use in a broad range of 3796 operational environments. It is quite awkward to apply a RESTful 3797 approach since the CCMP requires a more complex request/response 3798 protocol in order to maintain the data both in the server and at the 3799 client. This doesn't map very elegantly to the basic request/ 3800 response model, whereby a response typically indicates whether the 3801 request was successful or not, rather than providing additional data 3802 to maintain the synchronization between the client and server data. 3803 In addition, the CCMP clients may also receive the data in 3804 Notifications. While the notification method or protocol used by 3805 some conferencing clients can be independent of the CCMP, the same 3806 data in the server is used for both the CCMP and Notifications - this 3807 requires a server application above the transport layer (e.g., HTTP) 3808 for maintaining the data, which in the CCMP model is transparent to 3809 the transport protocol. 3811 A.1. Using SOAP for the CCMP 3813 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 3814 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 3815 -soap12-part2-20030624]), where conferences and the other objects are 3816 modeled as services with associated operations. Conferences and 3817 other objects are selected by their own local identifiers, such as 3818 email-like names for users. This approach has the advantage that it 3819 can easily define atomic operations that have well-defined error 3820 conditions. 3822 All SOAP operations would use a single HTTP verb. While the RESTful 3823 approach requires the use of a URI for each object, SOAP can use any 3824 token. 3826 A.2. A RESTful approach for the CCMP 3828 Conference objects can also be modeled as resources identified by 3829 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 3830 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 3831 changing objects and DELETE for deleting them. Many of the objects, 3832 such as conferences, already have natural URIs. 3834 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 3835 design pattern. The basic CRUD operations are used to manipulate 3836 conference objects, which are XML documents containing the 3837 information characterizing a specified conference instance, be it an 3838 active conference or a conference blueprint used by the conference 3839 server to create new conference instances through a simple clone 3840 operation. 3842 Following the CRUD approach, CCMP could use a general-purpose 3843 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 3844 encoded data objects defined in the Conference Information Data Model 3845 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 3847 Following on the CRUD approach, CCMP could follow the well-known REST 3848 (REpresentational State Transfer) architectural style [REST]. The 3849 CCMP could map onto the REST philosophy, by specifying resource URIs, 3850 resource formats, methods supported at each URI and status codes that 3851 have to be returned when a certain method is invoked on a specific 3852 URI. A REST-style approach must ensure sure that all operations can 3853 be mapped to HTTP operations. 3855 The following summarizes the specific HTTP method that could be used 3856 for each of the CCMP Requests: 3858 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 3859 obtain data about conference objects in the form of XML data model 3860 documents. 3862 Create: HTTP PUT could be used to create a new object as identified 3863 by the XCON-URI or XCON-USERID. 3865 Change: Either HTTP PATCH or HTTP POST could be used to change the 3866 conference object identified by the XCON-URI. 3868 Delete: HTTP DELETE could be used to delete conference objects and 3869 parameters within conference objects identified by the XCON-URI. 3871 Authors' Addresses 3873 Mary Barnes 3874 Nortel 3876 Email: mary.barnes@nortel.com 3878 Chris Boulton 3879 NS-Technologies 3881 Email: chris@ns-technologies.com 3883 Simon Pietro Romano 3884 University of Napoli 3885 Via Claudio 21 3886 Napoli 80125 3887 Italy 3889 Email: spromano@unina.it 3891 Henning Schulzrinne 3892 Columbia University 3893 Department of Computer Science 3894 450 Computer Science Building 3895 New York, NY 10027 3897 Email: hgs+xcon@cs.columbia.edu