idnits 2.17.1 draft-ietf-xcon-ccmp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 4308, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-20 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4582 (Obsoleted by RFC 8855) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Polycom 4 Intended status: Standards Track C. Boulton 5 Expires: April 29, 2011 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 October 26, 2010 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-11 15 Abstract 17 The Centralized Conferencing Manipulation Protocol (CCMP) allows an 18 XCON conferencing system client to create, retrieve, change, and 19 delete objects that describe a centralized conference. CCMP is a 20 means to control basic and advanced conference features such as 21 conference state and capabilities, participants, relative roles, and 22 details. CCMP is a state-less, XML-based, client server protocol 23 that carries, in its request and response messages, conference 24 information in the form of XML documents and fragments conforming to 25 the centralized conferencing data model schema. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 29, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 3. XCON Conference Control System Architecture . . . . . . . . . 5 64 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7 65 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 68 4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11 69 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 71 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14 72 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 73 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19 74 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21 75 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22 76 5.3.4. confRequest and confResponse . . . . . . . . . . . . 24 77 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28 78 5.3.6. userRequest and userResponse . . . . . . . . . . . . 30 79 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35 80 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37 81 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39 82 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41 83 5.3.11. extendedRequest and extendedResponse . . . . . . . . 44 84 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46 85 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49 86 6. A complete example of the CCMP in action . . . . . . . . . . 52 87 6.1. Alice retrieves the available blueprints . . . . . . . . 53 88 6.2. Alice gets detailed information about a specific 89 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55 90 6.3. Alice creates a new conference through a cloning 91 operation . . . . . . . . . . . . . . . . . . . . . . . . 57 92 6.4. Alice updates conference information . . . . . . . . . . 60 93 6.5. Alice inserts a list of users in the conference object . 62 94 6.6. Alice joins the conference . . . . . . . . . . . . . . . 63 95 6.7. Alice adds a new user to the conference . . . . . . . . . 65 96 6.8. Alice asks for the CCMP server capabilities . . . . . . . 68 97 6.9. Alice exploits a CCMP server extension . . . . . . . . . 70 98 7. Locating a Conference Control Server . . . . . . . . . . . . 73 99 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74 100 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 102 10.1. Assuring that the Proper Conferencing Server has been 103 contacted . . . . . . . . . . . . . . . . . . . . . . . . 78 104 10.2. User Authentication and Authorization . . . . . . . . . . 79 105 10.3. Security and Privacy of Identity . . . . . . . . . . . . 80 106 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80 107 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 108 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98 109 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99 110 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99 111 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100 112 12.4.1. Registration of a Conference Control Server 113 Application Service Tag . . . . . . . . . . . . . . . 100 114 12.4.2. Registration of a Conference Control Server 115 Application Protocol Tag for CCMP . . . . . . . . . . 101 116 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101 117 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101 118 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102 119 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 120 14. Changes since last Version . . . . . . . . . . . . . . . . . 104 121 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 122 15.1. Normative References . . . . . . . . . . . . . . . . . . 105 123 15.2. Informative References . . . . . . . . . . . . . . . . . 106 124 Appendix A. Appendix A: Other protocol models and transports 125 considered for CCMP . . . . . . . . . . . . . . . . 107 126 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 127 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 130 1. Introduction 132 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 133 defines a signaling-agnostic framework, naming conventions and 134 logical entities required for building advanced conferencing systems. 135 The XCON Framework introduces the conference object as a logical 136 representation of a conference instance, representing the current 137 state and capabilities of a conference. 139 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 140 this document allows authenticated and authorized users to create, 141 manipulate and delete conference objects. Operations on conferences 142 include adding and removing participants, changing their roles, as 143 well as adding and removing media streams and associated end points. 145 The CCMP implements the client-server model within the XCON 146 Framework, with the Conference Control Client and Conference Control 147 Server acting as client and server, respectively. The CCMP uses HTTP 148 [RFC2616] as the protocol to transfer requests and responses, which 149 contain the domain-specific XML-encoded data objects defined in 150 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 151 for Centralized Conferencing (XCON Data Model). 153 Section 2 clarifies the conventions and terminology used in the 154 document. Section 3 provides an overview of the Conference Control 155 functionality of the XCON framework, together with a description of 156 the main targets CCMP deals with, namely conference objects and 157 conference users. A general description of the operations associated 158 with protocol messages is given in Section 4 together with 159 implementation details. Section 5 delves into the details of the 160 specific CCMP messages. A complete, not normative, example of the 161 operation of the CCMP, describing a typical call flow associated with 162 conference creation and manipulation, is provided in Section 6. A 163 survey of the methods that can be used to locate a Conference Control 164 Server is provided in Section 7, whereas Section 8 discusses 165 potential approaches to notifications management. CCMP transport 166 over HTTP is highlighted in Section 9. Security considerations are 167 presented in Section 10. Finally, Section 11 provides the XML 168 schema. 170 2. Conventions and Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 In additon to the terms defined in the Framework for Centralized 177 Conferencing [RFC5239], this document uses the following terms and 178 acronyms: 180 XCON aware client: An XCON conferencing system client which is able 181 to issue CCMP requests. 182 First-Party: A request issued by the client to manipulate their own 183 conferencing data. 184 Third-Party: A request issued by a client to manipulate the 185 conference data of another client. 187 3. XCON Conference Control System Architecture 189 CCMP supports the XCON framework . Figure 1 depicts a subset of the 190 "Conferencing System Logical Decomposition" architecture from the 191 XCON framework document. It illustrates the role that CCMP assumes 192 within the overall centralized architecture. 194 ........................................................ 195 . Conferencing System . 196 . . 197 . +---------------------------------------+ . 198 . | C O N F E R E N C E O B J E C T | . 199 . +-+-------------------------------------+ | . 200 . | C O N F E R E N C E O B J E C T | | . 201 . +-+-------------------------------------+ | | . 202 . | C O N F E R E N C E O B J E C T | | | . 203 . | | |-+ . 204 . | |-+ . 205 . +---------------------------------------+ . 206 . ^ . 207 . | . 208 . v . 209 . +-------------------+ . 210 . | Conference Control| . 211 . | Server | . 212 . +-------------------+ . 213 . ^ . 214 .........................|.............................. 215 | 216 |Centralized 217 |Conferencing 218 |Manipulation 219 |Protocol 220 | 221 .........................|.............................. 222 . V . 223 . +----------------+ . 224 . | Conference | . 225 . | Control | . 226 . | Client | . 227 . +----------------+ . 228 . . 229 . Conferencing Client . 230 ........................................................ 232 Figure 1: Conference Client Interaction 234 CCMP serves as the Conference Control Protocol, allowing the 235 conference control client to interface with the conference object 236 maintained by the conferencing system, as represented in Figure 1. 237 Conference Control is one part of functionality for advanced 238 conferencing supported by a conferencing client. Other functions are 239 discussed in the XCON framework and related documents. 241 Conference object and conference users do represent key elements 242 involved in Conference Control Protocol operations. Their 243 identifiers, respectively the conference XCON-URI and the 244 conferencing client XCON-USERID, and their XML representations 245 compliant with the XML Schema defined in the XCON data model are 246 widely used for creating the CCMP requests and responses. The main 247 conference objects and users features envisioned by the XCON 248 framework are briefly described in the following subsections. 250 3.1. Conference Objects 252 Conference objects feature a simple dynamic inheritance-and-override 253 mechanism. Conference objects are linked into a tree known as 254 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 255 node inherits attributes from its parent node. The roots of these 256 inheritance trees are conference templates also known as 257 "blueprints". Nodes in the inheritance tree can be active 258 conferences or simply descriptions that do not currently have any 259 resources associated with them (i.e., conference reservations). An 260 object can mark certain of its properties as unalterable, so that 261 they cannot be overridden. Per the framework, a client may specify a 262 parent object (a conference or blueprint) from which to inherit 263 values when a conference is created using the Conference Control 264 Protocol. 266 Conference objects are uniquely identified by the XCON-URI within the 267 scope of the conferencing system. The XCON-URI is introduced in the 268 XCON framework and defined in the XCON common data model. 270 Conference objects are comprehensively represented through XML 271 documents compliant with the XML Schema defined in the XCON data 272 model [I-D.ietf-xcon-common-data-model]. The root element of such 273 documents, called "", is of type "conference-type". 274 It encompasses other XML elements describing different conference 275 features and users as well. Using the CCMP, conferencing clients can 276 use these XML structures to express their preferences in creating or 277 updating a conference. A conferencing server can convey conference 278 information using the XML elements back to the clients. 280 3.2. Conference Users 282 Each conference can have zero or more users. All conference 283 participants are users, but some users may have only administrative 284 functions and do not contribute or receive media. Users are added 285 one user at a time to simplify error reporting. When a conference is 286 cloned from a parent object, users are inherited as well, so that it 287 is easy to set up a conference that has the same set of participants 288 or a common administrator. The Conference Control Server creates 289 individual users, assigning them a unique Conference User Identifier 290 (XCON-USERID). The XCON-USERID as identifier of each conferencing 291 system client is introduced in the XCON framework and defined in the 292 XCON common data model. Each CCMP request, with an exception pointed 293 out in Section 5.3.6 representing the case of a user at his first 294 entrance in the system as a conference participant, must carry the 295 XCON-USERID of the requestor in the proper "confUserID" parameter. 297 The XCON-USERID acts as a pointer to the user's profile as a 298 conference actor, e.g. her signalling URI and other XCON protocol 299 URIs in general, her role (moderator, participant, observer, etc.), 300 her display text, her joining information and so on. A variety of 301 elements defined in the common element as specified 302 in the XCON data model are used to describe the users related to a 303 conference including the element, as well as each 304 element included within it. For example, it is possible to determine 305 how a specific user expects and is allowed to join a conference by 306 looking at the in : each element 307 involved in such a list represents a user and shows a "method" 308 attribute defining how the user is expected to join the conference, 309 i.e. "dial-in" for users that are allowed to dial, "dial-out" for 310 users that the conference focus will be trying to reach (with 311 "dial-in" being the default mode). If the conference is currently 312 active, dial-out users are contacted immediately; otherwise, they are 313 contacted at the start of the conference. The CCMP, acting as the 314 Conference Control Protocol, provides a means to manipulate these and 315 other kinds of user-related features. 317 As a consequence of an explicit user registration to a specific XCON 318 conferencing system, conferencing clients are usually provided 319 (besides the XCON-USERID) with log-in credentials (i.e. username and 320 password). Such credentials can be used to authenticate the XCON 321 aware client issuing CCMP requests. Thus, both username and password 322 should be carried in a CCMP request as part of the "subject" 323 parameter whenever a registered conferencing client wishes to contact 324 a CCMP server. The CCMP does not maintain user's subscriptions at 325 the conference server; hence, it does not provide any specific 326 mechanism allowing clients to register their conferencing accounts. 327 The "subject" parameter is just used for carrying authentication data 328 associated with pre-registered clients, with the specific 329 registration modality outside the scope of this document. 331 4. Protocol Overview 333 CCMP is a client-server, XML-based protocol, which has been 334 specifically conceived to provide users with the necessary means for 335 the creation, retrieval, modification and deletion of conference 336 objects. CCMP is also state-less, which means implementations can 337 safely handle transactions independently from each other. 338 Conference-related information is encapsulated into CCMP messages in 339 the form of XML documents or XML document fragments compliant with 340 the XCON data model representation. 342 Section 4.1 specifies the basic operations that can create, retrieve, 343 modify and delete conference-related information in a centralized 344 conference. The core set of objects manipulated in the CCMP protocol 345 includes conference blueprints, the conference object, users, and 346 sidebars. 348 CCMP has been conceived as completely independent from underlying 349 protocols, which means that there can be different ways to carry CCMP 350 messages across the network, from a conferencing client to a 351 conferencing server. The specification recommends the use of HTTP as 352 a transport solution, including CCMP requests in HTTP POST messages 353 and CCMP responses in HTTP 200 OK replies. Implementation details 354 are presented in Section 4.2 356 4.1. Protocol Operations 358 The main operations provided by CCMP belong in four general 359 categories: 361 create: for the creation of a conference, a conference user, a 362 sidebar, or a blueprint. 363 retrieve: to get information about the current state of either a 364 conference object (be it an actual conference or a blueprint, or a 365 sidebar) or a conference user. A retrieve operation can also be 366 used to obtain the XCON-URIs of the current conferences (active or 367 registered) handled by the conferencing server and/or the 368 available blueprints. 369 update: to modify the current features of a specified conference or 370 conference user. 371 delete: to remove from the system a conference object or a 372 conference user. 374 Thus, the main targets of CCMP operations are: 376 o conference objects associated with either active or registered 377 conferences, 378 o conference objects associated with blueprints, 379 o conference objects associated with sidebars, both embedded in the 380 main conference (i.e. elements in ) and 381 external to it (i.e. whose xcon-uris are included in the 382 elements of ), 384 o elements associated with conference users, 385 o the list of XCON-URIs related to conferences and blueprints 386 available at the server, for which only retrieval operations are 387 allowed. 389 Each operation in the protocol model is atomic and either succeeds or 390 fails as a whole. The conference server must ensure that the 391 operations are atomic in that the operation invoked by a specific 392 conference client completes prior to another client's operation on 393 the same conference object. The details for this data locking 394 functionality are out of scope for the CCMP protocol specification 395 and are implementation specific for a conference server. Thus, the 396 conference server first checks all the parameters, before making any 397 changes to the internal representation of the conference object. For 398 example, it would be undesirable to change the of the 399 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 401 can modify the same conference objects, conference clients should 402 first obtain the current object from the conference server and then 403 update the relevant data elements in the conference object prior to 404 invoking a specific operation on the conference server. In order to 405 effectively manage modifications to conference data, a versioning 406 approach is provided by the CCMP. Specifically, each conference 407 object is associated with a version number indicating the most up to 408 date view of the conference at the server's side. The version number 409 is reported to the clients when answering their requests. A client 410 willing to make modifications to a conference object has to send an 411 update message to the server. If the modifications are all 412 successfully applied, the server sends back to the client a "200" 413 response which also carries information about the current server-side 414 version of the modified object. With this approach, a client working 415 on version "X" of a conference object that finds a "200" response 416 with a version number which is "X+1" can be sure that the version it 417 was aware of was the most up to date. On the other hand, if the 418 "200" response contains a version which is at least "X+2", the client 419 can detect that the object that has been modified at the server's 420 side was more up to date than the one it was working upon. This is 421 clearly due to the effect of concurrent modification requests issued 422 by independent clients. Hence, for the sake of having available the 423 latest version of the modified object, the client can send to the 424 conference server a further "retrieve" request. In the case that a 425 copy of the conference object is not returned to the client as part 426 of the update response message, the client can always obtain a copy 427 through an ad-hoc "retrieve" message. 429 Based on the above considerations, all CCMP response messages 430 containing a conference document (or a fragment of it) MUST contain a 431 "version" parameter. The "version" parameter is not REQUIRED for 432 requests, since it represents useless information for the server: as 433 long as the required modifications can be applied to the target 434 conference object with no conflicts, the server does not care whether 435 the client has stored an up to date view of the information. 436 However, a client subscribed to the XCON event package 437 [I-D.ietf-xcon-event-package] notifications about conference object 438 modifications, will always have the most up to date version of that 439 object. 441 A final consideration concerns the relation between the CCMP and the 442 main entities it manages, i.e. conference objects. Such objects have 443 to be compliant with the XCON data-model, which identifies some 444 elements/attributes as mandatory. From the CCMP standpoint this can 445 become a problem in cases of client-initiated operations, like the 446 creation/update of conference objects. In such cases, not all of the 447 mandatory data can be known in advance to the client issuing a CCMP 448 request. As an example, a client has no means to know, at the time 449 it issues a conference creation request, the XCON-URI that the server 450 will assign to the yet-to-be-created conference and hence it is not 451 able to appropriately fill with that value the mandatory "entity" 452 attribute of the conference document contained in the request. To 453 solve this kind of issues, the CCMP will fill all mandatory data 454 model fields, for which no value is available at the client at the 455 time the request is constructed, with fake values in the form of 456 wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental 457 index initialized to a value of 1). Upon reception of the mentioned 458 kinds of requests, the server will: (i) generate the proper 459 identifier(s); (ii) produce a response in which the received fake 460 identifier(s) carried in the request has (have) been replaced by the 461 newly created one(s). With this approach we maintain compatibility 462 with the data model requirements, at the same time allowing for 463 client-initiated manipulation of conference objects at the server's 464 side (which is, by the way, one of the main goals for which the CCMP 465 protocol has been conceived at the outset). 467 4.2. Implementation Approach 469 There have been a number of different proposals as to the most 470 suitable implementation solution for the CCMP. A non-exhaustive 471 summary of the most interesting ones is provided in Appendix A. The 472 solution for the CCMP defined in this document is viewed as a good 473 compromise amongst the most notable past candidates and is referred 474 to as "HTTP single-verb transport plus CCMP body". With this 475 approach, CCMP is able to take advantage of existing HTTP 476 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 477 transport (i.e. a single transaction type for each request/response 478 pair); this allows decoupling CCMP messages from HTTP messages. 479 Similarly, as with any RESTful approach, CCMP messages are inserted 480 directly in the body of HTTP messages, thus avoiding any unnecessary 481 processing and communication burden associated with further 482 intermediaries. With this approach, no modification to the CCMP 483 messages/operations is required to use a different transport 484 protocol. 486 The remainder of this document focuses on the selected approach. The 487 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 488 POST operations and retrieves responses from the body of HTTP "200 489 OK" messages. CCMP messages have a MIME-type of "application/ 490 ccmp+xml", which appears inside the "Content-Type" and "Accept" 491 fields of HTTP requests and responses. The XML documents in the CCMP 492 messages MUST be encoded in UTF-8. This specification follows the 493 recommendations and conventions described in [RFC3023], including the 494 naming convention of the type ('+xml' suffix) and the usage of the 495 'charset' parameter. The 'charset' parameter MUST be included with 496 the XML document. Section 9 provides the complete requirements for 497 an HTTP implementation to support the CCMP. 499 5. CCMP messages 501 CCMP messages are either requests or responses. The general CCMP 502 request message is defined in Section 5.1. The general CCMP response 503 message is defined in Section 5.2. The details of the specific 504 message type which is carried in the CCMP request and response 505 messages are described in Section 5.3. CCMP response codes are 506 listed in Section 5.4 508 5.1. CCMP Request Message Type 510 A CCMP request message is comprised of the following parameters: 512 subject: An optional parameter containing username and password of 513 the client registered at the conferencing system. Each user who 514 subscribes to the conferencing system is assumed to be equipped 515 with those credentials and SHOULD enclose them in each CCMP 516 request she issues. These fields can be used to control that the 517 user sending the CCMP request has the authority to perform the 518 entailed operation. The same fields can also be exploited to 519 carry out other Authorization, Authentication and Accounting (AAA) 520 procedures. 521 confUserID: An optional parameter containing the XCON-USERID of the 522 client. The XCON-USERID is used to identify any conferencing 523 client within the context of the conferencing system and it is 524 assinged by the conferencing server at each conferencing client 525 who interacts with it. The "confUserID" parameter is REQUIRED in 526 the CCMP request and response messages with the exception of the 527 case of a user who has no XCON-USERID and who wants to enter, via 528 CCMP, a conference whose identifier is known. In such case, a 529 side-effect of the request is that the user is provided with an 530 appropriate XCON-USERID. An example of the above mentioned case 531 will be provided in Section 5.3.6. 532 confObjID: An optional parameter containing the XCON-URI of the 533 target conference object. 534 operation: An optional parameter refining the type of specialized 535 request message. The "operation" parameter is REQUIRED in all 536 requests except for the "blueprintsRequest" and "confsRequest" 537 specialized messages. 538 conference-password: An optional parameter that MUST be inserted in 539 all requests whose target conference object is password-protected 540 (as per the element in 541 [I-D.ietf-xcon-common-data-model]). 542 specialized request message: This is specialization of the generic 543 request message (e.g., blueprintsRequest), containing parameters 544 that are dependent on the specific request sent to the server. A 545 specialized request message MUST be included in the CCMP request 546 message. The details for the specialized messages and associated 547 parameters are provided in Section 5.3. 549 551 553 555 556 557 559 560 562 564 566 567 569 571 573 575 577 579 580 581 583 Figure 2: Structure of CCMP Request messages 585 5.2. CCMP Response Message Type 587 A CCMP response message is comprised of the following parameters: 589 confUserID: A mandatory parameter in CCMP response messages 590 containing the XCON-USERID of the conferencing client who issued 591 the CCMP request message. 593 confObjID: An optional parameter containing the XCON-URI of the 594 target conference object. 595 operation: An optional parameter for CCMP response messages. This 596 parameter is REQUIRED in all responses except for the 597 "blueprintsResponse" and "confsResponse" specialized messages. 598 response-code: A mandatory parameter containing the response code 599 associated with the request. The response code MUST be chosen 600 from the codes listed in Section 5.4. 601 response-string: An optional reason string associated with the 602 response. In case of an error, in particular, such string can be 603 used to provide the client with detailed information about the 604 error itself. 605 version: An optional parameter reflecting the current version number 606 of the conference object referred by the confObjID. This number 607 is contained in the "version" attribute of the 608 element related to that conference. 609 specialized response message: This is specialization of the generic 610 response message, containing parameters that are dependent on the 611 specific request sent to the server (e.g., blueprintsResponse). A 612 specialized response message SHOULD be included in the CCMP 613 response message, except in an error situation where the CCMP 614 request message did not contain a valid specialized message. In 615 this case, the conference server MUST return a "response-code" of 616 "400". The details for the specialized messages and associated 617 parameters are provided in Section 5.3. 619 621 623 625 626 627 629 630 632 634 636 637 639 641 643 646 648 650 652 653 654 656 Figure 3: Structure of CCMP Response message 658 5.3. Detailed messages 660 Based on the request and response message structures described in 661 Section 5.1 and Section 5.2, the following summarizes the specialized 662 CCMP request/response types described in this document: 664 1. blueprintsRequest/blueprintsResponse 665 2. confsRequest/confsResponse 666 3. blueprintRequest/blueprintResponse 667 4. confRequest/confResponse 668 5. usersRequest/usersResponse 669 6. userRequest/userResponse 670 7. sidebarsByValRequest/sidebarsByValResponse 671 8. sidebarsByRefRequest/sidebarsByRefResponse 672 9. sidebarByValRequest/sidebarByValResponse 673 10. sidebarByRefRequest/sidebarByRefResponse 674 11. extendedRequest/extendedResponse 675 12. optionsRequest/optionsResponse 677 These CCMP request/response pairs use the fundamental CCMP operations 678 as defined in Section 4.1 to manipulate the conference data. The 679 optionsRequest/optionsResponse message pair deserves a specific 680 discussion, since it is not used for manipulating information about 681 either conferences or conference users, but rather to retrieve 682 general information about conference server capabilities, in terms of 683 standard CCMP messages it supports, plus potential extension messages 684 it understands, as it will be further explained in Section 5.3.12. 685 Table 1 summarizes the remaining CCMP operations and corresponding 686 actions that are valid for a specific CCMP request type, noting that 687 neither the blueprintsRequest/blueprintsResponse nor confsRequest/ 688 confsResponse require an "operation" parameter. The corresponding 689 response MUST contain the same operation. Note that some entries are 690 labeled "N/A" indicating the operation is invalid for that request 691 type. In the case of an "N/A*", the operation MAY be allowed for 692 specific privileged users or system administrators, but is not part 693 of the functionality included in this document. 695 +---------------+------------+------------+------------+------------+ 696 | Operation | Retrieve | Create | Update | Delete | 697 | ------------- | | | | | 698 | Request Type | | | | | 699 +---------------+------------+------------+------------+------------+ 700 | blueprints | Get list | N/A | N/A | N/A | 701 | Request | of | | | | 702 | | blueprints | | | | 703 | ------------- | ---------- | ---------- | ---------- | ---------- | 704 | blueprint | Get | N/A* | N/A* | N/A* | 705 | Request | blueprint | | | | 706 | ------------- | ---------- | ---------- | ---------- | ---------- | 707 | confsRequest | Get list | N/A | N/A | N/A | 708 | | of confs | | | | 709 | ------------- | ---------- | ---------- | ---------- | ---------- | 710 | confRequest | Gets | Creates | Changes | Deletes | 711 | | conference | conference | conference | conference | 712 | | object | object | object | object | 713 | ------------- | ---------- | ---------- | ---------- | ---------- | 714 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 715 | | | | | | 716 | ------------- | ---------- | ---------- | ---------- | ---------- | 717 | userRequest | Gets | Adds a | Changes | Deletes | 718 | | specified | to | specified | specified | 719 | | | a conf | | | 720 | | | (***) | | | 721 | ------------- | ---------- | ---------- | ---------- | ---------- | 722 | sidebarsByVal | Gets | N/A | N/A | N/A | 723 | Request | | | | | 725 | ------------- | ---------- | ---------- | ---------- | ---------- | 726 | sidebarsByRef | Gets | N/A | N/A | N/A | 727 | Request | | | | | 729 | ------------- | ---------- | ---------- | ---------- | ---------- | 730 | sidebarByVal | Gets | Creates | Changes | Deletes | 731 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 732 | | by-val | by-val | by-val | by-val | 733 | ------------- | ---------- | ---------- | ---------- | ---------- | 734 | sidebarByRef | Gets | Creates | Changes | Deletes | 735 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 736 | | by-ref | by-ref | by-ref | by-ref | 737 +---------------+------------+------------+------------+------------+ 739 Table 1: Request Type Operation Specific Processing 741 (**): These operations are not allowed for a usersRequest message, 742 since the section, which is the target element of such a 743 request, is created and removed in conjuntcion with, respectively, 744 the creation and deletion of the associated conference document. 745 Thus, "update" and "retrieve" are the only semantically correct 746 operations for such message. 748 (***): This operation can involve the creation of an XCON-USERID, if 749 the sender does not add it in the "confUserID" parameter, and/or if 750 the "entity" field of the "userInfo" parameter is void. 752 Additional parameters included in the specialized CCMP request/ 753 response messages are detailed in the subsequent sections. If a 754 required parameter is not included in a request, the conference 755 server MUST return a 400 response code per Section 5.4. 757 5.3.1. blueprintsRequest and blueprintsResponse 759 A "blueprintsRequest" (Figure 4) message is sent to request the list 760 of XCON-URIs associated with the available blueprints from the 761 conference server. Such URIs can be subsequently used by the client 762 to access detailed information about a specified blueprint with a 763 specific blueprintRequest message per Section 5.3.3. The 764 "confUserID" parameter MUST be included in every blueprintsRequest/ 765 Response message and reflect the XCON-USERID of the conferencing 766 client issuing the request. A blueprintsRequest message REQUIRES no 767 "confObjID" and "operation" parameters, since it is not targetted to 768 a specific conference instance and it is conceived as a "retrieve- 769 only" request. In order to obtain a specific subset of the available 770 blueprints, a client may specify a selection filter providing an 771 appropriate xpath query in the optional "xpathFilter" parameter of 772 the request. For example, to select blueprints having both audio and 773 video stream support, a possible xpathFilter value could be: "/ 774 conference-info[conference-description/available-media/entry/ 775 type='audio' and conference-description/available-media/entry/ 776 type='video']". 778 The associated "blueprintsResponse" message SHOULD contain, as shown 779 in Figure 4, a "blueprintsInfo" parameter containing the above 780 mentioned XCON-URI list. 782 784 785 786 787 788 790 791 792 793 795 797 799 800 801 802 804 805 806 808 810 811 812 813 814 815 816 817 818 820 822 824 825 826 828 830 831 832 834 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 835 messages 837 5.3.2. confsRequest and confsResponse 839 A "confsRequest" message is used to retrieve, from the server, the 840 list of XCON-URIs associated with active and registered conferences 841 currently handled by the conferencing system. The "confUserID" 842 parameter MUST be included in every confsRequest/Response message and 843 reflect the XCON-USERID of the conferencing client issuing the 844 request. The "confObjID" parameter MUST NOT be included in the 845 confsRequest message. The "confsRequest" message is of a "retrieve- 846 only" type, since the sole purpose is to collect information 847 available at the conference server. Thus, an "operation" parameter 848 MUST NOT be included in a "confsRequest" message. In order to 849 retrieve a specific subset of the available conferences, a client may 850 specify a selection filter providing an appropriate xpath query in 851 the optional "xpathFilter" parameter of the request. For example, to 852 select only the registered conferences, a possible xpathFilter value 853 could be: "/conference-info[conference-description/conference-state/ 854 active='false']". The associated "confsResponse" message SHOULD 855 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 856 upon receipt of the response message, can interact with the available 857 conference objects through further CCMP messages. 859 861 862 863 864 865 866 867 868 869 871 873 875 876 877 878 880 881 882 883 885 886 887 888 889 890 891 892 893 895 897 899 900 901 903 905 906 907 909 Figure 5: Structure of the confsRequest and confsResponse messages 911 5.3.3. blueprintRequest and blueprintResponse 913 Through a "blueprintRequest", a client can manipulate the conference 914 object associated with a specified blueprint. Further than the 915 "confUserID" parameter, the request MUST include the "confObjID" and 916 the "operation" one. Again, the "confUserID" parameter MUST be 917 included in every blueprintRequest/Response message and reflect the 918 XCON-USERID of the conferencing client issuing the request. The 919 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 920 which might have been previously retrieved through a 921 "blueprintsRequest" message. 923 The blueprintRequest message SHOULD NOT contain an "operation" 924 parameter other than "retrieve". The "create", "update" and "delete" 925 operations SHOULD NOT be included in a "blueprintRequest" message 926 except in the case of privileged users (e.g. the conference server 927 administration staff), who might authenticate themselves by the mean 928 of the "subject" request parameter. 930 A blueprintRequest/retrieve carrying a "confObjID" which is not 931 associated with one of the available system's blueprints will 932 generate, on the server's side, a blueprintResponse message 933 containing a "404" error code. This holds also for the case in which 934 the mentioned "confObjID" is related to an existing conference 935 document stored at the server, but associated with an actual 936 conference (be it active or registered) or with a sidebar rather than 937 a blueprint. 939 In the case of "response-code" of "200" for a "retrieve" operation, 940 the "blueprintInfo" parameter MUST be included in the 941 "blueprintResponse" message. The "blueprintInfo" parameter contains 942 the conference document associated with the blueprint as identified 943 by the "confObjID" parameter specified in the blueprintRequest. 945 947 948 949 950 951 952 953 954 955 957 959 961 962 963 965 967 968 969 971 973 974 975 976 977 978 979 980 981 983 985 987 988 989 991 993 994 995 997 Figure 6: Structure of the blueprintRequest and blueprintResponse 998 messages 1000 5.3.4. confRequest and confResponse 1002 With a "confRequest" message, CCMP clients can manipulate conference 1003 objects associated with either active or registered conferences. The 1004 "confUserID" parameter MUST be included in every confRequest/Response 1005 message and reflect the XCON-USERID of the conferencing client 1006 issuing the request. ConfRequest and confResponse messages MUST also 1007 include an "operation" parameter. ConfResponse messages MUST return 1008 to the requestor a "response-code" and MAY contain a "response- 1009 string" explaining it. Depending upon the type of "operation", a 1010 "confObjID" and "confInfo" parameter MAY be included in the 1011 confRequest and response. The requirements for inclusion of 1012 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1013 messages and are detailed below for each "operation" case. 1015 The creation case deserves care. To create a new conference through 1016 a "confRequest" message, two approaches can be considered: 1018 1. Creation through explicit cloning: the "confObjID" parameter MUST 1019 contain the XCON-URI of the blueprint or of the conference to be 1020 cloned, while the "confInfo" parameter MUST NOT be included in 1021 the confRequest. Note that cloning of an active conference is 1022 only done in the case of a sidebar operation per the XCON 1023 framework and as described in Section 5.3.8. 1024 2. Creation through implicit cloning (also known as "direct 1025 creation"): the "confObjID" parameter MUST NOT be included in the 1026 request and the CCMP client can describe the desired conference 1027 to be created using the "confInfo" parameter. If no "confInfo" 1028 parameter is provided in the request, the new conference will be 1029 created as a clone of the system default blueprint. 1031 In both creation cases, the confResponse, for a successful completion 1032 of a "create" operation, contains a response-code of "200" and MUST 1033 contain the XCON-URI of the newly created conference in the 1034 "confObjID" parameter, in order to allow the conferencing client to 1035 manipulate that conference through following CCMP requests. In 1036 addition, the "confInfo" parameter transporting the created 1037 conference document MAY be included, at the discretion of the 1038 conferencing system implementation, along with an optional version 1039 parameter initialized at "1", since at creation time the conference 1040 object is at its first version. 1042 In the case of a confRequest with a "retrieve" operation, the 1043 "confObjID" representing the XCON-URI of the target conference MUST 1044 be included and the "confInfo" parameter MUST NOT be included in the 1045 request. The conferencing server MUST ignore any "confInfo" 1046 parameter that is received in a confRequest/retrieve. If the 1047 confResponse for the "retrieve" operation contains a "response-code" 1048 of "200", the "confInfo" parameter MUST be included in the response. 1049 The "confInfo" parameter MUST contain the entire conference document 1050 describing the target conference object in its current state. The 1051 current state of the retrieved conference object MUST also be 1052 reported in the proper "version" response parameter. 1054 In case of a confRequest with an "update" operation, the "confInfo" 1055 and "confObjID" MUST be included in the request. The "confInfo" 1056 represents an object of type "conference-type" containing all the 1057 changes to be applied to the conference whose identifier is 1058 "confObjID". Note that, in such a case, though the confInfo 1059 parameter has indeed to follow the rules indicated in the XCON data 1060 model, it does not represent the entire updated version of the target 1061 conference, since it rather conveys just the modifications to apply 1062 to that conference. For example, in order to change the conference 1063 title, the confInfo parameter will be of the form: 1065 1066 1067 *** NEW CONFERENCE TITLE *** 1068 1069 1071 Figure 7: Updating a conference object: modifying the title of a 1072 conference 1074 Similarly, to remove the title of an existing conference, a 1075 confRequest/update carrying the following "confInfo" parameter would 1076 do the job.: 1078 1079 1080 1081 1082 1084 Figure 8: Updating a conference object: removing the title of a 1085 conference 1087 In the case of a confResponse/update with a response-code of "200", 1088 no additional information is required in the response message, which 1089 means the return of confInfo parameter is not mandatory. A following 1090 confRequest/retrieve transaction might provide the CCMP client with 1091 the current aspect of the conference upon the modification, or the 1092 Notification Protocol might address that task as well. A "200" 1093 response-code indicates that the referenced conference document has 1094 been changed accordingly to the request by the conferencing server. 1095 The "version" parameter MUST be enclosed in the confResponse/update 1096 message, in order to let the client understand what is the actual 1097 current conference-object version, upon the applied modifications. 1098 An "409" response-code indicates that the changes reflected in the 1099 request "confInfo" are not feasible. This could be due to policies, 1100 requestor roles, specific privileges, unacceptable values etc., with 1101 the reason specific to a conferencing system and its configuration. 1102 Together with the "409" response-code, the "version" parameter MUST 1103 be attached in the confResponse/update, by this way allowing the 1104 client to eventually retrieve the current version of the target 1105 conference if the one she attempted to modify was not the most up-to- 1106 date. 1108 In the case of a confRequest with a "delete" operation, the 1109 "confObjID" representing the XCON-URI of the target conference MUST 1110 be included while the "confInfo" MUST NOT be included in the request. 1111 The conferencing server MUST ignore any "confInfo" parameter that is 1112 received within such a request. The confResponse MUST contain the 1113 same "confObjID" that was included in the confRequest. If the 1114 confResponse/delete operation contains a "200" response-code, the 1115 conference indicated in the "confObjID" has been successfully 1116 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1117 parameter. The "version" parameter SHOULD NOT be returned in any 1118 confResponse/delete. If the conferencing server cannot delete the 1119 conference referenced by the "confObjID" received in the confRequest 1120 because it is the parent of another conference object that is in use, 1121 the conferencing server MUST return a response-code of "425". 1123 A confRequest with an "operation" of "retrieve", "update" or "delete" 1124 carrying a "confObjID" which is not associated with one of the 1125 conferences (active or registered) the system is holding will 1126 generate, on the server's side, a confResponse message containing a 1127 "404" error code. This holds also for the case in which the 1128 mentioned "confObjID" is related to an existing conference object 1129 stored at the server, but associated with a blueprint or with a 1130 sidebar rather than an actual conference. 1132 The schema for the confRequest/confResponse pair is shown in 1133 Figure 9. 1135 1137 1138 1139 1140 1141 1142 1143 1144 1145 1147 1149 1151 1152 1153 1155 1157 1158 1159 1161 1163 1164 1165 1166 1167 1168 1169 1170 1171 1173 1175 1177 1178 1179 1181 1183 1184 1185 1187 Figure 9: Structure of the confRequest and confResponse messages 1189 5.3.5. usersRequest and usersResponse 1191 Through a "usersRequest" message the CCMP client manipulates the XML 1192 element of the conference document associated with the 1193 conference identified by the "confObjID" parameter complusory 1194 included in the request. Inside the element, along with the 1195 list of elements associated with conference participants, 1196 there is information that the client may be interested in 1197 controlling, such the list of the users to which access to the 1198 conference is allowed/denied, conference participation policies, 1199 etc.; for this reason, a customized message has been designed to 1200 allow for the manipulation of this specific part of a conference 1201 document. 1203 A "usersInfo" parameter MAY be included in a usersRequest message 1204 depending upon the operation. If the "usersInfo" parameter is 1205 included in the usersRequest message, the parameter MUST be compliant 1206 with the field of the XCON data model. 1208 Two operations are allowed for a "usersRequest" message: 1209 1. "retrieve": In this case the request MUST NOT include a 1210 "usersInfo" parameter, while the successful response MUST contain 1211 the desired element in the "usersInfo" parameter. The 1212 conference server MUST ignore a "usersInfo" parameter if it is 1213 received in a request with a "retrieve" operation. 1214 2. update: In this case, the "usersInfo" parameter MUST contain the 1215 modifications to be applied to the referred element. If 1216 the "response-code" is "200", then the "usersInfo" parameter 1217 SHOULD NOT be returned. Any "usersInfo" parameter that is 1218 returned SHOULD be ignored. A "response-code" of "426" indicates 1219 that the conferencing client is not allowed to make the changes 1220 reflected in the "usersInfo" contained in the usersRequest 1221 message. This could be due to policies, roles, specific 1222 privileges, etc., with the reason specific to a conferencing 1223 system and its configuration. 1225 Operations of "create" and "delete" are not applicable to a 1226 usersRequest message and MUST NOT be considered by the server, which 1227 means that a "response-code" of "403" MUST be included in the 1228 usersResponse message. 1230 1232 1233 1234 1235 1236 1237 1238 1239 1240 1242 1244 1246 1247 1248 1250 1252 1253 1254 1256 1258 1259 1260 1261 1262 1263 1264 1265 1266 1268 1270 1272 1273 1274 1276 1278 1279 1280 1282 Figure 10: Structure of the usersRequest and usersResponse messages 1284 5.3.6. userRequest and userResponse 1286 A "userRequest" message is used to manipulate elements inside 1287 a conference document associated with a conference identified by the 1288 "confObjID" parameter. Besides retrieving information about a 1289 specific conference user, the message is used to request that the 1290 conference server either create, modify, or delete information about 1291 a user. A "userRequest" message MUST include the "confObjID", the 1292 "operation" parameter, and MAY include a "userInfo" parameter 1293 containing the detailed user's information depending upon the 1294 operation and whether the "userInfo" has already been populated for a 1295 specific user. Note that a user may not necessarily be a 1296 conferencing control client (i.e., some participants in a conference 1297 are not "XCON aware"). 1299 An XCON-USERID SHOULD be assigned to each and every user subscribed 1300 to the system. In such a way, a user who is not a conference 1301 participant can make requests (provided she has successfully passed 1302 AAA checks), like creating a conference, retrieving conference 1303 information, etc.. 1305 Conference users can be created in a number of different ways. In 1306 each of these cases the operation MUST be set to "create" in the 1307 userRequest message. Each of the userResponse messages for these 1308 cases MUST include the "confObjID", "confUserID", "operation" and 1309 "response-code" parameters. In the case of a response code of "200", 1310 the userResponse message MAY include the "userInfo" parameter 1311 depending upon the manner in which the user was created: 1313 o Conferencing client with an XCON-USERID adds itself to the 1314 conference: In this case, the "userInfo" parameter MAY be included 1315 in the userRequest. The "userInfo" parameter MUST contain a 1316 element (compliant with the XCON data model) and the 1317 "entity" attribute MUST be set to a value which represents the 1318 XCON-USERID of the user initiating the request. No additional 1319 parameters beyond those previously described are required in the 1320 userResponse message, in the case of a "response-code" of "200". 1321 o Conferencing client acts on behalf of a third user whose XCON- 1322 USERID is known: in this case, the "userInfo" parameter MUST be 1323 included in the userRequest. The "userInfo" parameter MUST 1324 contain a element and the "entity" attribute value MUST be 1325 set to the XCON-USERID of the third user in question. No 1326 additional parameters beyond those previously described are 1327 required in the userResponse message, in the case of a "response- 1328 code" of "200". 1329 o A conferencing client who has no XCON-USERID and who wants to 1330 enter, via CCMP, a conference whose identifier is known. In such 1331 case, a side-effect of the request is that the user is provided 1332 with a new XCON-USERID (created by the server) carried inside the 1333 "confUserID" parameter of the response. This is the only case in 1334 which a CCMP request can be valid though carrying a void 1335 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1336 in the request, providing at least a contact URI of the joining 1337 client, in order to let the focus instigate the signaling phase 1338 needed to add her to the conference. The mandatory "entity" 1339 attribute of the "userInfo" parameter in the request is filled 1340 with a dummy value recognizable on the server side, so to conform 1341 to the rules contained in the XCON data model XML schema. The 1342 involved messages (userRequest and userResponse) in such case 1343 should look like the following: 1345 Request fields: 1347 confUserID=null; 1348 confObjID=confXYZ; 1349 operation=create; 1350 userInfo= 1352 1353 1354 ... 1356 Response fields (in case of success): 1358 confUserID=user345; 1359 confObjID=confXYZ; 1360 operation=create; 1361 response-code=200; 1362 userInfo=null; //or the entire userInfo object 1364 Figure 11: userRequest and userResponse in the absence of an xcon- 1365 userid 1367 o Conferencing client is unaware of the XCON-USERID of a third user: 1368 In this case, the XCON-USERID in the request "confUserID" is the 1369 sender's one and the "entity" attribute of the attached userInfo 1370 is filled with the pre-defined fake value 1371 "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the 1372 third user MUST be returned to the client issuing the request in 1373 the "entity" attribute of the response "userInfo" parameter, if 1374 the "response-code" is "200". This scenario is intended to 1375 support both the case where a brand new conferencing system user 1376 is added to a conference by a third party (i.e. a user who is not 1377 yet provided with an XCON-USERID) and the case where the CCMP 1378 client issuing the request does not know the to-be-added user's 1379 XCON-USERID (which means such an identifier could already exist on 1380 the server's side for that user). In this last case, the 1381 conferencing server is in charge of avoiding XCON-URI duplicates 1382 for the same conferencing client, looking at key fields in the 1383 request provided "userInfo" parameter, such as the signalling URI: 1385 if the joining user is a brand new one, then the generation of a 1386 new XCON identifier is needed; otherwise, if that user is an 1387 existing one, the server must recover the corresponding XCON 1388 identifier. 1390 In the case of a userRequest with a "retrieve" operation, the 1391 "confObjID" representing the XCON-URI of the target conference MUST 1392 be included. The "confUserID", containing the CCMP client's xcon- 1393 userid, MUST also be included in the userRequest message. If the 1394 client wants to retrieve information about her profile in the 1395 specified conference, no "userInfo" parameter is needed in the 1396 retrieve request. On the other hand, if the client wants to obtain 1397 someone else's info within the given conference, she MUST include in 1398 the userRequest/retrieve a "userInfo" parameter whose "entity" 1399 attribute conveys the desired user's xcon-userid. If the 1400 userResponse for the "retrieve" operation contains a "response-code" 1401 of "200", the "userInfo" parameter MUST be included in the response. 1403 In case of a userRequest with an "update" operation, the "confObjID", 1404 "confUserID" and "userInfo" MUST be included in the request. The 1405 "userInfo" is of type "user-type" and contains all the changes to be 1406 applied to a specific element in the conference object 1407 identified by the "confObjID" in the userRequest message. The user 1408 to be modified is identified through the "entity" attribute of the 1409 "userInfo" parameter included in the request. In the case of a 1410 userResponse with a "response-code" of "200", no additional 1411 information is required in the "userResponse" message. A "response- 1412 code" of "200" indicates that the referenced user element has been 1413 updated by the conference server. A "response-code" of "426" 1414 indicates that the conferencing client is not allowed to make the 1415 changes reflected in the "userInfo" in the initial request. This 1416 could be due to policies, roles, specific privileges, etc., with the 1417 reason specific to a conferencing system and its configuration. 1419 In the case of a userRequest with a "delete" operation, the 1420 "confObjID" representing the XCON-URI of the target conference MUST 1421 be included. The "confUserID", containing the CCMP client's xcon- 1422 userid, MUST be included in the userRequest message. If the client 1423 wants to exit the specified conference, no "userInfo" parameter is 1424 needed in the delete request. On the other hand, if the client wants 1425 to remove another participant from the given conference, she MUST 1426 include in the userRequest/delete a "userInfo" parameter whose 1427 "entity" attribute conveys the xcon-userid of that participant. The 1428 userResponse MUST contain the same "confObjID" that was included in 1429 the userRequest. The userResponse MUST contain a "response-code" of 1430 "200" if the target element has been successfully deleted. If 1431 the userResponse for the "delete" operation contains a "response- 1432 code" of "200", the userResponse MUST NOT contain the "userInfo" 1433 parameter. 1435 1437 1438 1439 1440 1441 1442 1443 1444 1445 1447 1449 1451 1452 1453 1455 1457 1458 1459 1461 1463 1464 1465 1466 1467 1468 1469 1470 1471 1473 1475 1477 1478 1479 1481 1483 1484 1485 1487 Figure 12: Structure of the userRequest and userResponse messages 1489 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1491 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1492 on the field of the conference object represented 1493 by the "confObjID". The "sidebarsByValRequest" message is of a 1494 "retrieve-only" type, so an "operation" parameter MUST NOT be 1495 included in a "sidebarsByValRequest" message. As with blueprints and 1496 conferences, also with sidebars, CCMP allows for the use of xpath 1497 filters whenever a selected subset of the sidebars available at the 1498 server's side has to be retrieved by the client. This applies both 1499 to sidebars by reference and to sidebars by value. A 1500 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1501 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1503 the client a "version" element related to the current version of the 1504 main conference object (i.e. the one whose identifier is contained in 1505 the "confObjId" field of the request) to which the sidebars in 1506 question are associated. The "sidebarsByValInfo" parameter contains 1507 the list of the conference objects associated with the sidebars by 1508 value derived from the main conference. The retrieved sidebars can 1509 then be updated or deleted using the "sidebarByValRequest" message, 1510 which is described in Section 5.3.8. 1512 1514 1515 1516 1517 1518 1519 1520 1521 1522 1524 1525 1528 1529 1530 1531 1533 1534 1535 1537 1539 1540 1541 1542 1543 1544 1545 1546 1547 1549 1551 1554 1555 1556 1558 1560 1561 1562 1564 Figure 13: Structure of the sidebarsByValRequest and 1565 sidebarsByValResponse messages 1567 5.3.8. sidebarByValRequest and sidebarByValResponse 1569 A sidebarByValRequest message MUST contain the "operation" parameter 1570 which discriminates among retrieval, creation, modification and 1571 deletion of a specific sidebar. The other required parameters depend 1572 upon the type of operation. 1574 In the case of a "create" operation, the "confObjID" parameter MUST 1575 be included in the sidebyValRequest message. In this case, the 1576 "confObjID" parameter contains the XCON-URI of the main conference in 1577 which the sidebar has to be created. If no "sidebarByValInfo" 1578 parameter is included, as envisaged in the XCON framework 1579 ([RFC5239]), the sidebar is created by cloning the main conference, 1580 following the implementation specific cloning rules. Otherwise, 1581 similarly to the case of direct creation, the sidebar conference 1582 object is built on the basis of the "sidebarByValInfo" parameter 1583 provided by the requestor. As a consequence of a sidebar-by-val 1584 creation, the conference server MUST update the main conference 1585 object reflected by the "confObjID" parameter in the 1586 sidebarbyValRequest/create message introducing the new sidebar object 1587 as a new new in the proper section . The 1588 newly created sidebar conference object MAY be included in the 1589 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1590 "response-code" is "200". The XCON-URI of the newly created sidebar 1591 MUST appear in the "confObjID" parameter of the response. The 1592 conference server can notify any conferencing clients that have 1593 subscribed to the conference event package, and are authorized to 1594 receive the notifications, of the addition of the sidebar to the 1595 conference. 1597 In the case of a "sidebarByVal" request with an operation of 1598 "retrieve", the URI for the conference object created for the sidebar 1599 (received in the response to a "create" operation or in a 1600 sidebarsByValResponse message) MUST be included in the "confObjID" 1601 parameter in the request. This "retrieve" operation is handled by 1602 the conference server in the same manner as a "retrieve" operation 1603 included in a confRequest message as detailed in Section 5.3.4. 1605 In the case of a "sidebarByVal" request with an operation of 1606 "update", the "sidebarByValInfo" MUST also be included in the 1607 request. The "confObjID" parameter contained in the request message 1608 identifies the specific sidebar instance to be updated. An "update" 1609 operation on the "sidebarByValInfo" is handled by the conference 1610 server in the same manner as an "update" operation on the confInfo 1611 included in a confRequest message as detailed in Section 5.3.4. A 1612 "sidebarByValResponse" message MUST carry back to the client a 1613 "version" element related to the current version of the sidebar whose 1614 identifier is contained in the "confObjId" field of the request. 1616 If an "operation" of "delete" is included in the sidebarByVal 1617 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1618 request. Any "sidebarByValInfo" included in the request MUST be 1619 ignored by the conference server. The URI for the conference object 1620 associated with the sidebar MUST be included in the "confObjID" 1621 parameter in the request. If the specific conferencing user as 1622 reflected by the "confUserID" in the request is authorized to delete 1623 the conference, the conference server deletes the conference object 1624 reflected by the "confObjID" parameter and updates the data in the 1625 conference object from which the sidebar was cloned. The conference 1626 server can notify any conferencing clients that have subscribed to 1627 the conference event package, and are authorized to receive the 1628 notifications, of the deletion of the sidebar to the conference. 1630 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1631 or "delete" carries a "confObjID" which is not associated with any 1632 existing sidebar-by-val, a confResponse message containing a "404" 1633 error code will be generated on the server's side. This holds also 1634 for the case in which the mentioned "confObjID" is related to an 1635 existing conference object stored at the server, but associated with 1636 a blueprint or with an actual conference or with a sidebar-by-ref 1637 rather than a sidebar-by-val. 1639 1641 1642 1643 1644 1645 1646 1647 1648 1649 1651 1653 1656 1657 1658 1660 1663 1664 1665 1667 1669 1670 1671 1672 1673 1674 1675 1676 1677 1679 1681 1684 1685 1686 1688 1690 1691 1692 1694 Figure 14: Structure of the sidebarByValRequest and 1695 sidebarByValResponse messages 1697 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1699 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1700 invoked to retrieve the element of the conference 1701 object identified by the "confObjID" parameter. The 1702 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1703 "operation" parameter MUST NOT be included in a 1704 "sidebarsByRefRequest" message. In the case of a "response-code" of 1705 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1707 response. The element represents the set of URIs 1708 of the sidebars associated with the main conference, whose 1709 description (in the form of a standard XCON conference document) is 1710 external to the main conference itself. Through the retrieved URIs, 1711 it is then possible to access single sidebars using the 1712 "sidebarByRef" request message, described in Section 5.3.10. A 1713 "sidebarsByRefResponse" message MUST carry back to the client a 1714 "version" element related to the current version of the main 1715 conference object (i.e. the one whose identifier is contained in the 1716 "confObjId" field of the request) to which the sidebars in question 1717 are associated. 1719 1721 1722 1723 1724 1725 1726 1727 1728 1729 1731 1733 1736 1737 1738 1740 1742 1743 1744 1746 1748 1749 1750 1751 1752 1753 1755 1756 1757 1759 1761 1764 1765 1766 1768 1770 1771 1772 1774 Figure 15: Structure of the sidebarsByRefRequest and 1775 sidebarsByRefResponse messages 1777 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1779 A sidebarByRefRequest message MUST contain the "operation" parameter 1780 which discriminates among retrieval, creation, modification and 1781 deletion of a specific sidebar. The other required parameters depend 1782 upon the type of operation. 1784 In the case of a "create" operation, the "confObjID" parameter MUST 1785 be included in the sidebyRefRequest message. In this case, the 1786 "confObjID" parameter contains the XCON-URI of the main conference in 1787 which the sidebar has to be created. If no "sidebarByRefInfo" 1788 parameter is included, as envisaged in the XCON framework 1789 ([RFC5239]), the sidebar is created by cloning the main conference, 1790 following the implementation specific cloning rules. Otherwise, 1791 similarly to the case of direct creation, the sidebar conference 1792 object is built on the basis of the "sidebarByRefInfo" parameter 1793 provided by the requestor. If the creation of the sidebar is 1794 successful, the conference server MUST update the "sidebars-by-ref" 1795 element in the conference object from which the sidebar was created 1796 (i.e., as identified by the "confObjID" in the original sidebarByRef 1797 request), with the URI of the newly created sidebar. The newly 1798 created conference object MAY be included in the response in the 1799 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1800 URI for the conference object associated with the newly created 1801 sidebar object MUST appear in the "confObjID" parameter of the 1802 response. The conference server can notify any conferencing clients 1803 that have subscribed to the conference event package, and are 1804 authorized to receive the notifications, of the addition of the 1805 sidebar to the conference. 1807 In the case of a "sidebarByRef" request with an operation of 1808 "retrieve", the URI for the conference object created for the sidebar 1809 MUST be included in the "confObjID" parameter in the request. A 1810 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1811 conference server in the same manner as a "retrieve" operation on the 1812 confInfo included in a confRequest message as detailed in 1813 Section 5.3.4. 1815 In the case of a "sidebarByRef" request with an operation of 1816 "update", the URI for the conference object created for the sidebar 1817 MUST be included in the "confObjID" parameter in the request. The 1818 "sidebarByRefInfo" MUST also be included in the request in the case 1819 of an "operation" of "update". An "update" operation on the 1820 "sidebarByRefInfo" is handled by the conference server in the same 1821 manner as an "update" operation on the confInfo included in a 1822 confRequest message as detailed in Section 5.3.4. A 1823 "sidebarByRefResponse" message MUST carry back to the client a 1824 "version" element related to the current version of the sidebar whose 1825 identifier is contained in the "confObjId" field of the request. 1827 If an "operation" of "delete" is included in the sidebarByRef 1828 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1829 request. Any "sidebarByRefInfo" included in the request MUST be 1830 ignored by the conference server. The URI for the conference object 1831 for the sidebar MUST be included in the "confObjID" parameter in the 1832 request. If the specific conferencing user as reflected by the 1833 "confUserID" in the request is authorized to delete the conference, 1834 the conference server SHOULD delete the conference object reflected 1835 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1836 element in the conference object from which the sidebar was 1837 originally cloned. The conference server can notify any conferencing 1838 clients that have subscribed to the conference event package, and are 1839 authorized to receive the notifications, of the deletion of the 1840 sidebar. 1842 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1843 or "delete" carries a "confObjID" which is not associated with any 1844 existing sidebar-by-ref, a confResponse message containing a "404" 1845 error code will be generated on the server's side. This holds also 1846 for the case in which the mentioned "confObjID" is related to an 1847 existing conference object stored at the server, but associated with 1848 a blueprint or with an actual conference or with a sidebar-by-val 1849 rather than a sidebar-by-ref. 1851 1853 1854 1855 1856 1857 1858 1859 1860 1861 1863 1865 1868 1869 1870 1872 1874 1875 1876 1878 1880 1881 1882 1883 1884 1885 1886 1887 1888 1890 1892 1895 1896 1897 1900 1902 1903 1904 1906 Figure 16: Structure of the sidebarByRefRequest and 1907 sidebarByRefResponse messages 1909 5.3.11. extendedRequest and extendedResponse 1911 In order to facilitate the possibility of specifying new request/ 1912 response pairs for conference control, CCMP makes available the 1913 "extendedRequest" and "extendedResponse" messages. Such messages 1914 constitute a CCMP skeleton in which implementors can transport the 1915 information needed to realize conference control mechanisms not 1916 explicitly envisioned in the CCMP specification; these mechanisms are 1917 called, in this context, "extensions". Each extension is assumed to 1918 be characterized by an appropriate name that MUST be carried in the 1919 extendedRequest/extendedResponse pair in the provided 1920 field. Extension-specific information can be transported in the form 1921 of schema-defined XML elements inside the element present in 1922 both extendedRequest and extendedResponse. 1924 The conferencing client SHOULD be able to be informed about the 1925 extensions supported by a CCMP server and to recover the XML Schema 1926 defining the related specific elements by means of an optionsRequest/ 1927 optionsResponse CCMP transaction (see Section 5.3.12). 1929 The meaning of the common CCMP parameters inherited by the 1930 extendedRequest and extendedResponse from the basic CCMP request and 1931 response messages SHOULD be preserved and exploited appropriately 1932 while defining an extension. 1934 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1947 1949 1950 1951 1953 1956 1957 1959 1961 1962 1963 1964 1965 1966 1967 1968 1969 1971 1973 1975 1976 1977 1980 1983 1984 1986 Figure 17: Structure of the extendedRequest and extendedResponse 1987 messages 1989 5.3.12. optionsRequest and optionsResponse 1991 An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. 1992 it does not represent a specialization of the general CCMP request. 1993 It allows a CCMP client to become aware of CCMP server capabilities 1994 in terms of CCMP supported messages. 1996 The "optionsResponse" returns, in the appropriate field, a 1997 list of the supported CCMP messages as defined in this specification. 1998 These messages are in the form of a list, 1999 including each of the supported messages as reflected by elements. The "optionsResponse" message also allows for an 2001 , which is a list of additional message types 2002 in the form of elements that are currently 2003 undefined, to allow for future extensibility. The following 2004 information is provided for both types of messages: 2005 o (mandatory): in case of standard messages, it can be one of 2006 the ten standard message names defined in this document (i.e. 2007 "blueprintsRequest", "confsRequest", etc.). In case of 2008 extensions, this element MUST carry the same value of the 2009 inserted in the corresponding extendedRequest/ 2010 extendedResponse message pair 2011 o (optional): this field is a list of 2012 entries, each representing the CRUD operation supported by the 2013 server for the message. If this optional element is absent, the 2014 client SHOULD assume the server is able to handle the entire set 2015 of CRUD operations or, in case of standard messages, all the 2016 operations envisioned for that message in this document. 2017 o (optional): since all CCMP messages can potentially 2018 contain XML elements not envisioned in the CCMP schema (due to the 2019 presence of elements and attributes), a reference to a 2020 proper schema definition specifying such new elements/attributes 2021 can also be sent back to the clients by means of such field. If 2022 this element is absent, no new elements are introduced in the 2023 messages further than those explicitly defined in the CCMP 2024 specification. 2025 o (optional): human readable information about the 2026 related message 2028 The only parameter needed in the optionsRequest is the sender 2029 confUserID, which is mirrored in the homologous parameter of the 2030 corresponding optionsResponse. 2032 The MUST appear in the optionsResponse and 2033 MUST NOT be void, since a CCMP server MUST be able to handle at least 2034 one of the standard messages in at least one of the envisioned 2035 operations, i.e. the aforementioned list MUST carry at least one 2036 containing at least one element. 2038 2040 2041 2042 2043 2044 2046 2048 2049 2050 2051 2052 2053 2054 2055 2056 2058 2060 2063 2064 2065 2067 2069 2070 2071 2073 2075 2076 2077 2080 2083 2085 2086 2087 2089 2091 2092 2093 2096 2098 2099 2100 2102 2104 2105 2106 2109 2112 2114 2116 2118 2119 2120 2122 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2139 2141 2142 2143 2145 2146 2147 2149 Figure 18: Structure of the optionsRequest and optionsResponse 2150 messages 2152 5.4. CCMP Response Codes 2154 All CCMP response messages MUST include a ""response-code"". The 2155 following summarizes the CCMP response codes: 2157 200 Success: Successful completion of the requested operation. 2158 400 Bad Request: Syntactically malformed request. 2159 401 Unauthorized: User not allowed to perform the required 2160 operation. 2161 403 Forbidden: Operation not allowed (e.g., cancellation of a 2162 blueprint). 2163 404 Object Not Found: Target conference object missing at the server 2164 (it refers to the "confObjID" parameter in the generic request 2165 message) 2166 409 Conflict: A generic error associated with all those situations 2167 in which a requested client operation cannot be successfully 2168 completed by the server. An example of such situation is when the 2169 modification of an object cannot be applied due to conflicts 2170 arising at the server's side, e.g. because the client version of 2171 the object is an obsolete one and the requested modifications 2172 collide with the up-to-date state of the object stored at the 2173 server. Such code would also be used if a client attempts to 2174 create an object (conference or user) with an entity that already 2175 exists. 2176 420 User Not Found: Target user missing at the server (it is related 2177 to the XCON-USERID in the "entity" attribute of the "userInfo" 2178 parameter when it is included in userRequests) 2180 421 Invalid confUserID: User missing at the server (this code is 2181 returned in the case of requests in which the "confUserID" of the 2182 sender is invalid). 2183 422 Invalid Conference Password: Target conference object's password 2184 contained in the request is wrong. 2185 423 Conference Password Required: "conference-password" missing in a 2186 request to access a password-protected conference object. 2187 424 Authentication Required: User's authentication information is 2188 missing or invalid. 2189 425 Forbidden Delete Parent: Cancel operation failed since the 2190 target object is a parent of child objects which depend on it, or 2191 because it effects, based on the "parent-enforceable" mechanism, 2192 the corresponding element in a child object. 2193 426 Forbidden Change Protected: Update refused by the server because 2194 the target element cannot be modified due to its implicit 2195 dependence on the value of a parent object ("parent-enforceable" 2196 mechanism). 2197 500 Server Internal Error: The server cannot complete the required 2198 service due to a system internal error. 2199 501 Not Implemented: Operation envisaged in the protocol, but not 2200 implemented in the contacted server. 2201 510 Request Timeout: The time required to serve the request has 2202 exceeded the envisaged service threshold. 2203 511 Resources Not Available: This code is used when the CCMP server 2204 cannot execute a command because of resource issues, e.g. it 2205 cannot create a sub conference because the system has reached its 2206 limits on the number of sub conferences, or if a request for 2207 adding a new user fails because the max number of users has been 2208 reached for the conference or the max number of users has been 2209 reached for the conferencing system. 2211 The handling of a "response-code" of "404", "409", "420", "421", 2212 "425" and "426" are only applicable to specific operations for 2213 specialized message responses and the details are provided in 2214 Section 5.3. The following table summarizes these response codes and 2215 the specialized message and operation to which they are applicable: 2217 +---------------+------------+------------+------------+------------+ 2218 | Response code | Create | Retrieve | Update | Delete | 2219 +---------------+------------+------------+------------+------------+ 2220 | 404 | userReques | All | All update | All delete | 2221 | | t, | retrieve | requests | requests | 2222 | | sidebarBy | requests, | | | 2223 | | ValRequest | EXCEPT: | | | 2224 | | sidebars | blueprints | | | 2225 | | ByRefReque | Request, | | | 2226 | | st | confsRequ | | | 2227 | | | est | | | 2228 | ------------- | ---------- | ---------- | ---------- | ---------- | 2229 | 409 | N/A | N/A | All update | N/A | 2230 | | | | requests | | 2231 | ------------- | ---------- | ---------- | ---------- | ---------- | 2232 | 420 | userReques | userReques | userReques | userReques | 2233 | | t(3rd part | t | t | t | 2234 | | yinvite | | | | 2235 | | with thir | | | | 2236 | | duser | | | | 2237 | | entity) | | | | 2238 | | (*) | | | | 2239 | ------------- | ---------- | ---------- | ---------- | ---------- | 2240 | 421 | All create | All | All update | All delete | 2241 | | requests, | retrieve | requests | requests | 2242 | | EXCEPT: | requests | | | 2243 | | userReques | | | | 2244 | | twith no | | | | 2245 | | confUserI | | | | 2246 | | D(**) | | | | 2247 | ------------- | ---------- | ---------- | ---------- | ---------- | 2248 | 425 | N/A | N/A | N/A | All delete | 2249 | | | | | request | 2250 | ------------- | ---------- | ---------- | ---------- | ---------- | 2251 | 426 | N/A | N/A | All update | N/A | 2252 | | | | requests | | 2253 +---------------+------------+------------+------------+------------+ 2255 Table 2: Response codes and associated operations 2257 (*) "420" in answer to a "userRequest/create" operation: in the case 2258 of a third-party invite, this code can be returned if the 2259 "confUserID" (contained in the "entity" attribute of the "userInfo" 2260 parameter) of the user to be added is unknown. In the case above, if 2261 instead it is the "confUserID" of the sender of the request that is 2262 invalid, a "421" error code is returned to the client. 2264 (**) "421" is not sent in answers to "userRequest/create" messages 2265 having a "null" confUserID, since this case is associated with a user 2266 who is unaware of his own XCON-USERID, but wants to enter a known 2267 conference. 2269 In the case of a response code of "510", a conferencing client MAY 2270 re-attempt the request within a period of time that would be specific 2271 to a conference control client or conference control server. 2273 A response code of "400" indicates that the conference control client 2274 sent a malformed request, which is indicative of an error in the 2275 conference control client or in the conference control server. The 2276 handling is specific to the conference control client implementation 2277 (e.g., generate a log, display an error message, etc.). It is NOT 2278 RECOMMENDED that the client re-attempt the request in this case. 2280 Response codes such as "401" and "403" indicate the client does not 2281 have the appropriate permissions, or there is an error in the 2282 permissions: re-attempting the request would likely not succeed and 2283 thus it is NOT RECOMMENDED. 2285 Any unexpected or unknown "response-code" SHOULD be treated by the 2286 client in the same manner as a "500" "response-code", the handling of 2287 which is specific to the conference control client implementation. 2289 6. A complete example of the CCMP in action 2291 In this section a typical, not normative, scenario in which the CCMP 2292 comes into play is described, by showing the actual composition of 2293 the various CCMP messages. In the call flows of the example, the 2294 Conference Control Client is a CCMP-enabled client, whereas the 2295 Conference Control Server is a CCMP-enabled server. The "confUserID" 2296 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2297 in all requests. The sequence of operations is as follows: 2299 1. Alice retrieves from the server the list of available blueprints 2300 (Section 6.1); 2301 2. Alice asks for detailed information about a specific blueprint 2302 (Section 6.2); 2303 3. Alice decides to create a new conference by cloning the retrieved 2304 blueprint (Section 6.3); 2305 4. Alice modifies information (e.g. XCON-URI, name, description) 2306 associated with the newly created blueprint (Section 6.4); 2307 5. Alice specifies a list of users to be contacted when the 2308 conference is activated (Section 6.5); 2309 6. Alice joins the conference (Section 6.6); 2310 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2311 "xcon-userid:Ciccio@example.com") join the conference 2312 (Section 6.7). 2313 8. Alice asks for the CCMP server capabilities (Section 6.8); 2314 9. Alice exploits an extension of the CCMP server (Section 6.9). 2316 Note, the examples do not include any details beyond the basic 2317 operation. 2319 In the following sections we deal with each of the above mentioned 2320 actions separately. 2322 6.1. Alice retrieves the available blueprints 2324 This section illustrates the transaction associated with retrieval of 2325 the blueprints, together with a dump of the two messages exchanged 2326 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2327 the figure, the "blueprintsResponse" message contains, in the 2328 "blueprintsInfo" parameter, information about the available 2329 blueprints, in the form of the standard XCON-URI of the blueprint, 2330 plus additional (and optional) information, like its display-text and 2331 purpose. 2333 Alice retrieves from the server the list of available blueprints: 2335 CCMP Client CCMP Server 2336 | | 2337 | CCMP blueprintsRequest message | 2338 | - confUserID: Alice | 2339 | - confObjID: (null) | 2340 |------------------------------------------------------>| 2341 | | 2342 | CMP blueprintsResponse message | 2343 | - confUserID: Alice | 2344 | - confObjID: (null) | 2345 | - response-code: 200 | 2346 | - blueprintsInfo: bp123,bp124,.. | 2347 |<------------------------------------------------------| 2348 | | 2349 . . 2350 . . 2352 1. blueprintsRequest message: 2354 2355 2359 2361 xcon-userid:alice@example.com 2362 2363 2364 2366 2. blueprintsResponse message form the server: 2368 2369 2373 2376 xcon-userid:Alice@example.com 2377 200 2378 2379 2380 2381 xcon:AudioRoom@example.com 2382 AudioRoom 2383 Simple Room: 2384 conference room with public access, 2385 where only audio is available, more users 2386 can talk at the same time 2387 and the requests for the AudioFloor 2388 are automatically accepted. 2389 2390 2391 2392 xcon:VideoRoom@example.com 2393 VideoRoom 2394 Video Room: 2395 conference room with public access, 2396 where both audio and video are available, 2397 8 users can talk and be seen at the same time, 2398 and the floor requests are automatically accepted. 2399 2400 2401 2402 xcon:AudioConference1@example.com 2403 AudioConference1 2404 Public Audio Conference: 2405 conference with public access, 2406 where only audio is available, 2407 only one user can talk at the same time, 2408 and the requests for the AudioFloor MUST 2409 be accepted by a Chair. 2410 2411 2412 2413 xcon:VideoConference1@example.com 2414 VideoConference1 2415 Public Video Conference: conference 2416 where both audio and video are available, 2417 only one user can talk 2418 2419 2420 2421 xcon:AudioConference2@example.com 2422 AudioConference2 2423 Basic Audio Conference: 2424 conference with private access, 2425 where only audio is available, 2426 only one user can talk at the same time, 2427 and the requests for the AudioFloor MUST 2428 be accepted by a Chair. 2429 2430 2431 2432 2433 2434 2436 Figure 19: Getting blueprints from the server 2438 6.2. Alice gets detailed information about a specific blueprint 2440 This section illustrates the second transaction in the overall flow. 2441 In this case, Alice, who now knows the XCON-URIs of the blueprints 2442 available at the server, makes a drill-down query, in the form of a 2443 CCMP "blueprintRequest" message, to get detailed information about 2444 one of them (the one called with XCON-URI 2445 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2446 Notice that the response contains, in the "blueprintInfo" parameter, 2447 a document compliant with the standard XCON data model. 2449 Alice retrieves detailed information about a specified blueprint: 2451 CCMP Client CCMP Server 2452 | | 2453 | CCMP blueprintRequest message | 2454 | - confUserID: Alice | 2455 | - confObjID: bp123 | 2456 | - operation: retrieve | 2457 | - blueprintInfo: (null) | 2458 |------------------------------------------------------>| 2459 | | 2460 | CCMP blueprintResponse message | 2461 | - confUserID: Alice | 2462 | - confObjID: bp123 | 2463 | - operation: retrieve | 2464 | - response-code: 200 | 2465 | - blueprintInfo: bp123Info | 2466 |<------------------------------------------------------| 2467 | | 2468 . . 2469 . . 2471 1. blueprintRequest message: 2473 2474 2478 2480 xcon-userid:Alice@example.com 2481 xcon:AudioRoom@example.com 2482 retrieve 2483 2484 2485 2487 2. blueprintResponse message form the server: 2489 2490 2495 2497 xcon-userid:alice@example.com 2498 xcon:AudioRoom@example.com 2499 retrieve 2500 200 2501 Success 2502 2503 2504 2505 AudioRoom 2506 2507 2508 2509 audio stream 2510 2511 audio 2512 2513 2514 2515 2516 allow 2517 2518 2519 confirm 2520 2521 2522 2523 2524 audioLabel 2525 2526 2527 2528 2529 2530 2531 2532 2534 Figure 20: Getting info about a specific blueprint 2536 6.3. Alice creates a new conference through a cloning operation 2538 This section illustrates the third transaction in the overall flow. 2539 Alice decides to create a new conference by cloning the blueprint 2540 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2541 retrieved detailed information through the "blueprintRequest" 2542 message. This is achieved by sending a "confRequest/create" message 2543 having the blueprint's URI in the "confObjID" parameter. The picture 2544 shows such transaction. Notice that the response contains, in the 2545 "confInfo" parameter, the document associated with the newly created 2546 conference, which is compliant with the standard XCON data model. 2547 The "confObjID" in the response is set to the XCON-URI of the new 2548 conference (in this case, "xcon:8977794@example.com"). We also 2549 notice that this value is equal to the value of the "entity" 2550 attribute of the element of the document 2551 representing the newly created conference object. 2553 Alice creates a new conference by cloning the 2554 "xcon:AudioRoom@example.com" blueprint: 2556 CCMP Client CCMP Server 2557 | | 2558 | CCMP confRequest message | 2559 | - confUserID: Alice | 2560 | - confObjID: AudioRoom | 2561 | - operation: create | 2562 | - confInfo: (null) | 2563 |------------------------------------------------------>| 2564 | | 2565 | CCMP confResponse message | 2566 | - confUserID: Alice | 2567 | - confObjID: newConfId | 2568 | - operation: create | 2569 | - response-code: 200 | 2570 | - version: 1 | 2571 | - confInfo: newConfInfo | 2572 |<------------------------------------------------------| 2573 | | 2574 . . 2575 . . 2577 1. confRequest message: 2579 2580 2584 2587 xcon-userid:Alice@example.com 2588 xcon:AudioRoom@example.com 2589 create 2590 2591 2592 2594 2. confResponse message from the server: 2596 2597 2601 2603 xcon-userid:Alice@example.com 2604 xcon:8977794@example.com 2605 create 2606 200 2607 Success 2608 1 2609 2610 2611 2612 2613 New conference by Alice cloned from AudioRoom 2614 2615 2616 2617 2618 audio stream 2619 2620 audio 2621 2622 2623 2624 2625 allow 2626 2627 2628 2629 confirm 2630 2631 2632 2633 333 2634 2635 2636 2637 2638 2639 2640 2642 Figure 21: Creating a new conference by cloning a blueprint 2644 6.4. Alice updates conference information 2646 This section illustrates the fourth transaction in the overall flow. 2647 Alice decides to modify some of the details associated with the 2648 conference she just created. More precisely, she changes the 2649 element under the element of 2650 the document representing the conference. This is achieved through a 2651 "confRequest/update" message carrying the fragment of the conference 2652 document to which the required changes have to be applied. As shown 2653 in the picture, the response contains a code of "200", which 2654 acknowledges the modifications requested by the client, while also 2655 updating the conference version number from 1 to 2, as reflected in 2656 the "version" parameter. 2658 Alice updates information about the conference she just created: 2660 CCMP Client CCMP Server 2661 | | 2662 | CCMP confRequest message | 2663 | - confUserID: Alice | 2664 | - confObjID: 8977794 | 2665 | - operation: update | 2666 | - confInfo: confUpdates | 2667 |------------------------------------------------------>| 2668 | | 2669 | CCMP confResponse message | 2670 | - confUserID: Alice | 2671 | - confObjID: 8977794 | 2672 | - operation: update | 2673 | - response-code: 200 | 2674 | - version: 2 | 2675 | - confInfo: (null) | 2676 |<------------------------------------------------------| 2677 | | 2678 . . 2679 . . 2681 1. confRequest message: 2683 2684 2688 2691 xcon-userid:Alice@example.com 2692 xcon:8977794@example.com 2693 update 2694 2695 2696 2697 2698 Alice's conference 2699 2700 2701 2702 2703 2704 2706 2. confResponse message form the server: 2708 2709 2713 2715 xcon-userid:Alice@example.com 2716 xcon:8977794@example.com 2717 update 2718 200 2719 Success 2720 2 2721 2723 2724 2726 Figure 22: Updating conference information 2728 6.5. Alice inserts a list of users in the conference object 2730 This section illustrates the fifth transaction in the overall flow. 2731 Alice modifies the under the element in 2732 the document associated with the conference she created. To the 2733 purpose, she exploits the "usersRequest" message provided by the 2734 CCMP. The picture below shows the transaction. 2736 Alice updates information about the list of users to whom access to 2737 the conference is permitted: 2739 CCMP Client CCMP Server 2740 | | 2741 | CCMP usersRequest message | 2742 | - confUserID: Alice | 2743 | - confObjID: 8977794 | 2744 | - operation: update | 2745 | - usersInfo: usersUpdates | 2746 |------------------------------------------------------>| 2747 | | 2748 | CCMP usersResponse message | 2749 | - confUserID: Alice | 2750 | - confObjID: 8977794 | 2751 | - operation: update | 2752 | - response-code: 200 | 2753 | - version: 3 | 2754 | - usersInfo: (null) | 2755 |<------------------------------------------------------| 2756 | | 2757 . . 2758 . . 2760 1. usersRequest message: 2762 2763 2767 2769 xcon-userid:Alice@example.com 2770 xcon:8977794@example.com 2771 update 2772 2773 2774 2775 2777 2779 2781 2782 2783 2784 2785 2787 2. usersResponse message form the server: 2789 2790 2794 2796 xcon-userid:Alice@example.com 2797 xcon:8977794@example.com 2798 retrieve 2799 200 2800 Success 2801 3 2802 2803 2804 2806 Figure 23: Updating the list of allowed users for the conference 2807 'xcon:8977794@example.com' 2809 6.6. Alice joins the conference 2811 This section illustrates the sixth transaction in the overall flow. 2812 Alice uses the CCMP to add herself to the newly created conference. 2813 This is achieved through a "userRequest/create" message containing, 2814 in the "userInfo" parameter, a element compliant with the XCON 2815 data model representation. Notice that such element includes 2816 information about the user's Address of Records, as well as her 2817 current end-point. The picture below shows the transaction. Notice 2818 how the "confUserID" parameter is equal to the "entity" attribute of 2819 the element, which indicates that the request issued by 2820 the client is a first-party one. 2822 Alice joins the conference by issuing a "userRequest/create" message 2823 with her own id to the server: 2825 CCMP Client CCMP Server 2826 | | 2827 | CCMP userRequest message | 2828 | - confUserID: Alice | 2829 | - confObjID: 8977794 | 2830 | - operation: create | 2831 | - userInfo: AliceUserInfo | 2832 |------------------------------------------------------>| 2833 | | 2834 | CCMP userResponse message | 2835 | - confUserID: Alice | 2836 | - confObjID: 8977794 | 2837 | - operation: create | 2838 | - response-code: 200 | 2839 | - version: 4 | 2840 | - userInfo: (null) | 2841 |<------------------------------------------------------| 2842 | | 2843 . . 2844 . . 2846 1. userRequest message: 2848 2849 2853 2855 xcon-userid:Alice@example.com 2856 xcon:8977794@example.com 2857 create 2858 2859 2860 2861 2862 2863 mailto:Alice83@example.com 2864 2865 email 2866 2867 2868 2869 2870 2871 2872 2874 2. userResponse message form the server: 2876 2877 2881 2883 xcon-userid:Alice@example.com 2884 xcon:8977794@example.com 2885 create 2886 200 2887 Success 2888 4 2889 2890 2891 2893 Figure 24: Alice joins the conference through the CCMP 2895 6.7. Alice adds a new user to the conference 2897 This section illustrates the seventh and last transaction in the 2898 overall flow. Alice uses the CCMP to add a new conferencing system 2899 user, Ciccio, to the conference. This "third-party" request is 2900 realized through a "userRequest/create" message containing, in the 2901 "userInfo" parameter, a element compliant with the XCON data 2902 model representation. Notice that such element includes information 2903 about Ciccio's Address of Records, as well as his current end-point, 2904 but has a fake "entity" attribute, "AUTO_GENERATE@example.com" as 2905 discussed in Section 4, since the XCON-USERID is initially unknown to 2906 Alice. Thus, the conference server is in charge of generating a new 2907 XCON-USERID for the user Alice indicates (i.e, Ciccio), and returning 2908 it in the "entity" attribute of the "userInfo" parameter carried in 2909 the response, as well as adding the user to the conference. The 2910 picture below shows the transaction. 2912 Alice adds user "Ciccio" to the conference by issuing a third-party 2913 "userRequest/create" message to the server: 2915 CCMP Client CCMP Server 2916 | | 2917 | CCMP userRequest message | 2918 | - confUserID: Alice | 2919 | - confObjID: 8977794 | 2920 | - operation: create | 2921 | - userInfo: dummyUserID, CiccioUserInfo | 2922 |------------------------------------------------------>| 2923 | | 2924 | CCMP optionsResponse message | 2925 | - confUserID: Alice | 2926 | - confObjID: 8977794 | 2927 | - operation: create | 2928 | - response-code: 200 | 2929 | - version: 5 | 2930 | - userInfo: userIDCiccio, | 2931 | CiccioUserInfo | 2932 | | 2933 |<------------------------------------------------------| 2934 | | 2935 . . 2936 . . 2938 1. "third party" userRequest message from Alice: 2940 2941 2945 2947 xcon-userid:Alice@example.com 2948 xcon:8977794@example.com 2949 create 2950 2951 2952 2953 2954 2955 mailto:Ciccio@example.com 2956 2957 email 2958 2959 2960 2961 2962 2963 2964 2966 2. "third party" userResponse message from the server: 2968 2969 2973 2975 xcon-userid:Alice@example.com 2976 xcon:8977794@example.com 2977 create 2978 200 2979 5 2980 2981 2982 2983 2984 2985 mailto:Ciccio@example.com 2986 2987 email 2988 2989 2990 2991 2992 2993 2994 2995 Figure 25: Alice adds a new user to the conference through the CCMP 2997 6.8. Alice asks for the CCMP server capabilities 2999 This section illustrates how Alice can discover which standard CCMP 3000 messages and what extensions are supported by the CCMP server she 3001 interacts with through an optionsRequest/optionsResponse transaction. 3003 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 3004 confUserID parameter. Looking at the element in the 3005 received optionsResponse, Alice infers the following server 3006 capabilities as regards standard CCMP messages: 3007 o the server doesn't support sidebarsByValRequest nor 3008 sidebarByValRequest messages, since they do not appear in the 3009 ; 3010 o the only implemented operation for the blueprintRequest message is 3011 "retrieve", since no other entries are included in the 3012 related field. 3014 By analyzing the , Alice discovers the server 3015 implements a bluePrint extension, referred to as "confSummaryRequest" 3016 in this example. This extension allows Alice to recover via CCMP a 3017 brief description of a specific conference; the XML elements involved 3018 in this extended conference control transaction are available at the 3019 URL indicated in the element and the only operation 3020 provided by this extension is "retrieve". To better understand how 3021 Alice can exploit the "confSummaryRequest" extension via CCMP, see 3022 Section 6.9. 3024 The figure below shows the optionsRequest/optionsResponse message 3025 exchange between Alice and the CCMP server. 3027 CCMP Client CCMP Server 3028 | | 3029 | CCMP optionsRequest message | 3030 | - confUserID: Alice | 3031 |------------------------------------------------------>| 3032 | | 3033 | CCMP userResponse message | 3034 | - confUserID: Alice | 3035 | - response-code: 200 | 3036 | - options (list of both | 3037 | standard and extended | 3038 | supported messages) | 3039 |<------------------------------------------------------| 3040 | | 3041 . . 3042 . . 3044 1. optionsRequest (Alice asks for CCMP server capabilities) 3046 3047 3051 3053 xcon-userid:Alice@example.com 3054 3055 3057 2. optionsResponse (the server returns the list of its conference 3058 control capabilities) 3060 3061 3065 3067 xcon-userid:Alice@example.com 3068 200 3069 success 3070 3071 3072 3073 3074 blueprintsRequest 3075 3076 3077 blueprintRequest 3078 3079 retrieve 3080 3081 3082 3083 confsRequest 3084 3085 3086 confRequest 3088 3089 3090 usersRequest 3091 3092 3093 userRequest 3094 3095 3096 sidebarsByRefRequest 3097 3098 3099 sidebarByRefRequest 3100 3101 3102 3103 3104 confSummaryRequest 3105 3106 retrieve 3107 3108 3109 http://example.com/ccmp-extension-schema.xsd 3110 3111 3112 confSummaryRequest is intented 3113 to allow the requestor to retrieve 3114 a brief description 3115 of the conference indicated in the 3116 confObjID request parameter 3117 3118 3119 3120 3121 3122 3123 3125 Figure 26: Alice asks for the server control capabilities 3127 6.9. Alice exploits a CCMP server extension 3129 In this section, a very simple example of CCMP extension support is 3130 provided. Alice can recover information about this and other server- 3131 supported extensions by issuing an optionsRequest (see Section 6.8). 3133 The extension in question is named "confSummaryRequest" and is 3134 conceived to allow a CCMP client to obtain from the CCMP server 3135 synthetic information about a specific conference. The conference 3136 summary is carried in the form of an XML element, , 3137 defined by the following XML schema: 3139 3140 3142 3144 3145 3146 3147 3148 3149 3150 3151 3153 3155 Figure 27: Example of XML Schema defining an extension parameter 3156 (ccmp-extension-schema.xsd) 3158 As it can be inferred from the schema file, the element 3159 contains conference information related to: 3161 o title 3162 o status (active or registered) 3163 o participation modality (if everyone is allowed to participate, the 3164 boolean element is set to "true") 3165 o involved media 3167 In order to retrieve a conference summary related to the conference 3168 she participates in, Alice then sends to the CCMP server an 3169 extendedRequest with a "confSummaryRequest" , 3170 specifying the conference xcon-uri in the confObjID request 3171 parameter, as depicted in the figure below. 3173 CCMP Client CCMP Server 3174 | | 3175 | CCMP extendedRequest message | 3176 | - confUserID: Alice | 3177 | - confObjID: 8977794 | 3178 | - operation: retrieve | 3179 | - extensionName: confSummaryRequest | 3180 |------------------------------------------------------>| 3181 | | 3182 | CCMP extendedResponse message | 3183 | - confUserID: Alice | 3184 | - confObjID: 8977794 | 3185 | - operation: retrieve | 3186 | - response-code: 200 | 3187 | - extensionName: | 3188 | confSummaryRequest | 3189 | - confSummary | 3190 |<------------------------------------------------------| 3191 | | 3192 . . 3193 . . 3195 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3197 3198 3202 3204 xcon-userid:Alice@example.com 3205 xcon:8977794@example.com 3206 retrieve 3207 3208 confRequestSummary 3209 3210 3211 3213 2. extendedResponse (the server provides Alice with a brief description 3214 of the desired conference) 3216 3217 3221 3223 xcon-userid:Alice@example.com 3224 xcon:8977794@example.com 3225 retrieve 3226 200 3227 success 3228 3229 confSummaryRequest 3230 3231 Alice's conference 3232 active 3233 true 3234 audio 3235 3236 3237 3238 3240 Figure 28: Alice exploits the 'confSummaryRequest' extension 3242 7. Locating a Conference Control Server 3244 If a conference control client is not pre-configured to use a 3245 specific conference control server for the requests, the client MUST 3246 first discover the conference control server before it can send any 3247 requests. The result of the discovery process, is the address of the 3248 server supporting conferencing. In this document, the result is an 3249 http: or https: URI, which identifies a conference server. 3251 This document proposes the use of DNS to locate the conferencing 3252 server. U-NAPTR resolution for conferencing takes a domain name as 3253 input and produces a URI that identifies the conferencing server. 3254 This process also requires an Application Service tag and an 3255 Application Protocol tag, which differentiate conferencing-related 3256 NAPTR records from other records for that domain. 3258 Section 12.4.1 defines an Application Service tag of "XCON", which is 3259 used to identify the centralized conferencing (XCON) server for a 3260 particular domain. The Application Protocol tag "CCMP", defined in 3261 Section 12.4.2, is used to identify an XCON server that understands 3262 the CCMP protocol. 3264 The NAPTR records in the following example Figure 29 demonstrate the 3265 use of the Application Service and Protocol tags. Iterative NAPTR 3266 resolution is used to delegate responsibility for the conferencing 3267 service from "zonea.example.com." and "zoneb.example.com." to 3268 "outsource.example.com.". 3270 zonea.example.com. 3271 ;; order pref flags 3272 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3273 "" ; regex 3274 outsource.example.com. ; replacement 3275 ) 3276 zoneb.example.com. 3277 ;; order pref flags 3278 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3279 "" ; regex 3280 outsource.example.com. ; replacement 3281 ) 3282 outsource.example.com. 3283 ;; order pref flags 3284 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 3285 "!*.!https://confs.example.com/!" ; regex 3286 . ; replacement 3287 ) 3289 Figure 29: Sample XCON:CCMP Service NAPTR Records 3291 Details for the "XCON" Application Service tag and the "CCMP" 3292 Application Protocol tag are included in Section 12.4. 3294 8. Managing Notifications 3296 As per [RFC5239], the CCMP is one of the following four protocols 3297 which have been formally identified within the XCON framework: 3298 Conference Control Protocol: between Conference and Media Control 3299 Client and Conference Server. Such protocol is the subject of the 3300 present document. 3301 Binary floor Control Protocol: between the Floor Control Client and 3302 the Floor Control Server. Such protocol is the BFCP, specified in 3303 [RFC4582]. 3304 Call Signaling Protocol: between the Call Signaling Client and the 3305 Focus. Such protocol can be either SIP or any other call 3306 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3307 a conferencing session. 3308 Notification Protocol: between the Notification Client and the XCON 3309 Notification Service. This specification does not define a new 3310 notification protocol. For clients that use SIP as the call 3311 signaling protocol, the XCON event package 3312 [I-D.ietf-xcon-event-package] MUST be used by the client for 3313 notifications of changes in the conference data as described 3314 below. 3316 The CCMP protocol specified in this document is a pro-active one and 3317 is used by a conferencing client to send requests to a conferencing 3318 server in order to retrieve information about the conference objects 3319 stored by the server and to potentially manipulate them. However, a 3320 complete conferencing solution is not prohibited from providing 3321 clients with a means for receiving asynchronous updates about the 3322 status of the objects available at the server. The notification 3323 protocol, while conceptually independent of all the mentioned 3324 companion protocols, can nonetheless be chosen in a way that is 3325 consistent with the overall protocol architecture characterizing a 3326 specific deployment, as discussed in the following. 3328 When the conference control client uses SIP [RFC3261] as the 3329 signaling protocol to participate in the conference, SIP event 3330 notification can be used. In such a case, the conference control 3331 client MUST implement the Conference event package for XCON 3332 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3333 conferencing clients as is SIP for signaling per the XCON Framework 3334 [RFC5239]. 3336 In the case where the interface to the conference server is entirely 3337 web based, there is a common mechanism for web-based systems that 3338 could be used - a "call back". With this mechanism, the conference 3339 client provides the conference server with an HTTP URL which is 3340 invoked when a change occurs. This is a common implementation 3341 mechanism for e-commerce. This works well in the scenarios whereby 3342 the conferencing client is a web server that provides the graphical 3343 HTML user interface and uses CCMP as the backend interface to the 3344 conference server. And, this model can co-exist with the SIP event 3345 notification model. PC-based clients behind NATs could provide a SIP 3346 event URI, whereas web-based clients using CCMP in the backend would 3347 probably find the HTTP call back approach much easier. The details 3348 of this approach are out of scope for the CCMP per se, thus the 3349 expectation is that a future specification will document this 3350 solution. 3352 9. HTTP Transport 3354 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3355 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3356 conforming conference Server and Conferencing client MUST support. 3358 Although CCMP uses HTTP as a transport, it uses a strict subset of 3359 HTTP features, and due to the restrictions of some features, a 3360 conferencing server may not be a fully compliant HTTP server. It is 3361 intended that a conference server can easily be built using an HTTP 3362 server with extensibility mechanisms, and that a conferencing client 3363 can trivially use existing HTTP libraries. This subset of 3364 requirements helps implementors avoid ambiguity with the many options 3365 the full HTTP protocol offers. 3367 A conferencing client that conforms to this specification is not 3368 required to support HTTP authentication [RFC2617] or cookies 3369 [RFC2965]. These mechanism are unnecessary because CCMP requests 3370 carry their own authentication information (in the "subject" field; 3371 see Section 5.1). 3373 A CCMP request is carried in the body of an HTTP POST request. The 3374 conferencing client MUST include a Host header in the request. 3376 The MIME type of CCMP request and response bodies is "application/ 3377 ccmp+xml". The conference server and conferencing client MUST 3378 provide this value in the HTTP Content-Type and Accept header fields. 3379 If the conference server does not receive the appropriate Content- 3380 Type and Accept header fields, the conference server SHOULD fail the 3381 request, returning a 406 (not acceptable) response. CCMP responses 3382 SHOULD include a Content-Length header. 3384 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3385 header in CCMP requests. The conference server MAY return 501 (not 3386 implemented) errors if either of these HTTP features are used. In 3387 the case that the conference server receives a request from the 3388 conferencing client containing a If-* (conditional) header, the 3389 conference server SHOULD return a 412 (precondition failed) response. 3391 The POST method is the only method REQUIRED for CCMP. If a 3392 conference server chooses to support GET or HEAD, it SHOULD consider 3393 the kind of application doing the GET. Since a conferencing client 3394 only uses a POST method, the GET or HEAD MUST be either an escaped 3395 URL (e.g., somebody found a URL in protocol traces or log files and 3396 fed it into their browser) or somebody doing testing/ debugging. The 3397 conference server could provide information in the CCMP response 3398 indicating that the URL corresponds to a conference server and only 3399 responds to CCMP POST requests or the conference server could instead 3400 try to avoid any leak of information by returning a very generic HTTP 3401 error message such as 405 (method not allowed). 3403 The conference server populates the HTTP headers of responses so that 3404 they are consistent with the contents of the message. In particular, 3405 the "CacheControl" header SHOULD be set to disable caching of any 3406 conference information by HTTP intermediaries. Otherwise, there is 3407 the risk of stale information and/or the unauthorized disclosure of 3408 the information. The HTTP status code MUST indicate a 2xx series 3409 response for all CCMP Response and Error messages. 3411 The conference server MAY redirect a CCMP request. A conferencing 3412 client MUST handle redirects, by using the Location header provided 3413 by the server in a 3xx response. When redirecting, the conferencing 3414 client MUST observe the delay indicated by the Retry-After header. 3415 The conferencing client MUST authenticate the server that returns the 3416 redirect response before following the redirect. A conferencing 3417 client SHOULD authenticate the conference server indicated in a 3418 redirect. 3420 The conference server SHOULD support persistent connections and 3421 request pipelining. If pipelining is not supported, the conference 3422 server MUST NOT allow persistent connections. The conference server 3423 MUST support termination of a response by the closing of a 3424 connection. 3426 Implementations of CCMP that implement HTTP transport MUST implement 3427 transport over TLS [RFC2818]. TLS provides message integrity and 3428 confidentiality between the conference control client and the 3429 conference control server. The conferencing client MUST implement 3430 the server authentication method described in HTTPS [RFC2818]. The 3431 device uses the URI obtained during conference server discovery to 3432 authenticate the server. The details of this authentication method 3433 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3434 the conferencing client SHOULD fail a request if server 3435 authentication fails. 3437 10. Security Considerations 3439 As identified in the XCON framework [RFC5239], there are a wide 3440 variety of potential attacks related to conferencing, due to the 3441 natural involvement of multiple endpoints and the capability to 3442 manipulate the data on the conference server using CCMP. Examples of 3443 attacks include the following: an endpoint attempting to listen to 3444 conferences in which it is not authorized to participate, an endpoint 3445 attempting to disconnect or mute other users, and theft of service by 3446 an endpoint in attempting to create conferences it is not allowed to 3447 create. 3449 The following summarizes the security considerations for CCMP: 3450 1. The client MUST determine the proper conference server. The 3451 conference server discovery is described in Section 7. 3452 2. The client MUST connect to the proper conference server. The 3453 mechanisms for addressing this security consideration are 3454 described in Section 10.1. 3455 3. The protocol MUST support a confidentiality and integrity 3456 mechanism. As described in Section 9, implementations of CCMP 3457 MUST implement the HTTP transport over TLS [RFC2818]. 3459 4. There are security issues associated with the authorization to 3460 perform actions on the conferencing system to invoke specific 3461 capabilities. A conference server SHOULD ensure that only 3462 authorized entities can manipulate the conference data. The 3463 mechanisms for addressing this security consideration are 3464 described in Section 10.2. 3465 5. The privacy and security of the identity of a user in the 3466 conference MUST be assured. The mechanisms to ensure the 3467 security and privacy of identity are discussed in Section 10.3. 3468 6. A final issue is related to Denial of Service (DoS) attacks on 3469 the conferencing server itself. In order to minimize the 3470 potential for DoS attacks, it is RECOMMENDED that conferencing 3471 systems require user authentication and authorization for any 3472 client participating in a conference. This can be accomplished 3473 through the use of the mechanisms described in Section 10.2, as 3474 well as by using the security mechanisms associated with the 3475 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 3476 Most CCMP commands can pend indefinitely, thus increasing the 3477 potential that pending requests can continue to increase when a 3478 server is receiving more requests than it can process within a 3479 specific time period. In this case a server SHOULD return a 510 3480 response code to the pending requests. In addition, to mitigate 3481 the situation clients MUST NOT wait indefinitely for a response 3482 and MUST implement a timer (in the range of seconds) such that 3483 when it expires, the client MUST close the connection. 3485 10.1. Assuring that the Proper Conferencing Server has been contacted 3487 When the CCMP transaction is conducted using TLS [RFC5246], the 3488 conference server can authenticate its identity, either as a domain 3489 name or as an IP address, to the conference client by presenting a 3490 certificate containing that identifier as a subjectAltName (i.e., as 3491 an iPAddress or dNSName, respectively). With the use of HTTP as a 3492 transport for CCMP, this is exactly the authentication described by 3493 TLS [RFC2818]. If the client has external information as to the 3494 expected identity or credentials of the proper conference server 3495 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 3496 implementation of CCMP MUST be capable of being transacted over TLS 3497 so that the client can request the above authentication, and a 3498 conference server implementation MUST include this feature. Note 3499 that in order for the presented certificate to be valid at the 3500 client, the client must be able to validate the certificate. In 3501 particular, the validation path of the certificate must end in one of 3502 the client's trust anchors, even if that trust anchor is the 3503 conference server certificate itself. 3505 10.2. User Authentication and Authorization 3507 Many policy authorization decisions are based on the identity of the 3508 user or the role that a user may have. The conferencing server MUST 3509 implement mechanisms for authentication of users to validate their 3510 identity. There are several ways that a user might authenticate its 3511 identity to the system. For users joining a conference using one of 3512 the call signaling protocols, the user authentication mechanisms for 3513 the specific protocol can be used. For the case of users joining the 3514 conference using the CCMP, TLS is RECOMMENDED. 3516 The XCON Framework [RFC5239] provides an overview of other 3517 authorization mechanisms. In the cases where a user is authorized 3518 via multiple mechanisms, it is RECOMMENDED that the conference server 3519 correlate the authorization of the CCMP interface with other 3520 authorization mechanisms - e.g., PSTN users that join with a PIN and 3521 control the conference using CCMP. When a conference server presents 3522 the identity of authorized users, it MAY provide information about 3523 the way the identity was proven or verified by the system. A 3524 conference server can also allow a completely unauthenticated user 3525 into the system - this information SHOULD also be communicated to 3526 interested parties. 3528 Once a user is authenticated and authorized through the various 3529 mechanisms available on the conference server, the conference server 3530 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3531 associate the XCON-USERID with any signaling specific user 3532 identifiers that were used for authentication and authorization. 3533 This XCON-USERID can be provided to a specific user through the 3534 conference notification interface and MUST be provided to users that 3535 interact with the conferencing system using the CCMP (i.e., in the 3536 appropriate CCMP response messages). This conference user identifier 3537 is REQUIRED for any subsequent operations on the conference object. 3539 We herein remark that the definition of a complete solution for 3540 policy-based management of an XCON-compliant conference system is out 3541 of the scope of this document, as well as of the XCON WG. We believe 3542 that the specification of such a framework is orthogonal to the 3543 overall XCON architecture, especially if a Role Based Access Control 3544 (RBAC) approach is embraced. In RBAC, the following elements are 3545 identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; 3546 (v) Permissions. For all of the above elements a direct mapping 3547 exists onto the main XCON entities. As an example, RBAC objects map 3548 onto XCON data model objects and RBAC operations map onto CCMP 3549 operations. 3551 Future documents might work on the definition of an RBAC framework 3552 for XCON, by first focusing on the definition of roles and eventually 3553 arriving at the specification of the needed permission policy sets 3554 and role policy sets (used to associate policy permission sets with 3555 specific roles). With these policies in place, access to a 3556 conference object compliant with the XCON data model can be 3557 appropriately controlled. Finally, coming to the issue of assigning 3558 users to roles, this can be done through so-called role-assignment 3559 policies. Such assignment should be under the responsibility of an 3560 ad-hoc dedicated Role Assignment entity. 3562 10.3. Security and Privacy of Identity 3564 An overview of the required privacy and anonymity for users of a 3565 conferencing system are provided in the XCON Framework [RFC5239]. 3566 The security of the identity in the form of the XCON-USERID is 3567 provided in the CCMP protocol through the use of TLS. 3569 The conference server SHOULD provide mechanisms to ensure the privacy 3570 of the XCON-USERID. This is accomplished by the conference client 3571 manipulation of the "provide-anonymity" element defined in the XCON 3572 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 3573 anonymity" element controls the degree to which a user reveals their 3574 identity. The conference client MUST set the "provide-anonymity" 3575 element to "hidden" if the user does not want other participants to 3576 even be aware that there is an additional participant in the 3577 conference. The conference client MUST set the "provide-anonymity" 3578 field to "private" if the user wants to be entirely "anonymous" 3579 (i.e., other participants are aware that there is another 3580 participant, but have no information as to their identity). The 3581 conference client MUST set the "provide-anonymity" field to "semi- 3582 private" if their identity is only to be revealed to other 3583 participants or users that have a higher level authorization (e.g., a 3584 conferencing system can be configured such that an administrator can 3585 see all users). To provide the required privacy, the conference 3586 client SHOULD include the "provide-anonymity" element in the 3587 "confInfo" parameter in a CCMP confRequest message with an "update" 3588 or "create" operation or in the "userInfo" parameter in a CCMP 3589 userRequest message with an "update" or "create" operation, to ensure 3590 the user is provided the appropriate level of privacy. If the 3591 "provide-anonymity" element is not included in the conference object, 3592 then other users can see the participant's identity. 3594 11. XML Schema 3596 This section provides the XML schema definition of the "application/ 3597 ccmp+xml" format. 3599 3601 3610 3612 3615 3616 3618 3620 3621 3622 3624 3625 3627 3629 3631 3632 3634 3636 3638 3640 3642 3644 3645 3647 3649 3651 3652 3653 3655 3656 3658 3660 3661 3662 3664 3666 3669 3672 3674 3676 3678 3679 3680 3682 3684 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3697 3699 3700 3701 3703 3705 3706 3707 3709 3711 3712 3713 3714 3715 3716 3717 3718 3719 3721 3723 3725 3726 3727 3729 3731 3732 3733 3735 3737 3738 3739 3740 3741 3742 3744 3745 3746 3748 3750 3752 3753 3754 3756 3758 3759 3760 3762 3764 3765 3766 3767 3768 3769 3770 3771 3772 3774 3776 3778 3779 3780 3782 3784 3785 3786 3788 3790 3791 3792 3793 3794 3795 3796 3797 3798 3800 3802 3804 3805 3806 3808 3810 3811 3812 3814 3816 3817 3818 3819 3820 3821 3822 3823 3824 3826 3828 3830 3831 3832 3834 3836 3837 3838 3839 3841 3842 3843 3844 3845 3846 3847 3848 3849 3851 3853 3856 3857 3858 3860 3862 3863 3864 3866 3868 3869 3870 3871 3872 3873 3874 3875 3876 3878 3880 3883 3884 3885 3888 3890 3891 3892 3894 3896 3897 3898 3899 3900 3901 3902 3903 3904 3906 3908 3911 3912 3913 3915 3917 3918 3919 3921 3923 3924 3925 3926 3927 3928 3929 3930 3931 3933 3935 3938 3939 3940 3942 3944 3945 3946 3948 3950 3951 3952 3953 3954 3955 3956 3957 3958 3960 3962 3964 3965 3966 3968 3970 3971 3973 3975 3976 3977 3978 3979 3980 3982 3983 3985 3986 3987 3988 3989 3990 3991 3992 3993 3995 3997 3999 4000 4001 4003 4005 4006 4007 4009 4011 4012 4013 4014 4015 4016 4017 4018 4019 4021 4023 4025 4026 4027 4029 4032 4033 4034 4036 4038 4039 4040 4041 4042 4043 4044 4045 4046 4048 4050 4052 4053 4054 4056 4058 4059 4060 4062 4064 4065 4066 4067 4068 4069 4070 4071 4072 4074 4076 4078 4079 4080 4082 4084 4085 4086 4088 4090 4091 4092 4093 4094 4095 4096 4097 4098 4100 4102 4104 4105 4106 4108 4110 4111 4112 4114 4116 4117 4118 4119 4120 4121 4122 4123 4124 4126 4127 4129 4130 4131 4133 4135 4136 4137 4139 4141 4142 4143 4144 4145 4146 4147 4148 4149 4151 4153 4156 4157 4158 4160 4162 4163 4164 4166 4168 4169 4170 4171 4172 4173 4174 4176 4177 4179 4181 4184 4185 4186 4188 4190 4191 4192 4194 4196 4197 4198 4199 4200 4201 4202 4203 4204 4206 4208 4211 4212 4213 4215 4217 4218 4219 4221 4223 4224 4225 4226 4227 4228 4229 4230 4231 4233 4235 4238 4239 4240 4242 4244 4245 4246 4248 4250 4251 4252 4253 4254 4255 4256 4257 4258 4260 4262 4264 4265 4266 4268 4271 4273 4275 4277 4278 4279 4280 4281 4282 4283 4284 4285 4287 4289 4292 4293 4294 4296 4298 4299 4300 4302 4304 4306 4307 4308 4309 4310 4312 4314 4315 4316 4317 4318 4319 4320 4322 4324 4326 4327 4328 4330 4332 4334 4335 4336 4338 4340 4341 4342 4345 4348 4350 4351 4352 4354 4356 4357 4358 4361 4363 4364 4365 4367 4369 4370 4371 4374 4377 4378 4379 4381 4382 4383 4385 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4402 4404 4405 4406 4408 4409 4410 4412 4414 4415 4416 4419 4421 4422 4423 4425 4427 4428 4429 4430 4433 4434 4437 4439 4440 4441 4443 4445 Figure 30 4447 12. IANA Considerations 4449 This document registers a new XML namespace, a new XML schema, and 4450 the MIME type for the schema. This document also registers the 4451 "XCON" Application Service tag and the "CCMP" Application Protocol 4452 tag. This document also defines registries for the CCMP operation 4453 types and response codes. 4455 12.1. URN Sub-Namespace Registration 4457 This section registers a new XML namespace, 4458 ""urn:ietf:params:xml:ns:xcon:ccmp"". 4460 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 4461 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4462 Mary Barnes (mary.ietf.barnes@gmail.com). 4463 XML: 4465 BEGIN 4466 4467 4469 4470 4471 CCMP Messages 4472 4473 4474

Namespace for CCMP Messages

4475

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

4476 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4477 with the RFC number for this specification.]] 4478

See RFCXXXX.

4479 4480 4481 END 4483 12.2. XML Schema Registration 4485 This section registers an XML schema as per the guidelines in 4486 [RFC3688]. 4488 URI: urn:ietf:params:xml:schema:xcon:ccmp 4489 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4490 Barnes (mary.ietf.barnes@gmail.com). 4491 Schema: The XML for this schema can be found as the entirety of 4492 Section 11 of this document. 4494 12.3. MIME Media Type Registration for 'application/ccmp+xml' 4496 This section registers the "application/ccmp+xml" MIME type. 4498 To: ietf-types@iana.org 4499 Subject: Registration of MIME media type application/ccmp+xml 4500 MIME media type name: application 4501 MIME subtype name: ccmp+xml 4502 Required parameters: (none) 4503 Optional parameters: charset 4504 Same as the charset parameter of "application/xml" as specified in 4505 RFC 3023 [RFC3023], Section 3.2. 4506 Encoding considerations: Same as the encoding considerations of 4507 "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. 4508 Security considerations: This content type is designed to carry 4509 protocol data related to conference control. Some of the data 4510 could be considered private. This media type does not provide any 4511 protection and thus other mechanisms such as those described in 4512 Section 10 are required to protect the data. This media type does 4513 not contain executable content. 4514 Interoperability considerations: None. 4515 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 4516 replace XXXX with the RFC number for this specification.]] 4517 Applications which use this media type: Centralized Conferencing 4518 control clients and servers. 4519 Additional Information: Magic Number(s): (none) 4520 File extension(s): .ccmpxml 4521 Macintosh File Type Code(s): TEXT 4522 Person & email address to contact for further information: Mary 4523 Barnes 4524 Intended usage: LIMITED USE 4525 Author/Change controller: The IETF 4526 Other information: This media type is a specialization of 4527 application/xml [RFC3023], and many of the considerations 4528 described there also apply to application/ccmp+xml. 4530 12.4. DNS Registrations 4532 Section 12.4.1 defines an Application Service tag of "XCON", which is 4533 used to identify the centralized conferencing (XCON) server for a 4534 particular domain. The Application Protocol tag "CCMP", defined in 4535 Section 12.4.2, is used to identify an XCON server that understands 4536 the CCMP protocol. 4538 12.4.1. Registration of a Conference Control Server Application Service 4539 Tag 4541 This section registers a new S-NAPTR/U-NAPTR Application Service tag 4542 for XCON, as mandated by [RFC3958]. 4544 Application Service Tag: XCON 4546 Intended usage: Identifies a server that supports centralized 4547 conferencing. 4549 Defining publication: RFCXXXX 4550 Contact information: The authors of this document 4552 Author/Change controller: The IESG 4554 12.4.2. Registration of a Conference Control Server Application 4555 Protocol Tag for CCMP 4557 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 4558 for the CCMP protocol, as mandated by [RFC3958]. 4560 Application Service Tag: CCMP 4562 Intended Usage: Identifies the Centralized Conferencing (XCON) 4563 Manipulation Protocol. 4565 Applicable Service Tag(s): XCON 4567 Terminal NAPTR Record Type(s): U 4569 Defining Publication: RFCXXXX 4571 Contact Information: The authors of this document 4573 Author/Change Controller: The IESG 4575 12.5. CCMP Protocol Registry 4577 This document requests that the IANA create a new registry for the 4578 CCMP protocol including an initial registry for operation types and 4579 response codes. 4581 12.5.1. CCMP Message Types 4583 The CCMP messages are described in Section 4.1 and defined in the XML 4584 schema in Section 11. The following summarizes the requested 4585 registry: 4587 Related Registry: CCMP Message Types Registry 4588 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4589 with the RFC number for this specification.] 4590 Registration/Assignment Procedures: New CCMP message types are 4591 allocated on a specification required basis. 4592 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4593 Barnes (mary.ietf.barnes@gmail.com). 4595 This section pre-registers the following initial CCMP message types: 4597 optionsRequest: Used by a conference control client to query a 4598 conferencing system for its capabilities, in terms of supported 4599 messages (both standard and non-standard). 4600 optionsResponse: The optionsResponse returns a list of CCMP messages 4601 (both standard and non-standard) supported by the specific 4602 conference server. 4603 blueprintsRequest: Used by a conference control client to query a 4604 conferencing system for its capabilities, in terms of available 4605 conference blueprints. 4606 blueprintsResponse: The blueprintsResponse returns a list of 4607 blueprints supported by the specific conference server. 4608 confsRequest: Used by a conference control client to query a 4609 conferencing system for its scheduled/active conferences. 4610 confsResponse: The "confsResponse" returns the list of the currently 4611 activated/scheduled conferences at the server. 4612 confRequest: The "confRequest" is used to create a conference object 4613 and/or to request an operation on the conference object as a 4614 whole. 4615 confResponse: The "confResponse" indicates the result of the 4616 operation on the conference object as a whole. 4617 userRequest: The "userRequest" is used to request an operation on 4618 the "user" element in the conference object. 4619 userResponse: The "userResponse" indicates the result of the 4620 requested operation on the "user" element in the conference 4621 object. 4622 usersRequest This "usersRequest" is used to manipulate the "users" 4623 element in the conference object, including parameters such as the 4624 "allowed-users-list", "join-handling", etc. 4625 usersResponse: This "usersResponse" indicates the result of the 4626 request to manipulate the "users" element in the conference 4627 object. 4628 sidebarRequest: This "sidebarRequest" is used to retrieve the 4629 information related to a sidebar or to create, change or delete a 4630 specific sidebar. 4631 sidebarResponse: This "sidebarResponse" indicates the result of the 4632 sidebarRequest. 4634 12.5.2. CCMP Response Codes 4636 The following summarizes the requested registry for CCMP Response 4637 codes: 4639 Related Registry: CCMP Response Code Registry 4640 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4641 with the RFC number for this specification.] 4643 Registration/Assignment Procedures: New response codes are allocated 4644 on a first-come/first-serve basis with specification required. 4645 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4646 Barnes (mary.ietf.barnes@gmail.com). 4648 This section pre-registers the following thirteen initial response 4649 codes as described above in Section 4.1: 4651 200: This code indicates that the request was successfully 4652 processed. 4653 409: This code indicates that a requested "update" cannot be 4654 successfully completed by the server. An example of such 4655 situation is when the modification of an object cannot be applied 4656 due to conflicts arising at the server's side (e.g. because the 4657 client version of the object is an obsolete one and the requested 4658 modifications collide with the up-to-date state of the object 4659 stored at the server). 4660 400: This code indicates that the request was badly formed in some 4661 fashion. 4662 401: This code indicates that the user was not authorized for the 4663 specific operation on the conference object. 4664 403: This code indicates that the specific operation is not valid 4665 for the target conference object. 4666 404: This code indicates that the specific conference object was not 4667 found. 4668 420: This code is returned in answer to a "userRequest/create" 4669 operation, in the case of a third-party invite, when the 4670 "confUserID" (contained in the "entity" attribute of the 4671 "userInfo" parameter) of the user to be added is unknown. 4672 421: This code is returned in the case of requests in which the 4673 "confUserID" of the sender is invalid. 4674 422: This code is returned in response to all requests wishing to 4675 access/manipulate a password-protected conference object, when the 4676 "conference-password" parameter contained in the request is wrong. 4677 423: This code is returned in response to all requests wishing to 4678 access/manipulate a password-protected conference object, when the 4679 "conference-password" parameter is missing in the request. 4680 424: This code is returned in response whenever the server wants to 4681 authenticate the requestor through the "subject" parameter and 4682 such a parameter is not provided in the request. 4683 425: This code indicates that the conferencing system cannot delete 4684 the specific conference object because it is a parent for another 4685 conference object. 4686 426: This code indicates that the target conference object cannot be 4687 changed (e.g., due to policies, roles, privileges, etc.). 4689 510: This code indicates that the request could not be processed 4690 within a reasonable time, with the time specific to a conferencing 4691 system implementation. 4692 500: This code indicates that the conferencing system experienced 4693 some sort of internal error. 4694 501: This code indicates that the specific operation is not 4695 implemented on that conferencing system. 4697 13. Acknowledgments 4699 The authors appreciate the feedback provided by Dave Morgan, Pierre 4700 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 4701 Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special 4702 thanks go to Roberta Presta for her invaluable contribution to this 4703 document. Roberta has worked on the specification of the CCMP 4704 protocol at the University of Napoli for the preparation of her 4705 Master thesis. She has also implemented the CCMP prototype used for 4706 the trials and from which the dumps provided in Section 6 have been 4707 extracted. 4709 14. Changes since last Version 4711 NOTE TO THE RFC-Editor: Please remove this section prior to 4712 publication as an RFC. 4714 The following summarizes the changes between the WG 03 and the 04: 4716 1. Re-organized document based on feedback from Richard Barnes. 4717 2. Editorial clarifications and nits, including those identified by 4718 Richard and Simo Veikkolainen. 4720 The following summarizes the changes between the WG 07 and the 08: 4722 1. Added a new "optionsRequest" message (and related 4723 "optionsResponse" message) to the list of CCMP messages. 4724 2. Clarified discussion about notifications management, by 4725 clarifying they are out of the scope of the present document, but 4726 at the same time providing some pointers to potential ways for 4727 implementing them. 4728 3. Clarified discussion about policies in XCON, by clarifying they 4729 are out of the scope of the present document, but at the same 4730 time providing some pointers to potential ways for implementing 4731 them. 4732 4. Corrected minor typos in the schema. 4734 5. Corrected schema definitions which brought to Unique Particle 4735 Attribution exceptions. 4736 6. Added the newly defined "optionsRequest" and "optionsResponse" 4737 messages to the schema. 4738 7. Misc editorial nits... 4740 The following summarizes the changes between the WG 08 and the 09: 4742 1. Added a section on the extendedRequest/extendedResponse message 4743 pair. 4744 2. Added a section on the optionsRequest/optionsResponse message 4745 pair. 4746 3. Added an example sub-section about the use of the optionsRequest/ 4747 optionsResponse message pair. 4748 4. Added an example sub-section about the use of the 4749 extendedRequest/extendedResponse message pair. 4750 5. Updated the schema in order to reflect the latest modifications 4751 and add-ons. 4752 6. Misc editorial nits... 4754 15. References 4756 15.1. Normative References 4758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4759 Requirement Levels", BCP 14, RFC 2119, March 1997. 4761 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4762 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4763 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4765 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 4766 Leach, P., Luotonen, A., and L. Stewart, "HTTP 4767 Authentication: Basic and Digest Access Authentication", 4768 RFC 2617, June 1999. 4770 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 4772 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 4773 Mechanism", RFC 2965, October 2000. 4775 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4776 January 2004. 4778 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 4779 Centralized Conferencing", RFC 5239, June 2008. 4781 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4782 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 4784 [I-D.ietf-xcon-common-data-model] 4785 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 4786 "Conference Information Data Model for Centralized 4787 Conferencing (XCON)", draft-ietf-xcon-common-data-model-20 4788 (work in progress), October 2010. 4790 15.2. Informative References 4792 [REST] Fielding, "Architectural Styles and the Design of Network- 4793 based Software Architectures", 2000. 4795 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 4796 Types", RFC 3023, January 2001. 4798 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4799 A., Peterson, J., Sparks, R., Handley, M., and E. 4800 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4801 June 2002. 4803 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 4804 Service Location Using SRV RRs and the Dynamic Delegation 4805 Discovery Service (DDDS)", RFC 3958, January 2005. 4807 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 4808 Control Protocol (BFCP)", RFC 4582, November 2006. 4810 [I-D.ietf-xcon-event-package] 4811 Camarillo, G., Srinivasan, S., Even, R., and J. 4812 Urpalainen, "Conference Event Package Data Format 4813 Extension for Centralized Conferencing (XCON)", 4814 draft-ietf-xcon-event-package-01 (work in progress), 4815 September 2008. 4817 [W3C.REC-soap12-part1-20030624] 4818 Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2 4819 Part 1: Messaging Framework", World Wide Web Consortium 4820 FirstEdition REC-soap12-part1-20030624, June 2003, 4821 . 4823 [W3C.REC-soap12-part2-20030624] 4824 Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2 4825 Part 2: Adjuncts", World Wide Web Consortium 4826 FirstEdition REC-soap12-part2-20030624, June 2003, 4827 . 4829 Appendix A. Appendix A: Other protocol models and transports considered 4830 for CCMP 4832 The operations on the objects can be implemented in at least two 4833 different ways, namely as remote procedure calls - using SOAP as 4834 described in Appendix A.1 and by defining resources following a 4835 RESTful architecture Appendix A.2. 4837 In both approaches, servers will have to recreate their internal 4838 state representation of the object with each update request, checking 4839 parameters and triggering function invocations. In the SOAP 4840 approach, it would be possible to describe a separate operation for 4841 each atomic element, but that would greatly increase the complexity 4842 of the protocol. A coarser-grained approach to the CCMP does require 4843 that the server process XML elements in updates that have not changed 4844 and that there can be multiple changes in one update. 4846 For CCMP, the resource (REST) model might appear more attractive, 4847 since the conference operations fit the CRUD approach. 4849 Neither of these approaches were considered ideal as SOAP was not 4850 considered to be general purpose enough for use in a broad range of 4851 operational environments. It is quite awkward to apply a RESTful 4852 approach since the CCMP requires a more complex request/response 4853 protocol in order to maintain the data both in the server and at the 4854 client. This doesn't map very elegantly to the basic request/ 4855 response model, whereby a response typically indicates whether the 4856 request was successful or not, rather than providing additional data 4857 to maintain the synchronization between the client and server data. 4858 In addition, the CCMP clients may also receive the data in 4859 Notifications. While the notification method or protocol used by 4860 some conferencing clients can be independent of the CCMP, the same 4861 data in the server is used for both the CCMP and Notifications - this 4862 requires a server application above the transport layer (e.g., HTTP) 4863 for maintaining the data, which in the CCMP model is transparent to 4864 the transport protocol. 4866 A.1. Using SOAP for the CCMP 4868 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 4869 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 4870 -soap12-part2-20030624]), where conferences and the other objects are 4871 modeled as services with associated operations. Conferences and 4872 other objects are selected by their own local identifiers, such as 4873 email-like names for users. This approach has the advantage that it 4874 can easily define atomic operations that have well-defined error 4875 conditions. 4877 All SOAP operations would use a single HTTP verb. While the RESTful 4878 approach requires the use of a URI for each object, SOAP can use any 4879 token. 4881 A.2. A RESTful approach for the CCMP 4883 Conference objects can also be modeled as resources identified by 4884 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 4885 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 4886 changing objects and DELETE for deleting them. Many of the objects, 4887 such as conferences, already have natural URIs. 4889 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 4890 design pattern. The basic CRUD operations are used to manipulate 4891 conference objects, which are XML documents containing the 4892 information characterizing a specified conference instance, be it an 4893 active conference or a conference blueprint used by the conference 4894 server to create new conference instances through a simple clone 4895 operation. 4897 Following the CRUD approach, CCMP could use a general-purpose 4898 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 4899 encoded data objects defined in the Conference Information Data Model 4900 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 4902 Following on the CRUD approach, CCMP could follow the well-known REST 4903 (REpresentational State Transfer) architectural style [REST]. The 4904 CCMP could map onto the REST philosophy, by specifying resource URIs, 4905 resource formats, methods supported at each URI and status codes that 4906 have to be returned when a certain method is invoked on a specific 4907 URI. A REST-style approach must ensure sure that all operations can 4908 be mapped to HTTP operations. 4910 The following summarizes the specific HTTP method that could be used 4911 for each of the CCMP Requests: 4913 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 4914 obtain data about conference objects in the form of XML data model 4915 documents. 4917 Create: HTTP PUT could be used to create a new object as identified 4918 by the XCON-URI or XCON-USERID. 4920 Change: Either HTTP PATCH or HTTP POST could be used to change the 4921 conference object identified by the XCON-URI. 4923 Delete: HTTP DELETE could be used to delete conference objects and 4924 parameters within conference objects identified by the XCON-URI. 4926 Authors' Addresses 4928 Mary Barnes 4929 Polycom 4930 TX 4931 US 4933 Email: mary.ietf.barnes@gmail.com 4935 Chris Boulton 4936 NS-Technologies 4938 Email: chris@ns-technologies.com 4940 Simon Pietro Romano 4941 University of Napoli 4942 Via Claudio 21 4943 Napoli 80125 4944 Italy 4946 Email: spromano@unina.it 4948 Henning Schulzrinne 4949 Columbia University 4950 Department of Computer Science 4951 450 Computer Science Building 4952 New York, NY 10027 4954 Email: hgs+xcon@cs.columbia.edu