idnits 2.17.1 draft-ietf-xcon-ccmp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 13, 2009) is 5394 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) ** 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-13 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 6 errors (**), 0 flaws (~~), 3 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: January 14, 2010 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 July 13, 2009 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-03 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The Centralized Conferencing Manipulation Protocol (CCMP) can create, 52 retrieve, change and delete objects describing a centralized 53 conference, such as state and capabilities of the conference, 54 participants, and their roles. The conference information is 55 contained in XML documents and fragments conforming to the 56 centralized conferencing data model schema. CCMP is a state-less 57 client-server protocol based on a request/response model. 58 Conferencing clients send requests to conference servers, which 59 respond to the client with the conference information. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 67 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 9 68 6. Conference Object and User Identifiers . . . . . . . . . . . . 11 69 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 11 70 6.2. Conference Users and Participants . . . . . . . . . . . . 11 71 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Implementation Approach . . . . . . . . . . . . . . . . . 14 73 7.2. CCMP protocol messages . . . . . . . . . . . . . . . . . . 14 74 7.2.1. CCMP Request Message . . . . . . . . . . . . . . . . . 14 75 7.2.2. CCMP Response Message . . . . . . . . . . . . . . . . 16 76 7.2.2.1. CCMP Response Codes . . . . . . . . . . . . . . . 18 77 7.2.3. Detailed CCMP Messages . . . . . . . . . . . . . . . . 21 78 7.2.3.1. blueprintsRequest and blueprintsResponse 79 messages . . . . . . . . . . . . . . . . . . . . . 23 80 7.2.3.2. confsRequest and confsResponse messages . . . . . 25 81 7.2.3.3. blueprintRequest and blueprintResponse messages . 26 82 7.2.3.4. confRequest and confResponse messages . . . . . . 28 83 7.2.3.5. usersRequest and usersResponse messages . . . . . 31 84 7.2.3.6. userRequest and userResponse messages . . . . . . 34 85 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse 86 messages . . . . . . . . . . . . . . . . . . . . . 39 87 7.2.3.8. sidebarByValRequest and sidebarByValResponse 88 messages . . . . . . . . . . . . . . . . . . . . . 41 89 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse 90 messages . . . . . . . . . . . . . . . . . . . . . 44 91 7.2.3.10. sidebarByRefRequest and sidebarByRefResponse 92 messages . . . . . . . . . . . . . . . . . . . . . 46 93 8. A complete example of the CCMP in action . . . . . . . . . . . 50 94 8.1. Alice retrieves the available blueprints . . . . . . . . . 50 95 8.2. Alice gets detailed information about a specific 96 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 53 97 8.3. Alice creates a new conference through a cloning 98 operation . . . . . . . . . . . . . . . . . . . . . . . . 55 99 8.4. Alice updates conference information . . . . . . . . . . . 57 100 8.5. Alice inserts a list of users in the conference object . . 59 101 8.6. Alice joins the conference . . . . . . . . . . . . . . . . 61 102 8.7. Alice adds a new user to the conference . . . . . . . . . 63 103 9. Locating a Conference Control Server . . . . . . . . . . . . . 66 104 10. Managing Notifications . . . . . . . . . . . . . . . . . . . . 68 105 11. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 69 106 12. Security Considerations . . . . . . . . . . . . . . . . . . . 71 107 12.1. Assuring that the Proper Conferencing Server has been 108 contacted . . . . . . . . . . . . . . . . . . . . . . . . 72 109 12.2. User Authentication and Authorization . . . . . . . . . . 72 110 12.3. Security and Privacy of Identity . . . . . . . . . . . . . 73 111 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 74 112 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 113 14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 85 114 14.2. XML Schema Registration . . . . . . . . . . . . . . . . . 85 115 14.3. MIME Media Type Registration for 'application/ccmp+xml' . 86 116 14.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 87 117 14.4.1. Registration of a Location Server Application 118 Service Tag . . . . . . . . . . . . . . . . . . . . . 87 119 14.4.2. Registration of a Location Server Application 120 Protocol Tag for HELD . . . . . . . . . . . . . . . . 87 121 14.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 88 122 14.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 88 123 14.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 89 124 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 125 16. Changes since last Version . . . . . . . . . . . . . . . . . . 93 126 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 127 17.1. Normative References . . . . . . . . . . . . . . . . . . . 95 128 17.2. Informative References . . . . . . . . . . . . . . . . . . 95 129 Appendix A. Appendix A: Other protocol models and transports 130 considered for CCMP . . . . . . . . . . . . . . . . . 97 131 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 97 132 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 98 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 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. However, 159 the CCMP is a request/response protocol with new or updated data 160 relevant to the specific conference object returned in the response. 161 Whereas, a REST approach involves singular/monolithic operations on 162 data, with the response typically indicating either success or 163 failure, rather than providing updated data based on a specific 164 operation, thus, it was not considered a good choice. Details of the 165 use of REST for the CCMP, as well as other protocols considered 166 (e.g., SOAP) are provided in Appendix A. 168 Section 4 provides an overview of the design of the CCMP, followed by 169 the system architecture in Section 5. Section 6 discusses the 170 primary keys in the conference object carried in the protocol. An 171 overview of the operations associated with each protocol request and 172 response is provided in Section 7. A complete example of the 173 operation of the CCMP, describing a typical call flow associated with 174 conference creation and manipulation, is provided in Section 8. 175 Section 13 provides the XML schema. 177 2. Conventions 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 3. Terminology 185 In additon to the terms defined in the Framework for Centralized 186 Conferencing [RFC5239], this document uses the following terms and 187 acronyms: 189 CRUD: CRUD stands for Create/Read/Update/Delete and indicates a 190 design pattern supporting creating, retrieving, updating and 191 destroying objects. 193 REST: REpresentational State Transfer (REST) is an architectural 194 style, i.e., a coordinated set of architectural constraints. REST 195 is based on the consideration that a software architecture can 196 often be specified as an appropriate configuration of components, 197 data and connectors, all coordinated through constraining their 198 mutual relationships. Coordination and constraints help achieve a 199 desired set of architectural properties. [REST] 201 SOAP: Simple Object Access Protocol defined in 202 [W3C.REC-soap12-part1-20030624] and 203 [W3C.REC-soap12-part2-20030624]. 205 4. Protocol Overview 207 This document specifies the basic operations that can create, 208 retrieve, modify and delete conference-related information in a 209 centralized conference. The core set of objects manipulated in the 210 CCMP protocol described in this document includes conference 211 blueprints, the conference object, users, and sidebars. 213 Each operation in the protocol model is atomic and either succeeds or 214 fails as a whole. The conference server MUST ensure that the 215 operations are atomic in that the operation invoked by a specific 216 conference client completes prior to another client's operation on 217 the same conference object. The details for this data locking 218 functionality are out of scope for the CCMP protocol specification 219 and are implementation specific for a conference server. Thus, the 220 conference server first checks all the parameters, before making any 221 changes to the internal representation of the conference object. For 222 example, it would be undesirable to change the of the 223 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 225 can modify the same conference objects, conference clients SHOULD 226 first obtain the current object from the conference server and then 227 update the relevant data elements in the conference object prior to 228 invoking a specific operation on the conference server. In some 229 cases, the data changes are not fully applied, since a previous 230 operation by another conference client may have altered some of the 231 data. Where appropriate (i.e., depending upon the specific data and 232 policies), the conference server SHOULD indicate that the data has 233 been modified and return the current conference object to the client. 234 For example, one conferencing client may add a new user to the 235 conference object. Thus, a subsequent request by another 236 conferencing client should provide a conference object containing 237 this new user. 239 It is likely that implementations and future standardization work 240 will add more conference attributes and parameters. There are three 241 types of extensions. The first and simplest type of extension adds 242 elements to the overall conference description, media descriptions or 243 descriptions of users. The XML namespace mechanism makes such 244 extensions relatively easy, although implementations still have to 245 deal with companion implementations that may not understand the new 246 namespaces. The CCMP "blueprintsRequest" message allows clients to 247 determine the capabilities of a specific server, reflected by the 248 specific blueprints supported by that server. 250 A second type of extension replaces the conference, user or media 251 objects with completely new schema definitions, i.e., the namespaces 252 for these objects themselves differ from the basic one defined in 253 this document. As long as the blueprintsRequest message remains 254 available and keeps to a mutually-understood definition, a compatible 255 client and server will be able to bootstrap themselves into using 256 these new objects. 258 Finally, it is conceivable that new object types are needed beyond 259 the core conference, user and media objects and their children. 260 These would also be introduced by namespaces and new URIs. 262 5. System Architecture 264 CCMP supports the XCON framework . Figure 1 depicts a subset of the 265 'Conferencing System Logical Decomposition' architecture from the 266 XCON framework document. It illustrates the role that CCMP assumes 267 within the overall centralized architecture. 269 ........................................................ 270 . Conferencing System . 271 . . 272 . +---------------------------------------+ . 273 . | C O N F E R E N C E O B J E C T | . 274 . +-+-------------------------------------+ | . 275 . | C O N F E R E N C E O B J E C T | | . 276 . +-+-------------------------------------+ | | . 277 . | C O N F E R E N C E O B J E C T | | | . 278 . | | | | . 279 . | | |-+ . 280 . | |-+ . 281 . +---------------------------------------+ . 282 . ^ . 283 . | . 284 . v . 285 . +-------------------+ . 286 . | Conference Control| . 287 . | Server | . 288 . +-------------------+ . 289 . ^ . 290 .........................|.............................. 291 | 292 |Conference 293 |Control 294 |Manipulation 295 |Protocol 296 | 297 .........................|.............................. 298 . V . 299 . +----------------+ . 300 . | Conference | . 301 . | Control | . 302 . | Client | . 303 . +----------------+ . 304 . . 305 . Conferencing Client . 306 ........................................................ 308 Figure 1: Conference Client Interaction 310 CCMP serves as the Conference Control Protocol, allowing the 311 conference control client to interface with the conference object 312 maintained by the conferencing system, as represented in Figure 1. 313 Conference Control is one part of functionality for advanced 314 conferencing supported by a conferencing client. Other functions are 315 discussed in the XCON framework and related documents. 317 6. Conference Object and User Identifiers 319 This section provides an overview of the conference object and 320 conference users which are key protocol elements for creating the 321 CCMP requests and responses. The identifiers used in CCMP for the 322 conference object (XCON-URI) and conference user (XCON-USERID) are 323 introduced in the XCON framework and defined in the XCON data model 324 [I-D.ietf-xcon-common-data-model]. 326 6.1. Conference Object 328 Conference objects feature a simple dynamic inheritance-and-override 329 mechanism. Conference objects are linked into a tree, where each 330 tree node inherits attributes from its parent node. The roots of 331 these inheritance trees are also known as "blueprints". Nodes in the 332 inheritance tree can be active conferences or simply descriptions 333 that do not currently have any resources associated with them. An 334 object can mark certain of its properties as unalterable, so that 335 they cannot be overridden. 337 The schema for the conference object is defined in the XCON data 338 model. Conference objects are uniquely identified by the XCON-URI. 339 A client MAY specify a parent element that indicates the parent from 340 which the conference is to inherit values. When creating 341 conferences, the XCON-URI included by the client is only a 342 suggestion. To avoid identifier collisions and to conform to local 343 server policy, the conference control server MAY choose a different 344 identifier. 346 6.2. Conference Users and Participants 348 Each conference can have zero or more users. All conference 349 participants are users, but some users may have only administrative 350 functions and do not contribute or receive media. Users are added 351 one user at a time to simplify error reporting. Users are inherited 352 as well, so that it is easy to set up a conference that has the same 353 set of participants or a common administrator. The Conference 354 Control Server creates individual users, assigning them a unique 355 Conference User Identifier (XCON-USERID). 357 A variety of elements defined in the common element 358 as specified in the XCON data model are used to determine how a 359 specific user expects and is allowed to join a conference as a 360 participant or as a user with specific privileges (e.g., observer). 361 For example, the attribute defines how the caller joins the 362 conference, with a set of defined XML elements, namely for 363 users that are allowed to dial in and for users that the 364 conference focus will be trying to reach. is the default. 366 If the conference is currently active, dial-out users are contacted 367 immediately; otherwise, they are contacted at the start of the 368 conference. The conference control server assigns a unique 369 Conference User Identifier (XCON-USERID) to each user. The 370 conference control server uses the XCON-USERID to change or delete 371 elements. Depending upon policies and privileges, specific 372 users MAY also manipulate elements. 374 In many conferences, users can dial in if they know the XCON-URI and 375 an access code shared by all conference participants. In this case, 376 the system is typically not aware of the call signaling URL. Thus, 377 the initial element does not have an entity attribute and the 378 default type of is used to support this type of user. For 379 this case, the server assigns a locally-unique URI, such as a 380 locally-scoped tel URI [RFC3966]. The conference control server 381 assigns a unique Conference User Identifier (XCON-USERID) to these 382 users when they dial-in to join the conference. If the user supports 383 the notification event package [I-D.ietf-xcon-event-package], they 384 can receive their XCON-USERID, thus allowing them to also manipulate 385 the attribute, including the entity attribute, in the 386 conference object. 388 7. Protocol Operations 390 CCMP is a client-server, XML-based, stateless protocol, which has 391 been specifically conceived to provide users with the necessary means 392 for the creation, retrieval, modification and deletion of conference 393 objects. Conference-related information is encapsulated into CCMP 394 messages in the form of documents or document fragments compliant 395 with the XCON data model representation. 397 The main operations provided by CCMP belong in four general 398 categories: 400 create: for the creation of a conference, a conference user, a 401 sidebar, or a blueprint. 403 retrieve: to get information about the current state of either a 404 conference object (be it an actual conference or a blueprint, or a 405 sidebar) or a conference user. A retrieve operation can also be 406 used to obtain the XCON-URIs of the active conferences and/or 407 blueprints available at the server. 409 update: to modify the current features of a specified conference or 410 conference user. 412 delete: to remove from the system a conference object or a 413 conference user. 415 Thus, the main targets of CCMP operations are: 417 o conference objects associated with either active or registered 418 conferences, 420 o conference objects associated with blueprints, 422 o conference objects associated with sidebars, both embedded in the 423 main conference (i.e. elements) and external 424 to it (i.e. elements), 426 o elements associated with conference users, 428 o the list of XCON-URIs related to conferences and blueprints 429 available at the server, for which only retrieval operations are 430 allowed. 432 7.1. Implementation Approach 434 There have been a number of different proposals as to the most 435 suitable implementation solution for the CCMP. A non-exhaustive 436 summary of the most interesting ones is provided in Appendix A. The 437 solution for the CCMP defined in this document is viewed as a good 438 compromise amongst the most notable past candidates and is referred 439 to as 'HTTP transport plus CCMP body'. With this approach, CCMP is 440 able to take advantage of existing HTTP functionality. As with SOAP, 441 the CCMP uses a 'single HTTP verb' for transport (i.e. a single 442 transaction type for each request/response pair); this allows 443 decoupling CCMP messages from HTTP messages. Similarly, as with any 444 RESTful approach, CCMP messages are inserted directly in the body of 445 HTTP messages, thus avoiding any unnecessary processing and 446 communication burden associated with further intermediaries. With 447 this approach, no modification to the CCMP messages/operations is 448 required to use a different transport protocol. 450 The remainder of this document focuses on the selected approach. The 451 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 452 POST operations and retrieves responses from the body of HTTP '200 453 OK' messages. CCMP messages have a MIME-type of "application/ 454 ccmp+xml", which appears inside the "Content-Type" and "Accept" 455 fields of HTTP requests and responses. Section 11 provides the 456 complete requirements for an HTTP implementation to support the CCMP. 458 7.2. CCMP protocol messages 460 CCMP messages are either requests or responses. The general CCMP 461 request message is defined in Section 7.2.1. The general CCMP 462 response message is defined in Section 7.2.2. The details of the 463 specific message type which is carried in the CCMP request and 464 response messages are described in Section 7.2.3. 466 7.2.1. CCMP Request Message 468 A CCMP request message is comprised of the following parameters: 470 confUserId: An optional parameter containing the XCON-USERID of the 471 client. The "confUserID" parameter is used to determine if the 472 conference control client has the authority to perform the 473 operation, as well as other Authorization, Authentication and 474 Accounting (AAA) procedures. The attribute is required in the 475 CCMP request and response messages with the exception of the case 476 of a user who has no XCON-USERID and who wants to enter, via CCMP, 477 a conference whose identifier is known. In such case, a side- 478 effect of the request is that the user is provided with an 479 appropriate XCON-USERID. An example of the above mentioned case 480 will be provided in Section 7.2.3.6. 482 confObjId: An optional parameter containing the XCON-URI of the 483 target conference object. 485 operation: An optional parameter refining the type of specialized 486 request message. The "operation" parameter is REQUIRED in all 487 requests except for the "blueprintsRequest" and "confsRequest" 488 specialized messages. 490 password: An optional parameter that MUST be inserted in all 491 requests whose target conference object is password-protected (as 492 per the element in 493 [I-D.ietf-xcon-common-data-model]). 495 specialized request message: This is specialization of the generic 496 request message (e.g., blueprintsRequest), containing parameters 497 that are dependent on the specific request sent to the server. A 498 specialized response message MUST be included in the CCMP request 499 message. The details for the specialized messages and associated 500 parameters are provided in Section 7.2.3. 502 504 506 507 508 510 511 513 515 517 518 520 522 524 526 527 529 Figure 2: Structure of CCMP Request messages 531 7.2.2. CCMP Response Message 533 A CCMP response message is comprised of the following parameters: 535 confUserId: A mandatory parameter in CCMP response messages 536 containing the XCON-USERID of the conferencing client who issued 537 the CCMP request message. 539 confObjId: An optional parameter containing the XCON-URI of the 540 target conference object. 542 operation: An optional parameter for CCMP response messages. This 543 parameter is REQUIRED in all responses except for the 544 "blueprintsResponse" and "confsResponse" specialized messages. 546 responseCode: A mandatory parameter containing the response code 547 associated with the request. The response code MUST be chosen 548 from the codes listed in Section 7.2.2.1. 550 specialized response message: This is specialization of the generic 551 response message, containing parameters that are dependent on the 552 specific request sent to the server (e.g., blueprintsResponse). A 553 specialized request message SHOULD be included in the CCMP 554 response message, except in an error situation where the CCMP 555 request message did not contain a valid specialized message. In 556 this case, the conference server MUST return a responseCode of 557 "badRequest". The details for the specialized messages and 558 associated parameters are provided in Section 7.2.3. 560 562 564 565 566 568 569 571 573 575 576 578 580 582 584 585 587 Figure 3: Structure of CCMP Response message 589 7.2.2.1. CCMP Response Codes 591 All CCMP response messages MUST include a "responseCode". The 592 following summarizes the CCMP response codes: 594 success: Successful completion of the requested operation. 596 modified: Successful completion of the requested operation, with 597 partial data returned in the confObjID having been modified from 598 the data included in the confObjID included request, either for a 599 "create" or a "change" operation 601 badRequest: Syntactically malformed request 603 objectNotFound: Target conference object missing at the server (it 604 refers to the 'confObjId' parameter in the generic request 605 message) 607 userNotFound: Target user missing at the server (it is related to 608 the XCON-USERID in the 'entity' attribute of the 'userInfo' 609 parameter when it is included in userRequests) 611 invalidConfUserID: User missing at the server (this code is returned 612 in the case of requests in which the 'confUserID' of the sender is 613 invalid). 615 invalidPassword: Target conference object's password contained in 616 the request is wrong. 618 passwordRequired: Conference password missing in a request to access 619 a password-protected conference object. 621 unauthorized: User not allowed to perform the required operation 623 forbidden: Operation not allowed (e.g., cancellation of a blueprint) 625 forbiddenDeleteParent: Cancel operation failed since the target 626 object is a parent of child objects which depend on it, or because 627 it effects, based on the 'parent-enforceable' mechanism, the 628 corresponding element in a child object 630 forbiddenChangeProtected: Update refused by the server because the 631 target element cannot be modified due to its implicit dependence 632 on the value of a parent object ('parent-enforceable' mechanism) 634 requestTimeout: The time required to serve the request has exceeded 635 the envisaged service threshold 637 serverInternalError: The server cannot complete the required service 638 due to a system internal error 640 notImplemented: Operation envisaged in the protocol, but not 641 implemented in the contacted server. 643 The handling of a responseCode of 'modified', 'objectNotFound', 644 'userNotFound', 'deleteParentFailed' and 'changeFailedProtected' are 645 only applicable to specific operations for specialized message 646 responses and the details are provided in Section 7.2.3. The 647 following table summarizes these responseCodes and the specialized 648 message and operation to which they are applicable: 650 +---------------+------------+------------+------------+------------+ 651 | Response code | Create | Retrieve | Update | Delete | 652 +---------------+------------+------------+------------+------------+ 653 | Modified | All create | N/A | All update | N/A | 654 | | requests | | requests | | 655 | | | | | | 656 | ------------- | ---------- | ---------- | ---------- | ---------- | 657 | | | | | | 658 | objectNotFoun | userReques | All | All update | All delete | 659 | d | t, | retrieve | requests | requests | 660 | | sidebarBy | requests, | | | 661 | | ValRequest | EXCEPT: | | | 662 | | sidebars | blueprints | | | 663 | | ByRefReque | Request, | | | 664 | | st | confsRequ | | | 665 | | | est | | | 666 | | | | | | 667 | ------------- | ---------- | ---------- | ---------- | ---------- | 668 | | | | | | 669 | userNotFound | userReques | userReques | userReques | userReques | 670 | | t(3rd part | t | t | t | 671 | | yinvite | | | | 672 | | with thir | | | | 673 | | duser | | | | 674 | | entity) | | | | 675 | | (*) | | | | 676 | | | | | | 677 | ------------- | ---------- | ---------- | ---------- | ---------- | 678 | | | | | | 679 | invalidConfUs | All create | All | All update | All delete | 680 | erID | requests, | retrieve | requests | requests | 681 | | EXCEPT: | requests | | | 682 | | userReques | | | | 683 | | twith no | | | | 684 | | confUserI | | | | 685 | | D(**) | | | | 686 | | | | | | 687 | ------------- | ---------- | ---------- | ---------- | ---------- | 688 | | | | | | 689 | forbiddenDele | N/A | N/A | N/A | All delete | 690 | teParent | | | | request | 691 | | | | | | 692 | ------------- | ---------- | ---------- | ---------- | ---------- | 693 | | | | | | 694 | forbiddenChan | N/A | N/A | All update | N/A | 695 | geProtected | | | requests | | 696 +---------------+------------+------------+------------+------------+ 698 Table 1: Response codes and associated operations 700 (*) 'userNotFound' in answer to a 'userRequest/create' operation: in 701 the case of a third-party invite, this code can be returned if the 702 'confUserId' (contained in the 'entity' attribute of the 'userInfo' 703 parameter) of the user to be added is unknown. In the case above, if 704 instead it is the 'confUserID' of the sender of the request that is 705 invalid, an 'invalidConfUserID' error code is returned to the client. 707 (**) 'invalidConfUserID' is not sent in answers to 'userRequest/ 708 create' messages having a 'null' confUserId, since this case is 709 associated with a user who is unaware of his own XCON-USERID, but 710 wants to enter a known conference. 712 In the case of a response code of 'requestTimeout', a conferencing 713 client MAY re-attempt the request within a period of time that would 714 be specific to a conference control client or conference control 715 server. 717 A response code of 'badRequest' indicates that the conference control 718 client sent a malformed request, which is indicative of an error in 719 the conference control client or in the conference control server. 720 The handling is specific to the conference control client 721 implementation (e.g., generate a log, display an error message, 722 etc.). It is NOT RECOMMENDED that the client re-attempt the request 723 in this case. 725 Response codes such as 'unauthorized', "forbidden' and 726 'operationNotAllowed' indicate the client does not have the 727 appropriate permissions, there is an error in the permissions, or 728 there is a system error in the client or conference control server, 729 thus re-attempting the request would likely not succeed and thus is 730 NOT RECOMMENDED. 732 Any unexpected or unknown responseCode SHOULD be treated by the 733 client in the same manner as a 'serverInternalError' responseCode, 734 the handling of which is specific to the conference control client 735 implementation. 737 7.2.3. Detailed CCMP Messages 739 Based on the request and response message structures described in 740 Section 7.2.1 and Section 7.2.2, the following summarizes the 741 specialized CCMP request/response types described in this document: 743 1. blueprintsRequest/blueprintsResponse 745 2. confsRequest/confsResponse 747 3. blueprintRequest/blueprintResponse 749 4. confRequest/confResponse 751 5. usersRequest/usersResponse 753 6. userRequest/userResponse 755 7. sidebarsByValRequest/sidebarsByValResponse 757 8. sidebarsByRefRequest/sidebarsByRefResponse 759 9. sidebarByValRequest/sidebarByValResponse 761 10. sidebarByRefRequest/sidebarByRefResponse 763 These CCMP request/response pairs use the fundamental CCMP operations 764 as defined in Section 7 to manipulate the conference data. Table 2 765 summarizes the CCMP operations and corresponding actions that are 766 valid for a specific CCMP request type, noting that neither the 767 blueprintsRequest/blueprintsResponse or confsRequest/ConfsResponse 768 require an "operation" parameter. The corresponding response MUST 769 contain the same operation. Note that some entries are labeled "N/A" 770 indicating the operation is invalid for that request type. In the 771 case of an "N/A*", the operation MAY be allowed for specific 772 privileged users or system administrators, but is not part of the 773 functionality included in this document. 775 +---------------+------------+------------+------------+------------+ 776 | Operation | Retrieve | Create | Update | Delete | 777 | ------------- | | | | | 778 | -Request Type | | | | | 779 +---------------+------------+------------+------------+------------+ 780 | blueprintsReq | Get list | N/A | N/A | N/A | 781 | uest | of | | | | 782 | | blueprints | | | | 783 | | | | | | 784 | ------------- | ---------- | ---------- | ---------- | ---------- | 785 | | | | | | 786 | blueprintRequ | Get | N/A* | N/A* | N/A* | 787 | est | blueprint | | | | 788 | | | | | | 789 | ------------- | ---------- | ---------- | ---------- | ---------- | 790 | | | | | | 791 | confsRequest | Get list | N/A | N/A | N/A | 792 | | of confs | | | | 793 | | (active, | | | | 794 | | etc.) | | | | 795 | | | | | | 796 | ------------- | ---------- | ---------- | ---------- | ---------- | 797 | | | | | | 798 | confRequest | Gets | Creates | Changes | Deletes | 799 | | conference | conference | conference | conference | 800 | | object or | object | object | Object as | 801 | | blueprint | | | a whole | 802 | | | | | | 803 | ------------- | ---------- | ---------- | ---------- | ---------- | 804 | | | | | | 805 | usersRequest | Gets | N/A | Changes | N/A | 806 | | specific | | specified | | 807 | | users | | users | | 808 | | element | | element | | 809 | | | | | | 810 | ------------- | ---------- | ---------- | ---------- | ---------- | 811 | | | | | | 812 | userRequest | Gets | Adds a | Changes | Deletes | 813 | | specific | user to a | specified | user | 814 | | user | conference | user | element as | 815 | | element. | . * | element. | a whole. | 816 | | | | | | 817 | ------------- | ---------- | ---------- | ---------- | ---------- | 818 | | | | | | 819 | sidebarsByVal | Gets | N/A | N/A | N/A | 820 | Request | sidebars-b | | | | 821 | | y -val | | | | 822 | | element | | | | 823 | ------------- | ---------- | ---------- | ---------- | ---------- | 824 | | | | | | 825 | sidebarsByRef | Gets | N/A | N/A | N/A | 826 | Request | sidebars-b | | | | 827 | | y -ref | | | | 828 | | element | | | | 829 | | | | | | 830 | ------------- | ---------- | ---------- | ---------- | ---------- | 831 | | | | | | 832 | sidebarByValR | Gets a | Creates a | Adds or | Removes/ | 833 | equest | sidebar | sidebar by | modifies a | deletes | 834 | | element | cloning | sidebar | entire | 835 | | | existing | | sidebar | 836 | | | conf | | | 837 | | | object | | | 838 | | | | | | 839 | ------------- | ---------- | ---------- | ---------- | ---------- | 840 | | | | | | 841 | sidebarByRefR | Gets a | Creates | Adds or | Removes/ | 842 | equest | sidebar | sidebar by | modifies | deletes | 843 | | element | cloning | sidebar | entire | 844 | | | existing | | sidebar | 845 | | | conf | | | 846 | | | object | | | 847 +---------------+------------+------------+------------+------------+ 849 Table 2: Request Type Operation Specific Processing 851 *: This operation can involve the creation of an XCON-UserID, if the 852 sender does not add it in the 'confUserId' parameter, or if the 853 'entity' field of the userInfo parameter is void. 855 Additional parameters included in the specialized CCMP request/ 856 response messages are detailed in the subsequent sections. 858 7.2.3.1. blueprintsRequest and blueprintsResponse messages 860 A 'blueprintsRequest' (Figure 4) message is sent to request the list 861 of XCON-URIs associated with the available blueprints from the 862 conference server. Such URIs can be subsequently used by the client 863 to access detailed information about a specified blueprint with a 864 specific 'blueprintRequest' message per Section 7.2.3.3. A 865 'blueprintsRequest' message REQUIRES no additional parameters beyond 866 those specified for the basic CCMP request message. The 'confObjId' 867 and 'operation' parameters MUST NOT be included in the request or 868 response for this transaction. 870 The associated 'blueprintsResponse' message SHOULD contain, as shown 871 in Figure 4, a 'blueprintsInfo' parameter containing the above 872 mentioned XCON-URI list. If the 'blueprintsInfo' parameter is empty, 873 the conference control client MAY attempt to use a local default 874 blueprint to create conferences. However, the handling in this 875 situation is specific to the conference control client 876 implementation. 878 879 880 881 882 883 885 886 887 888 889 890 891 892 893 894 896 898 901 902 903 905 906 908 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 909 messages 911 7.2.3.2. confsRequest and confsResponse messages 913 A 'confsRequest' message is used to retrieve, from the server, the 914 list of XCON-URIs associated with active and registered conferences A 915 'confsRequest' message REQUIRES no additional parameters beyond those 916 specified for the basic CCMP request message. The 'confObjId' 917 parameter MUST NOT be included in the confsRequest message. The 918 'confsRequest' message is of a "retrieve-only" type, since the sole 919 purpose is to collect information available at the conference server. 920 Thus, an 'operation' parameter MUST NOT be included in a 921 'confsRequest' message. The associated 'confsResponse' message 922 SHOULD contain the list of XCON-URIs in the 'confsInfo' parameter. A 923 user, upon receipt of the response message, can interact with the 924 available conference objects through further CCMP messages. 926 927 928 929 930 931 933 934 935 936 937 938 939 940 941 942 944 946 948 949 950 952 953 954 Figure 5: Structure of the confsRequest and confsResponse messages 956 7.2.3.3. blueprintRequest and blueprintResponse messages 958 Through a 'blueprintRequest', a client can manipulate the conference 959 object associated with a specified blueprint. The request MUST 960 include an 'operation' parameter and a 'confObjId' parameter. The 961 'confObjId' parameter MUST contain the XCON-URI of the blueprint, 962 which might have been previously retrieved through a 963 'blueprintsRequest' message. The blueprintRequest message SHOULD NOT 964 contain an 'operation' parameter other than 'retrieve'. The 965 'create', 'update' and 'delete' operations SHOULD NOT be included in 966 a 'blueprintRequest' message except in the case of privileged users 967 (e.g. the conference server administration staff). 969 In the case of responseCode of "success" for a 'retrieve' operation, 970 the 'blueprintInfo' parameter MUST be included in the 971 'blueprintResponse' message. The 'blueprintInfo' parameter contains 972 the conference document associated with the blueprint as identified 973 by the 'confObjID' parameter specified in the blueprintRequest. 975 If a response code of "objectNotFound" is received in a 976 'blueprintResponse' message, it is RECOMMENDED that a conference 977 control client attempt to retrieve another conference blueprint if 978 more than one had been received in the "blueprintsResponse" message. 979 If there was only one blueprint in the "blueprintsResponse" 980 initially, then the client should send another "blueprintsRequest" 981 message to determine if there may be new or additional blueprints for 982 the specific conferencing system. If this "blueprintsResponse" 983 message contains no blueprints, the handling is specific to the 984 conference control client. 986 987 988 989 990 991 992 993 994 995 997 999 1001 1002 1003 1005 1006 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1019 1021 1023 1024 1025 1026 1027 1029 Figure 6: Structure of the blueprintRequest and blueprintResponse 1030 messages 1032 7.2.3.4. confRequest and confResponse messages 1034 With a 'confRequest' message, CCMP clients can manipulate conference 1035 objects associated with either active or registered conferences 1036 (blueprints or reservations). The request MUST include an 1037 'operation' parameter. Depending upon the type of 'operation' a 1038 'confObjId' parameter MAY be included. The 'confObjId' parameter 1039 contains the XCON-URI of the specific active or registered 1040 conference. The requirements for inclusion of 'confInfo' parameter 1041 depends upon the specific 'operation' in the confRequest/confResponse 1042 and are detailed below. The detailed information included in the 1043 'confInfo' parameter MUST follow the rules as specified in the XCON 1044 Data Model document [I-D.ietf-xcon-common-data-model]. 1046 To create a new conference through a 'confRequest' message, two 1047 approaches can be considered: 1049 1. Creation through explicit cloning: the 'confObjId' parameter MUST 1050 contain the XCON-URI of the blueprint to be cloned, while the 1051 'confInfo' parameter MUST NOT be included in the confRequest; 1053 2. Creation through implicit cloning (also known as "direct 1054 creation"): the 'confObjId' parameter MUST NOT be included in the 1055 request, whereas the 'confInfo' parameter describing the 1056 conference to be created MUST be included in the confRequest. 1058 In both cases, the confResponse, for a successful completion of a 1059 'create' operation, contains a responseCode of 'success' and MUST 1060 contain the XCON-URI of the created conference in the 'confObjID' 1061 parameter. In addition, the 'confInfo' parameter transporting the 1062 created conference document MUST be included. Obviously, the newly 1063 created object can be manipulated by the client through a subsequent 1064 'update' operation. For example, after the creation and addition of 1065 the participants, the creator may want to lock the conference object. 1066 This can be accomplished with a confRequest with an operation of 1067 'update' by setting the 'locked' element in the confInfo included in 1068 the confRequest message described below. 1070 In the case of a confRequest with a 'retrieve' operation, the 1071 'confObjId' representing the XCON-URI of the target conference the 1072 conference control client MUST be included and the 'confInfo' 1073 parameter SHOULD NOT be included in the request. The conferencing 1074 server MUST ignore any 'confInfo' parameter that is received in a 1075 'confRequest' and this 'confInfo' parameter MUST NOT be included in 1076 the confResponse. If the confResponse for the 'retrieve' operation 1077 contains a responseCode of 'success', the 'confInfo' parameter MUST 1078 be included in the response. The 'confInfo' parameter MUST contain 1079 the entire conference document describing the target conference 1080 object in its current state. 1082 In case of of a confRequest with an 'update' operation, the 1083 'confInfo' and 'confObjID' MUST be included in the request. The 1084 'confInfo' represents an object of type "conference-type" containing 1085 all the changes to be applied to the conference whose identifier is 1086 'confObjId'. In the case of a confResponse with a responseCode of 1087 'success', no additional information is REQUIRED in the 1088 'confResponse' message. A responseCode of 'success' indicates that 1089 the referenced conference document has not been changed by the 1090 conference server. However, if the target conference object was not 1091 updated exactly as indicated by the client a responseCode of 1092 'modified' MUST be included in the 'confResponse' and the 'confInfo' 1093 parameter MUST contain the entire conference document to which any 1094 changes have been applied. A responseCode of 'changeFailedProtected' 1095 indicates that the conferencing client is not allowed to make the 1096 changes reflected in the 'confInfo' in the initial request. This 1097 could be due to policies, roles, specific privileges, etc.), with the 1098 reason specific to a conferencing system and its configuration. 1099 Thus, it is RECOMMENDED that the client continue using the previous 1100 version of the 'confInfo', if the conference was active. If the 1101 conference was not active, it is RECOMMENDED that the client revert 1102 to an original version of the blueprint or use another blueprint - 1103 one previously retrieved with a blueprintRequest or one obtained via 1104 a new blueprintsRequest/blueprintRequest sequence. 1106 In the case of a confRequest with a 'delete' operation, the 1107 'confObjId' representing the XCON-URI of the target conference MUST 1108 be included and the 'confInfo' SHOULD NOT be included in the request. 1109 The conferencing server MUST ignore any 'confInfo' parameter that is 1110 received. The confResponse MUST contain the same 'confObjId'that was 1111 included in the confRequest. The confResponse MUST contain a 1112 responseCode of 'success' if the targeted conference is successfully 1113 deleted. If the confResponse for the 'retrieve' operation contains a 1114 responseCode of 'success', the confResponse SHOULD NOT contain the 1115 'confInfo' parameter. If the conferencing server cannot delete the 1116 conference referenced by the 'confObjId' received in the confRequest 1117 because it is the parent of another conference object that is in use, 1118 the conferencing server MUST return a responseCode of 1119 'deleteParentFailed'. 1121 The schema for the confRequest/confResponse pair is shown in 1122 Figure 7. 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1135 1137 1139 1140 1141 1143 1144 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1157 1159 1161 1162 1163 1164 1165 1167 Figure 7: Structure of the confRequest and confResponse messages 1169 The following provides an example of the 'confInfo' parameter 1170 required to change the title of a conference: 1172 1173 1174 New conference title 1175 1176 1178 Figure 8: Updating a conference object: modifying the title of a 1179 conference 1181 Similarly, to remove the title of an existing conference, an 'update' 1182 operation carrying the following 'confInfo' parameter would do the 1183 job. 1185 1186 1187 1188 1189 1191 Figure 9: Updating a conference object: removing the title of a 1192 conference 1194 7.2.3.5. usersRequest and usersResponse messages 1196 Through a usersRequest message the CCMP client manipulates the 1197 element of the conference document associated with the 1198 conference identified by the 'confObjId' parameter. Inside the 1199 element, along with the list of conference users, there is 1200 information that the client may be interested in controlling, such as 1201 the lists of users to which access to the conference is allowed/ 1202 denied, conference participation policies, etc.; for this reason, a 1203 customized message has been designed to allow for the manipulation of 1204 this specific part of a conference document. 1206 A 'usersInfo' parameter MAY be included in a usersRequest message 1207 depending upon the operation. If the 'userInfo' parameter is 1208 included in the usersRequest message, the parameter MUST be compliant 1209 with the field of the XCON data model. 1211 Two operations are allowed for a "usersRequest" message: 1213 1. retrieve: In this case the request SHOULD NOT include a 1214 'usersInfo' parameter, while a successful response MUST contain 1215 the desired element in the 'usersInfo' parameter. The 1216 conference server MUST be ignore a 'usersInfo' parameter if it is 1217 received in a request with a 'retrieve' operation. 1219 2. update: In this case, the 'usersInfo' parameter MUST contain the 1220 modifications to be applied to the referred element. If 1221 the responseCode is 'success', then the 'usersInfo' parameter 1222 SHOULD NOT be returned. Any 'usersInfo' parameter that is 1223 returned SHOULD be ignored. If the responseCode is 'modified', 1224 the 'usersInfo' parameter MUST be included in the response. The 1225 'usersInfo' reflects to the client the (partial) modifications 1226 that have been applied. A responseCode of 1227 'changeFailedProtected' indicates that the conferencing client is 1228 not allowed to make the changes reflected in the 'usersInfo' in 1229 usersRequest message. This could be due to policies, roles, 1230 specific privileges, etc.), with the reason specific to a 1231 conferencing system and its configuration. Thus, it is 1232 RECOMMENDED that the client continue using the previous version 1233 of the 'usersInfo'. 1235 Operations of 'create' and 'delete' are not applicable to a 1236 usersRequest message and MUST NOT be considered by the server, which 1237 means that a responseCode of 'forbidden' MUST be included in the 1238 usersResponse message. 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1251 1253 1255 1256 1257 1259 1260 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1273 1275 1277 1278 1279 1280 1281 1283 Figure 10: Structure of the usersRequest and usersResponse messages 1285 7.2.3.6. userRequest and userResponse messages 1287 A "userRequest" message is used to manipulate elements inside 1288 a conference document associated with a conference identified by the 1289 'confObjId' parameter. Besides retrieving information about a 1290 specific conference user, the message is used to request that the 1291 conference server either create, modify, or delete information about 1292 a user. A "userRequest" message MUST include the 'confObjID', the 1293 'operation' parameter, and MAY include a 'userInfo' parameter 1294 containing the detailed user's information depending upon the 1295 operation and whether the 'userInfo' has already been populated for a 1296 specific user. Note that a user may not necessarily be a 1297 conferencing control client (i.e., some participants in a conference 1298 are not "XCON aware"). 1300 We remark that an XCON-USERID SHOULD be assigned to each and every 1301 user subscribed to the system. In such a way, a user who is not a 1302 conference participant can make requests (provided she has 1303 successfully passed AAA checks), like creating a conference, 1304 retrieving conference information, etc.. 1306 Conference users can be created in a number of different ways. In 1307 each of these cases the operation MUST be set to "create" in the 1308 userRequest message. Each of the userResponse messages for these 1309 cases MUST include the 'confObjID', 'confUserID', 'operation' and 1310 'responseCode' parameters. In the case of a response code of 1311 'success', the userResponse message MAY include the 'userInfo' 1312 parameter depending upon the manner in which the user was created: 1314 o Conferencing client with an XCON-USERID adds itself to the 1315 conference: In this case, the 'userInfo' parameter MAY be included 1316 in the userRequest. The 'userInfo' parameter MUST contain a 1317 element (compliant with the XCON data model) and the 1318 'entity' attribute MUST be set to a value which represents the 1319 XCON-USERID of the user initiating the request. No additional 1320 parameters beyond those previously described are REQUIRED in the 1321 userResponse message, in the case of a responseCode of 'success'. 1323 o Conferencing client acts on behalf of a third user whose XCON- 1324 USERID is known: in this case, the 'userInfo' parameter MUST be 1325 included in the userRequest. The 'userInfo' parameter MUST 1326 contain a element and the 'entity' attribute value MUST be 1327 set to the XCON-USERID of the third user in question. No 1328 additional parameters beyond those previously described are 1329 REQUIRED in the userResponse message, in the case of a 1330 responseCode of 'success'. 1332 o A conferencing client who has no XCON-USERID and who wants to 1333 enter, via CCMP, a conference whose identifier is known. In such 1334 case, a side-effect of the request is that the user is provided 1335 with an appropriate XCON-USERID. The involved messages 1336 (userRequest and userResponse) in such case should look like the 1337 following: 1339 Request fields: 1341 confUserId=null; 1342 confObjId=confXYZ; 1343 operation=create; 1344 userInfo= 1346 1347 1348 ... 1350 Response fields (in case of success): 1352 confUserId=user345; 1353 confObjId=confXYZ; 1354 operation=create; 1355 response-code=success; 1356 userInfo=null; //or the entire userInfo object 1358 Figure 11: userRequest and userResponse in the absence of an xcon- 1359 userid 1361 o Conferencing client is unaware of the XCON-USERID of a third user: 1362 In this case, the 'entity' attribute MUST NOT be included in the 1363 request. The XCON-USERID generated by the conference server for 1364 such a user MUST also be returned to the client as the value of 1365 the 'entity' attribute in the 'userInfo' parameter of the response 1366 if the responseCode is "success". This scenario is mainly 1367 intended to support the case whereby an XCON aware client is added 1368 to a conference by a third party, e.g. the chairperson of the 1369 conference. 1371 o Conferencing client obtains a new user profile in the context of a 1372 conference: this case is handled in the same manner as the 1373 previous case associated with the creation of a user on behalf of 1374 a third party when the XCON-USERID is unknown, thus indicating to 1375 the conference server that the client wants a new XCON-USERID and 1376 associated 'userInfo' parameter to be allocated and populated 1377 respectively. 1379 In both cases, the confResponse, for a successful completion of a 1380 'create' operation, contains a responseCode of 'success' and MUST 1381 contain the XCON-URI of the created conference in the 'confObjID' 1382 parameter. In addition, the 'confInfo' parameter transporting the 1383 created conference document MUST be included. Obviously, the newly 1384 created object can be manipulated by the client through a subsequent 1385 'update' operation. 1387 In the case of a userRequest with a 'retrieve' operation, the 1388 'confObjId' representing the XCON-URI of the target conference MUST 1389 be included. The 'confUserId' MUST be included in the userRequest 1390 message. This 'confUserId' indicates the specific element in 1391 XCON data model, as reflected by the 'entity' attribute in the 1392 element that the conference client is requesting to retrive. The 1393 'userInfo' parameter SHOULD NOT be included in the request. The 1394 conferencing server MUST ignore any 'userInfo' parameter that is 1395 received in a 'userRequest' and this 'userInfo' parameter MUST NOT be 1396 included in the userResponse. If the userResponse for the 'retrieve' 1397 operation contains a responseCode of 'success', the 'userInfo' 1398 parameter MUST be included in the response. 1400 In case of of a userRequest with an 'update' operation, the 1401 'confObjID', 'confUserID' and 'userInfo' MUST be included in the 1402 request. The 'userInfo' is of type "user-type" and contains all the 1403 changes to be applied to a specific element in the conference 1404 object identified by the 'confObjId' in the userRequest message. The 1405 'entity' attribute in the 'userInfo' MUST be equal to the 1406 'confUserID' in the userRequest message. In the case of a user 1407 Response with a responseCode of 'success', no additional information 1408 is REQUIRED in the 'confResponse' message. A responseCode of 1409 'success' indicates that the referenced user element has been updated 1410 by the conference server. However, if the specific element 1411 was not updated exactly as indicated by the client a responseCode of 1412 'modified' MUST be included in the 'confResponse' and the 'userInfo' 1413 parameter MUST contain the entire element which to which the 1414 conference server has applied changes. A responseCode of 1415 'changeFailedProtected' indicates that the conferencing client is not 1416 allowed to make the changes reflected in the 'userInfo' in the 1417 initial request. This could be due to policies, roles, specific 1418 privileges, etc., with the reason specific to a conferencing system 1419 and its configuration. Thus, it is RECOMMENDED that the client 1420 continue using the previous version of the 'userInfo'. 1422 In the case of a userRequest with a 'delete' operation, the 1423 'confObjId' representing the XCON-URI of the target conference and 1424 the 'confUserID' associated with the specific element (i.e., 1425 matching the 'entity' attribute) that the conferencing client is 1426 requesting be deleted MUST be included in the userRequest message. 1427 The 'userInfo' SHOULD NOT be included in the request. The 1428 conferencing server MUST ignore any 'userInfo' parameter that is 1429 received. The userResponse MUST contain the same 'confObjId' that 1430 was included in the userRequest. The userResponse MUST contain a 1431 responseCode of 'success' if the element associated with the 1432 specific 'confUserId' is successfully deleted. If the userResponse 1433 for the 'retrieve' operation contains a responseCode of 'success', 1434 the userResponse SHOULD NOT contain the 'userInfo' parameter. 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1447 1449 1451 1452 1453 1455 1456 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1469 1471 1473 1474 1475 1476 1477 1479 Figure 12: Structure of the userRequest and userResponse messages 1481 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse messages 1483 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1484 on the field of the conference object represented 1485 by the 'confObjId'. The request MUST include an 'operation' of 1486 "retrieve" and a 'confObjId' parameter. Operations of 'create', 1487 'update' and 'delete' MUST NOT be included in a sidebarsByValRequest 1488 message. A "sidebarsByValResponse" with a responseCode of 'success' 1489 MUST contain a 'sidebarsByValInfo' parameter containing the desired 1490 element. The 'sidebarsByValInfo' parameter 1491 contains the identifiers of the sidebars derived from the main 1492 conference in the form of XCON-URIs. The retrieved sidebars can then 1493 be updated or deleted using the "sidebarByValRequest" message, which 1494 is described in Section 7.2.3.8. 1496 1498 1499 1500 1501 1502 1503 1504 1505 1506 1508 1510 1513 1514 1515 1517 1518 1520 1522 1523 1524 1525 1526 1527 1528 1529 1530 1532 1534 1537 1538 1539 1541 1542 1543 Figure 13: Structure of the sidebarsByValRequest and 1544 sidebarsByValResponse messages 1546 7.2.3.8. sidebarByValRequest and sidebarByValResponse messages 1548 A sidebarByValRequest message MUST contain the 'operation' parameter 1549 which discriminates among retrieval, creation, modification and 1550 deletion of a specific sidebar. The other required parameters depend 1551 upon the type of operation. 1553 In the case of a 'create' operation, the 'confObjId' parameter MUST 1554 be included in the sidebyValRequest message. In this case, the 1555 'confObjId' parameter contains the XCON-URI of the main conference in 1556 which the sidebar is to be created. The 'sidebarByValInfo' parameter 1557 SHOULD NOT be included in the request, since, as envisaged in the 1558 XCON framework ([RFC5239]), sidebars are always created by cloning 1559 the main conference. Any 'sidebarByValInfo' included in the request 1560 MUST be ignored. The conference server sets the 'active' element to 1561 'false' of the cloned conference to reflect that it is a "reserved" 1562 conference. The conference server MUST update the conference object 1563 reflected by the 'confObjID' parameter, in the sidebarbyVal request 1564 message, from which the sidebar was created to reflect the newly 1565 created sidebar. The newly created conference object MUST be 1566 included in the response in the 'sidebarByValInfo' parameter, if the 1567 responseCode is 'success'. The URI for the conference object 1568 associated with the newly created sidebar object MUST appear in the 1569 'entity' attribute in the 'sidebarByValInfo'. The conference server 1570 can notify any conferencing clients that have subscribed to the 1571 conference event package, and are authorized to receive the 1572 notifications, of the addition of the sidebar to the conference. 1574 In the case of a 'sidebarByVal' request with an operation of 1575 'retrieve', the URI for the conference object created for the 1576 sidebar, as reflected by the 'entity' attribute in the 1577 'sidebarByValInfo', received in the response to a 'create' operation 1578 or in a sidebarsByValResponse message, MUST be included in the 1579 'confObjID' parameter in the request. This 'retrieve' operation is 1580 handled by the conference server in the same manner as a 'retrieve' 1581 operation included in a confRequest message as detailed in 1582 Section 7.2.3.4. 1584 In the case of a 'sidebarByVal' request with an operation of 1585 'update', the 'sidebarByValInfo' MUST also be included in the 1586 request. The 'entity' attribute in the 'sidebarByValInfo' identifies 1587 the specific sidebar instance to be updated. The URI for the 1588 conference object containing the specific sidebar-by-value element to 1589 be updated MUST be included in the 'confObjID' parameter in the 1590 request. An 'update' operation on the 'sidebarByValInfo' is handled 1591 by the conference server in the same manner as an 'update' operation 1592 on the confInfo included in a confRequest message as detailed in 1593 Section 7.2.3.4. 1595 If an 'operation' of 'delete' is included in the sidebarByVal 1596 request, the 'sidebarByValInfo' parameter SHOULD NOT be included in 1597 the request. Any 'sidebarByValInfo' included in the request SHOULD 1598 be ignored by the conference server. The URI for the conference 1599 object for the sidebar, as reflected by the 'entity' attribute in the 1600 'sidebarByValInfo', received in the response to a 'create' operation 1601 or in a sidebarsByValResponse message, MUST be included in the 1602 'confObjID' parameter in the request. If the specific conferencing 1603 user as reflected by the 'confUserID' in the request is authorized to 1604 delete the conference, the conference server deletes the conference 1605 object reflected by the 'confObjID' parameter and updates the data in 1606 the conference object from which the sidebar was cloned. The 1607 conference server can notify any conferencing clients that have 1608 subscribed to the conference event package, and are authorized to 1609 receive the notifications, of the deletion of the sidebar to the 1610 conference. 1612 1614 1615 1616 1617 1618 1619 1620 1621 1622 1624 1626 1629 1630 1631 1633 1634 1636 1638 1639 1640 1641 1642 1643 1644 1645 1646 1648 1650 1653 1654 1655 1657 1658 1659 Figure 14: Structure of the sidebarByValRequest and 1660 sidebarByValResponse messages 1662 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse messages 1664 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1665 invoked to retrieve the element of the conference 1666 object identified by the 'confObjId' parameter. The 'confObjID' 1667 parameter MUST be included in the request. An operation of 1668 'retrieve' MUST also be included in the request. Operations of 1669 'create', 'update' and 'delete' MUST NOT be included in a 1670 sidebarsByValRequest message. In the case of a responseCode of 1671 'success', the 'sidebarsByRefInfo' parameter, containing the 1672 element of the conference object, MUST be included 1673 in the response. The element represents the set of 1674 URIs of the sidebars associated with the main conference, whose 1675 description (in the form of a standard XCON conference document) is 1676 external to the main conference itself. Through the retrieved URIs, 1677 it is then possible to access single sidebars using the 1678 "sidebarByRef" request message, described in Section 7.2.3.10. 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1691 1693 1696 1697 1698 1700 1701 1703 1705 1706 1707 1708 1709 1710 1711 1712 1713 1715 1717 1720 1721 1722 1724 1725 1726 Figure 15: Structure of the sidebarsByRefRequest and 1727 sidebarsByRefResponse messages 1729 7.2.3.10. sidebarByRefRequest and sidebarByRefResponse messages 1731 A sidebarByRefRequest message MUST contain the 'operation' parameter 1732 which discriminates among retrieval, creation, modification and 1733 deletion of a specific sidebar. The other required parameters depend 1734 upon the type of operation. 1736 In the case of an 'operation of 'create', the 'confObjId' parameter 1737 representing the XCON-URI of the conference from which the sidebar is 1738 to be created (cloned) MUST be included in all sidebarByRefRequest 1739 messages. The'sidebarByRefInfo' parameter SHOULD NOT be included in 1740 the request, since, as envisaged in the XCON framework ([RFC5239]), 1741 sidebars are always created by cloning the main conference. Any 1742 'sidebarByRefInfo' included in the request MUST be ignored. If the 1743 creation of the sidebar is successful, the conference server MUST 1744 update the 'sidebars-by-ref' element in the conference object from 1745 which the sidebar was created (i.e., as identified by the 'confObjID' 1746 in the original sidebarByRef request), with the URI for the newly 1747 created sidebar. The newly created conference object MUST be 1748 included in the response in the 'sidebarByRefInfo' parameter with a 1749 responseCode 'success'. The URI for the conference object associated 1750 with the newly created sidebar object MUST appear in the 'entity' 1751 attribute in the 'sidebarByRefInfo'. The conference server can 1752 notify any conferencing clients that have subscribed to the 1753 conference event package, and are authorized to receive the 1754 notifications, of the addition of the sidebar to the conference. 1756 In the case of a 'sidebarByRef' request with an operation of 1757 'retrieve', the URI for the conference object created for the sidebar 1758 MUST be included in the 'confObjID' parameter in the request. The 1759 'sidebarByRefInfo' MUST also be included in the request in the case 1760 of an 'operation' of 'update'. An 'update' operation on the 1761 'sidebarByRefInfo' is handled by the conference server in the same 1762 manner as a 'retrieve' operation on the confInfo included in a 1763 confRequest message as detailed in Section 7.2.3.4. 1765 In the case of a 'sidebarByRef' request with an operation of 1766 'update', the URI for the conference object created for the sidebar 1767 MUST be included in the 'confObjID' parameter in the request. The 1768 'sidebarByRefInfo' MUST also be included in the request in the case 1769 of an 'operation' of 'update'. An 'update' operation on the 1770 'sidebarByRefInfo' is handled by the conference server in the same 1771 manner as an 'update' operation on the confInfo included in a 1772 confRequest message as detailed in Section 7.2.3.4. 1774 If an 'operation' of 'delete' is included in the sidebarByRef 1775 request, the 'sidebarByRefInfo' parameter SHOULD NOT be included in 1776 the request. Any 'sidebarByRefInfo' included in the request SHOULD 1777 be ignored by the conference server. The URI for the conference 1778 object for the sidebar MUST be included in the 'confObjID' parameter 1779 in the request. If the specific conferencing user as reflected by 1780 the 'confUserID' in the request is authorized to delete the 1781 conference, the conference server SHOULD delete the conference object 1782 reflected by the 'confObjID' parameter and SHOULD update the 1783 'sidebars-by-ref' element in the conference object from which the 1784 sidebar was originally cloned. The conference server can notify any 1785 conferencing clients that have subscribed to the conference event 1786 package, and are authorized to receive the notifications, of the 1787 deletion of the sidebar. 1789 1791 1792 1793 1794 1795 1796 1797 1798 1799 1801 1803 1806 1807 1808 1810 1811 1813 1815 1816 1817 1818 1819 1820 1821 1822 1823 1825 1827 1830 1831 1832 1834 1835 1836 Figure 16: Structure of the sidebarByRefRequest and 1837 sidebarByRefResponse messages 1839 8. A complete example of the CCMP in action 1841 [spromano-09] This section has to be updated, since we added the 1842 'operation' parameter in response messages. Hence, we first have to 1843 update the schema file; then, we have to change the excrpts in this 1844 section. 1846 In this section a typical scenario in which the CCMP comes into play 1847 is described, by showing the actual composition of the various CCMP 1848 messages. In the call flows of the example, the Conference Control 1849 Client is a CCMP-enabled client, whereas the Conference Control 1850 Server is a CCMP-enabled server. The 'confUserId' of the client is 1851 "Alice" and appears in all requests. The sequence of operations is 1852 as follows: 1854 1. Alice retrieves from the server the list of available blueprints 1855 (Section 8.1); 1857 2. Alice asks for detailed information about a specific blueprint 1858 (Section 8.2); 1860 3. Alice decides to create a new conference by cloning the retrieved 1861 blueprint (Section 8.3); 1863 4. Alice modifies information (e.g. XCON-URI, name, description) 1864 associated with the newly created blueprint (Section 8.4); 1866 5. Alice specifies a list of users to be contacted when the 1867 conference is activated (Section 8.5); 1869 6. Alice joins the conference (Section 8.6); 1871 7. Alice lets a new user (whose 'confUserId' is "Ciccio") join the 1872 conference (Section 8.7). 1874 Note, the examples do not include any details beyond the basic 1875 operation. 1877 In the following sections we deal with each of the above mentioned 1878 actions separately. 1880 8.1. Alice retrieves the available blueprints 1882 This section illustrates the transaction associated with retrieval of 1883 the blueprints, together with a dump of the two messages exchanged 1884 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 1885 the figure, the "blueprintsResponse" message contains, in the 1886 'blueprintsInfo' parameter, information about the available 1887 blueprints, in the form of the standard XCON-URI of the blueprint, 1888 plus additional (and optional) information, like its display-text and 1889 purpose. 1891 Alice retrieves from the server the list of available blueprints: 1893 CCMP Client CCMP Server 1894 | | 1895 | CCMP blueprintsRequest message | 1896 | - confUserID: Alice | 1897 | - confObjId: (null) | 1898 |------------------------------------------------------>| 1899 | | 1900 | CMP blueprintsResponse message | 1901 | - confUserID: Alice | 1902 | - confObjId: (null) | 1903 | - responseCode: success | 1904 | - blueprintsInfo: bp123,bp124,.. | 1905 |<------------------------------------------------------| 1906 | | 1907 . . 1908 . . 1910 1. blueprintsRequest message: 1912 1913 1916 1918 xcon-userid:Alice@meetecho.com 1919 1920 1922 2. blueprintsResponse message form the server: 1924 1925 1929 1933 xcon-userid:Alice@meetecho.com 1934 success 1935 1936 1937 1938 xcon:AudioRoom@meetecho.com 1939 AudioRoom 1940 Simple Room: 1941 conference room with public access, 1942 where only audio is available, more users 1943 can talk at the same time 1944 and the requests for the AudioFloor 1945 are automatically accepted. 1946 1947 1948 1949 xcon:VideoRoom@meetecho.com 1950 VideoRoom 1951 Video Room: 1952 conference room with public access, 1953 where both audio and video are available, 1954 8 users can talk and be seen at the same time, 1955 and the floor requests are automatically accepted. 1956 1957 1958 1959 xcon:AudioConference1@meetecho.com 1960 AudioConference1 1961 Public Audio Conference: 1962 conference with public access, 1963 where only audio is available, 1964 only one user can talk at the same time, 1965 and the requests for the AudioFloor MUST 1966 be accepted by a Chair. 1967 1968 1969 1970 xcon:VideoConference1@meetecho.com 1971 VideoConference1 1972 Public Video Conference: conference 1973 where both audio and video are available, 1974 only one user can talk 1975 1976 1977 1978 xcon:AudioConference2@meetecho.com 1979 AudioConference2 1980 Basic Audio Conference: 1982 conference with private access, 1983 where only audio is available, 1984 only one user can talk at the same time, 1985 and the requests for the AudioFloor MUST 1986 be accepted by a Chair. 1987 1988 1989 1990 1991 1992 1994 Figure 17: Getting blueprints from the server 1996 8.2. Alice gets detailed information about a specific blueprint 1998 This section illustrates the second transaction in the overall flow. 1999 In this case, Alice, who now knows the XCON-URIs of the blueprints 2000 available at the server, makes a drill-down query, in the form of a 2001 CCMP "blueprintRequest" message, to get detailed information about 2002 one of them (the one called with XCON-URI 2003 "xcon:AudioRoom@meetecho.com"). The picture shows such transaction. 2004 Notice that the response contains, in the 'blueprintInfo' parameter, 2005 a document compliant with the standard XCON data model. 2007 Alice retrieves detailed information about a specified blueprint: 2009 CCMP Client CCMP Server 2010 | | 2011 | CCMP blueprintRequest message | 2012 | - confUserID: Alice | 2013 | - confObjId: bp123 | 2014 | - operation: retrieve | 2015 | - blueprintInfo: (null) | 2016 |------------------------------------------------------>| 2017 | | 2018 | CCMP blueprintResponse message | 2019 | - confUserID: Alice | 2020 | - confObjId: bp123 | 2021 | - operation: retrieve | 2022 | - responseCode: success | 2023 | - blueprintInfo: bp123Info | 2024 |<------------------------------------------------------| 2025 | | 2026 . . 2027 . . 2029 1. blueprintRequest message: 2031 2032 2036 2038 xcon:AudioRoom@meetecho.com 2039 xcon-userid:Alice@meetecho.com 2040 retrieve 2041 2042 2043 2045 2. blueprintResponse message form the server: 2047 2048 2052 2054 xcon:AudioRoom@meetecho.com 2055 retrieve 2056 xcon-userid:Alice@meetecho.com 2057 success 2058 2059 2060 2061 AudioRoom 2062 2 2063 2064 2065 audio 2066 2067 2068 2069 2070 allow 2071 2072 2073 confirm 2074 2075 2076 2077 2078 2079 2080 2081 2082 2084 Figure 18: Getting info about a specific blueprint 2086 8.3. Alice creates a new conference through a cloning operation 2088 This section illustrates the third transaction in the overall flow. 2089 Alice decides to create a new conference by cloning the blueprint 2090 having XCON-URI "xcon:AudioRoom@meetecho.com", for which she just 2091 retrieved detailed information through the "blueprintRequest" 2092 message. This is achieved by sending a "confRequest/create" message 2093 having the blueprint's URI in the 'confObjId' parameter. The picture 2094 shows such transaction. Notice that the response contains, in the 2095 'confInfo' parameter, the document associated with the newly created 2096 conference, which is compliant with the standard XCON data model. 2097 The 'confObjId' in the response is set to the XCON-URI of the new 2098 conference (in this case, "xcon:8977794@meetecho.com"). We also 2099 notice that this value is equal to the value of the "entity" 2100 attribute of the element of the document 2101 representing the newly created conference object. 2103 Alice creates a new conference by cloning the 2104 "xcon:AudioRoom@meetecho.com" blueprint: 2106 CCMP Client CCMP Server 2107 | | 2108 | CCMP confRequest message | 2109 | - confUserID: Alice | 2110 | - confObjId: AudioRoom | 2111 | - operation: create | 2112 | - confInfo: (null) | 2113 |------------------------------------------------------>| 2114 | | 2115 | CCMP confResponse message | 2116 | - confUserID: Alice | 2117 | - confObjId: newConfId | 2118 | - operation: create | 2119 | - responseCode: success | 2120 | - confInfo: newConfInfo | 2121 |<------------------------------------------------------| 2122 | | 2123 . . 2124 . . 2126 1. confRequest message: 2128 2129 2133 2136 xcon:AudioRoom@meetecho.com 2137 xcon-userid:Alice@meetecho.com 2138 create 2139 2140 2141 2143 2. confResponse message from the server: 2145 2146 2150 2153 xcon:8977794@meetecho.com 2154 xcon-userid:Alice@meetecho.com 2155 create 2156 success 2157 2158 2159 2160 2161 New conference by Alice cloned from AudioRoom 2162 2163 2164 2165 2166 xcon:8977794@meetecho.com 2167 2168 2169 conference xcon-uri 2170 2171 2172 8601 2173 2174 2175 2176 10 2177 2178 2179 audio 2180 2181 2182 2183 2184 allow 2185 2186 2187 2188 confirm 2189 2190 2191 2192 2193 2194 2195 2196 2198 Figure 19: Creating a new conference by cloning a blueprint 2200 8.4. Alice updates conference information 2202 This section illustrates the fourth transaction in the overall flow. 2203 Alice decides to modify some of the details associated with the 2204 conference she just created. More precisely, she changes the 2205 element under the element of 2206 the document representing the conference. This is achieved through a 2207 "confRequest/update" message carrying the fragment of the conference 2208 document to which the required changes have to be applied. As shown 2209 in the picture, the response contains a code of 'success', which 2210 acknowledges the modifications requested by the client. 2212 Alice updates information about the conference she just created: 2214 CCMP Client CCMP Server 2215 | | 2216 | CCMP confRequest message | 2217 | - confUserID: Alice | 2218 | - confObjId: 897779 | 2219 | - operation: update | 2220 | - confInfo: conf456Updates | 2221 |------------------------------------------------------>| 2222 | | 2223 | CCMP confResponse message | 2224 | - confUserID: Alice | 2225 | - confObjId: 8977794 | 2226 | - operation: update | 2227 | - responseCode: success | 2228 | - confInfo: (null) | 2229 |<------------------------------------------------------| 2230 | | 2231 . . 2232 . . 2234 1. confRequest message: 2236 2237 2241 2244 xcon:8977794@meetecho.com 2245 xcon-userid:Alice@meetecho.com 2246 update 2247 2248 2249 2250 2251 Alice's conference 2253 2254 2255 2256 2257 2258 2260 2. confResponse message form the server: 2262 2263 2267 2269 xcon:8977794@meetecho.com 2270 xcon-userid:Alice@meetecho.com 2271 update 2272 success 2273 2274 2275 2277 Figure 20: Updating conference information 2279 8.5. Alice inserts a list of users in the conference object 2281 This section illustrates the fifth transaction in the overall flow. 2282 Alice modifies the under the element in 2283 the document associated with the conference she created. To the 2284 purpose, she exploits the "usersRequest" message provided by the 2285 CCMP. The picture below shows the transaction. 2287 Alice updates information about the list of users to whom access to 2288 the conference is permitted: 2290 CCMP Client CCMP Server 2291 | | 2292 | CCMP usersRequest message | 2293 | - confUserID: Alice | 2294 | - confObjId: 8977794 | 2295 | - operation: update | 2296 | - usersInfo: usersUpdates | 2297 |------------------------------------------------------>| 2298 | | 2299 | CCMP usersResponse message | 2300 | - confUserID: Alice | 2301 | - confObjId: 8977794 | 2302 | - operation: update | 2303 | - responseCode: success | 2304 | - usersInfo: (null) | 2305 |<------------------------------------------------------| 2306 | | 2307 . . 2308 . . 2310 1. usersRequest message: 2312 2313 2317 2319 xcon:8977794@meetecho.com 2320 xcon-userid:Alice@meetecho.com 2321 update 2322 2323 2324 2325 2327 2329 2331 2332 2333 2334 2335 2337 2. usersResponse message form the server: 2339 2340 2344 2346 xcon:8977794@meetecho.com 2347 xcon-userid:Alice@meetecho.com 2348 update 2349 success 2350 2351 2352 2354 Figure 21: Updating the list of allowed users for the conference 2355 'xcon:8977794@meetecho.com' 2357 8.6. Alice joins the conference 2359 This section illustrates the sixth transaction in the overall flow. 2360 Alice uses the CCMP to add herself to the newly created conference. 2361 This is achieved through a "userRequest/create" message containing, 2362 in the 'userInfo' parameter, a element compliant with the XCON 2363 data model representation. Notice that such element includes 2364 information about the user's Address of Records, as well as her 2365 current end-point. The picture below shows the transaction. Notice 2366 how the 'confUserId' parameter is equal to the "entity" attribute of 2367 the element, which indicates that the request issued by 2368 the client is a first-party one. 2370 Alice joins the conference by issuing a "userRequest/create" message 2371 with her own id to the server: 2373 CCMP Client CCMP Server 2374 | | 2375 | CCMP userRequest message | 2376 | - confUserID: Alice | 2377 | - confObjId: 8977794 | 2378 | - operation: create | 2379 | - userInfo: AliceUserInfo | 2380 |------------------------------------------------------>| 2381 | | 2382 | CCMP userResponse message | 2383 | - confUserID: Alice | 2384 | - confObjId: 8977794 | 2385 | - operation: create | 2386 | - responseCode: success | 2387 | - userInfo: (null) | 2388 |<------------------------------------------------------| 2389 | | 2390 . . 2391 . . 2393 1. userRequest message: 2395 2396 2400 2402 xcon:8977794@meetecho.com 2403 xcon-userid:Alice@meetecho.com 2404 create 2405 2406 2407 2408 2409 2410 mailto:Alice83@example.com 2411 2412 email 2413 2414 2415 2416 2417 2418 2419 2421 2. userResponse message form the server: 2423 2424 2428 2430 xcon:8977794@meetecho.com 2431 xcon-userid:Alice@meetecho.com 2432 create 2433 success 2434 2435 2436 2438 Figure 22: Alice joins the conference through the CCMP 2440 8.7. Alice adds a new user to the conference 2442 This section illustrates the seventh and last transaction in the 2443 overall flow. Alice uses the CCMP to add a new user to the 2444 conference. This is achieved through a "userRequest/create" message 2445 containing, in the 'userInfo' parameter, a element compliant 2446 with the XCON data model representation. Notice that such element 2447 includes information about the user's Address of Records, as well as 2448 his current end-point. The picture below shows the transaction. 2449 Notice how the 'confUserId' parameter in the request is Alice's id, 2450 whereas the element has no "entity" attribute and contains 2451 information about a different user, thus indicating that the request 2452 issued by the client is a third-party one. This is also reflected in 2453 the response coming from the server, which this time contains a non- 2454 void element, whose "entity" attribute has been set by the 2455 server to the value of the newly created conference user id. 2457 Alice adds user "Ciccio" to the conference by issuing a third-party 2458 "userRequest/create" message to the server: 2460 CCMP Client CCMP Server 2461 | | 2462 | CCMP userRequest message | 2463 | - confUserID: Alice | 2464 | - confObjId: 8977794 | 2465 | - operation: create | 2466 | - usersInfo: CiccioUserInfo | 2467 |------------------------------------------------------>| 2468 | | 2469 | CCMP userResponse message | 2470 | - confUserID: Alice | 2471 | - confObjId: 8977794 | 2472 | - operation: create | 2473 | - responseCode: success | 2474 | - usersInfo: (not null!)| 2475 |<------------------------------------------------------| 2476 | | 2477 . . 2479 . . 2481 1. "third party" userRequest message from Alice: 2483 2484 2488 2490 xcon:8977794@meetecho.com 2491 xcon-userid:Alice@meetecho.com 2492 create 2493 2494 2495 2496 2497 2498 mailto:ciccio@pernacchio.com 2499 2500 email 2501 2502 2503 2504 2505 2506 2507 2509 2. "third party" userResponse message form the server: 2511 2512 2516 2518 8977794 2519 xcon-userid:Alice@meetecho.com 2520 success 2521 create 2522 2523 2524 2525 2526 2527 mailto:ciccio@pernacchio.com 2528 2529 email 2530 2531 2532 2533 2534 2535 2536 2538 Figure 23: Alice adds a new user to the conference through the CCMP 2540 9. Locating a Conference Control Server 2542 If a conference control client is not pre-configured to use a 2543 specific conference control server for the requests, the client MUST 2544 first discover the conference control server before it can send any 2545 requests. The result of the discovery process, is the address of the 2546 server supporting conferencing. In this document, the result is an 2547 http: or https: URI, which identifies a conference server. 2549 This document proposes the use of DNS to locate the conferencing 2550 server. U-NAPTR resolution for conferencing takes a domain name as 2551 input and produces a URI that identifies the conferencing server. 2552 This process also requires an Application Service tag and an 2553 Application Protocol tag, which differentiate conferencing-related 2554 NAPTR records from other records for that domain. 2556 Section 14.4.1 defines an Application Service tag of "XCON", which is 2557 used to identify the centralized conferencing (XCON) server for a 2558 particular domain. The Application Protocol tag "CCMP", defined in 2559 Section 14.4.2, is used to identify an XCON server that understands 2560 the CCMP protocol. 2562 The NAPTR records in the following example Figure 24 demonstrate the 2563 use of the Application Service and Protocol tags. Iterative NAPTR 2564 resolution is used to delegate responsibility for the conferencing 2565 service from "zonea.example.com." and "zoneb.example.com." to 2566 "outsource.example.com.". 2568 zonea.example.com. 2569 ;; order pref flags 2570 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2571 "" ; regex 2572 outsource.example.com. ; replacement 2573 ) 2574 zoneb.example.com. 2575 ;; order pref flags 2576 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2577 "" ; regex 2578 outsource.example.com. ; replacement 2579 ) 2580 outsource.example.com. 2581 ;; order pref flags 2582 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 2583 "!*.!https://confs.example.com/!" ; regex 2584 . ; replacement 2585 ) 2586 Figure 24: Sample XCON:CCMP Service NAPTR Records 2588 Details for the "XCON" Application Service tag and the "CCMP" 2589 Application Protocol tag are included in Section 14.4. 2591 10. Managing Notifications 2593 In cases where the conference control client uses SIP [RFC3261] as 2594 the signaling protocol to participate in the conference, SIP event 2595 notification can be used. This would REQUIRE the conference control 2596 client to implement the Conference event package for XCON 2597 [I-D.ietf-xcon-event-package]. This is the default mechanism for 2598 conferencing clients as is SIP for signaling per the XCON Framework 2599 [RFC5239]. 2601 In the case where the interface to the conference server is entirely 2602 web based, there is a common mechanism for web-based systems that 2603 could be used - a "call back". With this mechanism, the conference 2604 client provides the conference server with an HTTP URL which is 2605 invoked when a change occurs. This is a common implementation 2606 mechanism for e-commerce. This works well in the scenarios whereby 2607 the conferencing client is a web server that provides the graphical 2608 HTML user interface and uses CCMP as the backend interface to the 2609 conference server. And, this model can co-exist with the SIP event 2610 notification model. PC-based clients behind NATs could provide a SIP 2611 event URI, whereas web servers would probably find the HTTP model 2612 much easier to program. The details of this approach are out of 2613 scope for the CCMP per se, thus the expectation is that a future 2614 specification will document this solution. 2616 11. HTTP Transport 2618 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 2619 [RFC2818] as transport mechanisms for the CCMP protocol, which a 2620 conforming conference Server and Conferencing client MUST support. 2622 Although CCMP uses HTTP as a transport, it uses a strict subset of 2623 HTTP features, and due to the restrictions of some features, a 2624 conferencing server may not a fully compliant HTTP server. It is 2625 intended that a conference server can easily be built using an HTTP 2626 server with extensibility mechanisms, and that a conferencing client 2627 can trivially use existing HTTP libraries. This subset of 2628 requirements helps implementors avoid ambiguity with the many options 2629 the full HTTP protocol offers. 2631 A conferencing client that conforms to this specification SHOULD NOT 2632 be required to support HTTP authentication [RFC2617] or cookies 2633 [RFC2965]. Because the conferencing client and the conference server 2634 may have a prior relationship, the conference server SHOULD NOT 2635 require a conferencing client to authenticate, either using the above 2636 HTTP authentication methods or TLS client authentication. 2638 A CCMP request is carried in the body of an HTTP POST request. The 2639 conferencing client MUST include a Host header in the request. 2641 The MIME type of CCMP request and response bodies is "application/ 2642 ccmp+xml". The conference server and conferencing client MUST 2643 provide this value in the HTTP Content-Type and Accept header fields. 2644 If the conference server does not receive the appropriate Content- 2645 Type and Accept header fields, the conference server SHOULD fail the 2646 request, returning a 406 (not acceptable) response. CCMP responses 2647 SHOULD include a Content-Length header. 2649 Conferencing clients MUST NOT use the "Expect" header or the "Range" 2650 header in CCMP requests. The conference server MAY return 501 (not 2651 implemented) errors if either of these HTTP features are used. In 2652 the case that the conference server receives a request from the 2653 conferencing client containing a If-* (conditional) header, the 2654 conference server SHOULD return a 412 (precondition failed) response. 2656 The POST method is the only method REQUIRED for CCMP. If a 2657 conference server chooses to support GET or HEAD, it SHOULD consider 2658 the kind of application doing the GET. Since a conferencing client 2659 only uses a POST method, the GET or HEAD MUST be either an escaped 2660 URL (e.g., somebody found a URL in protocol traces or log files and 2661 fed it into their browser) or somebody doing testing/ debugging. The 2662 conference server could provide information in the HELD response 2663 indicating that the URL corresponds to a conference server and only 2664 responds to CCMP POST requests or the conference server could instead 2665 try to avoid any leak of information by returning a very generic HTTP 2666 error message such as 404 (not found). 2668 The conference server populates the HTTP headers of responses so that 2669 they are consistent with the contents of the message. In particular, 2670 the "CacheControl" header SHOULD be set to disable caching of any 2671 conference information by HTTP intermediaries. Otherwise, there is 2672 the risk of stale information and/or the unauthorized disclosure of 2673 the information. The HTTP status code MUST indicate a 2xx series 2674 response for all CCMP Response and Error messages. 2676 The conference server MAY redirect a CCMP request. A conferencing 2677 client MUST handle redirects, by using the Location header provided 2678 by the server in a 3xx response. When redirecting, the conferencing 2679 client MUST observe the delay indicated by the Retry-After header. 2680 The conferencing client MUST authenticate the server that returns the 2681 redirect response before following the redirect. A conferencing 2682 client SHOULD authenticate the conference server indicated in a 2683 redirect. 2685 The conference server SHOULD support persistent connections and 2686 request pipelining. If pipelining is not supported, the conference 2687 server MUST NOT allow persistent connections. The conference server 2688 MUST support termination of a response by the closing of a 2689 connection. 2691 Implementations of CCMP that implement HTTP transport MUST implement 2692 transport over TLS [RFC2818]. TLS provides message integrity and 2693 confidentiality between the conference control client and the 2694 conference control server. The conferencing client MUST implement 2695 the server authentication method described in HTTPS [RFC2818]. The 2696 device uses the URI obtained during conference server discovery to 2697 authenticate the server. The details of this authentication method 2698 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 2699 the conferencing client SHOULD fail a request if server 2700 authentication fails. 2702 12. Security Considerations 2704 As identified in the XCON framework [RFC5239], there are a wide 2705 variety of potential attacks related to conferencing, due to the 2706 natural involvement of multiple endpoints and the capability to 2707 manipulate the data on the conference server using CCMP. Examples of 2708 attacks include the following: an endpoint attempting to listen to 2709 conferences in which it is not authorized to participate, an endpoint 2710 attempting to disconnect or mute other users, and theft of service by 2711 an endpoint in attempting to create conferences it is not allowed to 2712 create. 2714 The following summarizes the security considerations for CCMP: 2716 1. The client MUST determine the proper conference server. The 2717 conference server discovery is described in . 2719 2. The client MSUT connect to the proper conference server. The 2720 mechanisms for addressing this security consideration are 2721 described in Section 12.1. 2723 3. The protocol MUST support a confidentiality and integrity 2724 mechanism. As described in Section 11, implementations of CCMP 2725 MUST implement the HTTP transport over TLS [RFC2818]. 2727 4. There are security issues associated with the authorization to 2728 perform actions on the conferencing system to invoke specific 2729 capabilities. A conference server SHOULD ensure that only 2730 authorized entities can manipulate the conference data. The 2731 mechanisms for addressing this security consideration are 2732 described in Section 12.2. 2734 5. The privacy and security of the identity of a user in the 2735 conference MUST be assured. The mechanisms to ensure the 2736 security and privacy of identity are discussed in Section 12.3. 2738 6. A final issue is related to Denial of Service (DoS) attacks on 2739 the conferencing server itself. In order to minimize the 2740 potential for DoS attacks, it is RECOMMENDED that conferencing 2741 systems require user authentication and authorization for any 2742 client participating in a conference. This can be accomplished 2743 through the use of the mechanisms described in Section 12.2, as 2744 well as by using the security mechanisms associated with the 2745 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 2747 12.1. Assuring that the Proper Conferencing Server has been contacted 2749 When the CCMP transaction is conducted using TLS [RFC5246], the 2750 conference server can authenticate its identity, either as a domain 2751 name or as an IP address, to the conference client by presenting a 2752 certificate containing that identifier as a subjectAltName (i.e., as 2753 an iPAddress or dNSName, respectively). With the use of HTTP as a 2754 transport for CCMP, this is exactly the authentication described by 2755 TLS [RFC2818]. If the client has external information as to the 2756 expected identity or credentials of the proper conference server 2757 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 2758 implementation of CCMP MUST be capable of being transacted over TLS 2759 so that the client can request the above authentication, and a 2760 conference server implementation MUST include this feature. Note 2761 that in order for the presented certificate to be valid at the 2762 client, the client must be able to validate the certificate. In 2763 particular, the validation path of the certificate must end in one of 2764 the client's trust anchors, even if that trust anchor is the 2765 conference server certificate itself. 2767 12.2. User Authentication and Authorization 2769 Many policy authorization decisions are based on the identity of the 2770 user or the role that a user may have. The conferencing server MUST 2771 implement mechanisms for authentication of users to validate their 2772 identity. There are several ways that a user might authenticate its 2773 identity to the system. For users joining a conference using one of 2774 the call signaling protocols, the user authentication mechanisms for 2775 the specific protocol can be used. For the case of users joining the 2776 conference using the CCMP, TLS is RECOMMENDED. 2778 The XCON Framework [RFC5239] provides an overview of other 2779 authorization mechanisms. In the cases where a user is authorized 2780 via multiple mechanisms, it is RECOMMENDED that the conference server 2781 correlate the authorization of the CCMP interface with other 2782 authorization mechanisms - e.g., PSTN users that join with a PIN and 2783 control the conference using CCMP. When a conference server presents 2784 the identity of authorized users, it MAY provide information about 2785 the way the identity was proven or verified by the system. A 2786 conference server can also allow a completely unauthenticated user 2787 into the system - this information SHOULD also be communicated to 2788 interested parties. 2790 Once a user is authenticated and authorized through the various 2791 mechanisms available on the conference server, the conference server 2792 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 2793 associate the XCON-USERID with any signaling specific user 2794 identifiers that were used for authentication and authorization. 2796 This XCON-USERID can be provided to a specific user through the 2797 conference notification interface and MUST be provided to users that 2798 interact with the conferencing system using the CCMP (i.e., in the 2799 appropriate CCMP response messages). This conference user identifier 2800 is REQUIRED for any subsequent operations on the conference object. 2802 12.3. Security and Privacy of Identity 2804 An overview of the REQUIRED privacy and anonymity for users of a 2805 conferencing system are provided in the XCON Framework [RFC5239]. 2806 The security of the identity in the form of the XCON-USERID is 2807 provided in the CCMP protocol through the use of TLS. 2809 The conference server SHOULD provide mechanisms to ensure the privacy 2810 of the XCON-USERID. This is accomplished by the conference client 2811 manipulation of the "provide-anonymity" element defined in the XCON 2812 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 2813 anonymity" element controls the degree to which a user reveals their 2814 identity. The conference client MUST set the "provide-anonymity" 2815 element to "hidden" if the user does not want other participants to 2816 even be aware that there is an additional participant in the 2817 conference. The conference client MUST set the "provide-anonymity" 2818 field to "private" the user wants to be entirely "anonymous" (i.e., 2819 other participants are aware that there is another participant, but 2820 have no information as to their identity). The conference client 2821 MUST set the "provide-anonymity" field to "semi-private" if their 2822 identity is only to be revealed to other participants or users that 2823 have a higher level authorization (e.g., a conferencing system can be 2824 configured such that an administrator can see all users). To provide 2825 the required privacy, the conference client SHOULD include the 2826 "provide-anonymity" element in the "confInfo" parameter in a CCMP 2827 confRequest message with an "update" or "create" operation or in the 2828 "userInfo" parameter in a CCMP userRequest message with an "update" 2829 or "create" operation, to ensure the user is provided the appropriate 2830 level of privacy. If the "provide-anonymity" element is not included 2831 in the conference object, then other users can see the participant's 2832 identity. 2834 13. XML Schema 2836 This section provides the XML schema definition of the "application/ 2837 ccmp+xml" format. 2839 2840 2849 2852 2856 2857 2859 2861 2862 2863 2865 2866 2868 2870 2871 2872 2874 2875 2877 2878 2880 2881 2883 2885 2887 2889 2890 2892 2893 2894 2895 2896 2897 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2910 2912 2914 2915 2916 2918 2919 2921 2922 2923 2924 2925 2927 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2940 2942 2944 2945 2946 2948 2949 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2962 2964 2966 2967 2968 2970 2971 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2984 2986 2988 2989 2990 2992 2993 2995 2997 2998 2999 3000 3001 3003 3004 3005 3006 3007 3008 3010 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3023 3026 3027 3028 3030 3031 3033 3035 3036 3037 3038 3039 3040 3041 3042 3043 3045 3047 3050 3051 3052 3054 3055 3057 3059 3061 3062 3064 3066 3068 3070 3071 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3084 3086 3089 3090 3091 3093 3094 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3107 3109 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3127 3129 3132 3133 3134 3136 3137 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3150 3152 3154 3155 3156 3158 3159 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3172 3174 3176 3177 3178 3179 3180 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3193 3195 3196 3197 3198 3199 3200 3202 3204 3205 3206 3207 3208 3209 3210 3212 3213 3215 3217 3220 3221 3222 3224 3225 3227 3229 3230 3231 3232 3233 3234 3235 3236 3237 3239 3241 3243 3244 3245 3247 3248 3250 3252 3253 3254 3255 3256 3257 3258 3259 3261 3263 3265 3268 3269 3270 3272 3273 3275 3277 3278 3279 3280 3281 3282 3283 3284 3285 3287 3289 3292 3293 3294 3296 3297 3299 3301 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3324 3326 3327 3328 3329 3330 3331 3332 3333 3334 3336 Figure 25 3338 14. IANA Considerations 3340 This document registers a new XML namespace, a new XML schema, and 3341 the MIME type for the schema. This document also registers the 3342 "XCON" Application Service tag and the "CCMP" Application Protocol 3343 tag. This document also defines registries for the CCMP operation 3344 types and response codes. 3346 14.1. URN Sub-Namespace Registration 3348 This section registers a new XML namespace, 3349 ""urn:ietf:params:xml:ns:xcon:ccmp"". 3351 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 3353 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 3354 Mary Barnes (mary.barnes@nortel.com). 3356 XML: 3358 BEGIN 3359 3360 3362 3363 3364 CCMP Messages 3365 3366 3367

Namespace for CCMP Messages

3368

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

3369 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3370 with the RFC number for this specification.]] 3371

See RFCXXXX.

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