idnits 2.17.1 draft-ietf-xcon-ccmp-10.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 (July 12, 2010) is 5037 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 4270, 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-19 -- 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: January 13, 2011 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 July 12, 2010 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-10 15 Abstract 17 The Centralized Conferencing Manipulation Protocol (CCMP) allows an 18 XCON conferencing system client to create, retrieve, change, and 19 delete objects that describe a centralized conference. CCMP is a 20 means to control basic and advanced conference features such as 21 conference state and capabilities, participants, relative roles, and 22 details. CCMP is a state-less, XML-based, client server protocol 23 that carries, in its request and response messages, conference 24 information in the form of XML documents and fragments conforming to 25 the centralized conferencing data model schema. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 13, 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 . . . . 36 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 . . . . . . . . . 45 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 . . . . . . . 67 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 . . . . . . . . . . 78 105 10.3. Security and Privacy of Identity . . . . . . . . . . . . 79 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 . . . . . . . . . . 100 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 . . . . . . . . . . . . . . . . 106 126 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 127 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 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. 183 3. XCON Conference Control System Architecture 185 CCMP supports the XCON framework . Figure 1 depicts a subset of the 186 "Conferencing System Logical Decomposition" architecture from the 187 XCON framework document. It illustrates the role that CCMP assumes 188 within the overall centralized architecture. 190 ........................................................ 191 . Conferencing System . 192 . . 193 . +---------------------------------------+ . 194 . | C O N F E R E N C E O B J E C T | . 195 . +-+-------------------------------------+ | . 196 . | C O N F E R E N C E O B J E C T | | . 197 . +-+-------------------------------------+ | | . 198 . | C O N F E R E N C E O B J E C T | | | . 199 . | | |-+ . 200 . | |-+ . 201 . +---------------------------------------+ . 202 . ^ . 203 . | . 204 . v . 205 . +-------------------+ . 206 . | Conference Control| . 207 . | Server | . 208 . +-------------------+ . 209 . ^ . 210 .........................|.............................. 211 | 212 |Centralized 213 |Conferencing 214 |Manipulation 215 |Protocol 216 | 217 .........................|.............................. 218 . V . 219 . +----------------+ . 220 . | Conference | . 221 . | Control | . 222 . | Client | . 223 . +----------------+ . 224 . . 225 . Conferencing Client . 226 ........................................................ 228 Figure 1: Conference Client Interaction 230 CCMP serves as the Conference Control Protocol, allowing the 231 conference control client to interface with the conference object 232 maintained by the conferencing system, as represented in Figure 1. 233 Conference Control is one part of functionality for advanced 234 conferencing supported by a conferencing client. Other functions are 235 discussed in the XCON framework and related documents. 237 Conference object and conference users do represent key elements 238 involved in Conference Control Protocol operations. Their 239 identifiers, respectively the conference XCON-URI and the 240 conferencing client XCON-USERID, and their XML representations 241 compliant with the XML Schema defined in the XCON data model are 242 widely used for creating the CCMP requests and responses. The main 243 conference objects and users features envisioned by the XCON 244 framework are briefly described in the following subsections. 246 3.1. Conference Objects 248 Conference objects feature a simple dynamic inheritance-and-override 249 mechanism. Conference objects are linked into a tree known as 250 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 251 node inherits attributes from its parent node. The roots of these 252 inheritance trees are conference templates also known as 253 "blueprints". Nodes in the inheritance tree can be active 254 conferences or simply descriptions that do not currently have any 255 resources associated with them (conference reservations). An object 256 can mark certain of its properties as unalterable, so that they 257 cannot be overridden. It is envisaged by the framework that a client 258 may specify a parent object (a conference or blueprint) from which 259 the conference to be created has to inherit values by the mean of the 260 Conference Control Protocol. 262 Conference objects are uniquely identified by the XCON-URI within the 263 scope of the conferencing system. Such identifier is introduced in 264 the XCON framework and defined in the XCON common data model. 266 Conference objects are comprehensively represented through XML 267 documents compliant with the XML Schema defined in the XCON data 268 model [I-D.ietf-xcon-common-data-model]. The root element of such 269 documents, called "", is of type "conference-type". 270 It encompasses other XML elements describing different conference 271 features and users as well. By the mean of CCMP, conferencing 272 clients can use such XML structures to express their preferences in 273 creation or update. A conferencing server can convey conference 274 information of such a form back to the clients. 276 3.2. Conference Users 278 Each conference can have zero or more users. All conference 279 participants are users, but some users may have only administrative 280 functions and do not contribute or receive media. Users are added 281 one user at a time to simplify error reporting. When a conference is 282 cloned from a parent object, users are inherited as well, so that it 283 is easy to set up a conference that has the same set of participants 284 or a common administrator. The Conference Control Server creates 285 individual users, assigning them a unique Conference User Identifier 286 (XCON-USERID). The XCON-USERID as identifier of each conferencing 287 system client is introduced in the XCON framework and defined in the 288 XCON common data model. Each CCMP request, with an exception pointed 289 out in Section 5.3.6 representing the case of a user at his first 290 entrance in the system as a conference participant, must carry the 291 XCON-USERID of the requestor in the proper "confUserID" parameter. 293 The XCON-USERID acts as a pointer to the user's profile as a 294 conference actor, e.g. her signalling URI and other XCON protocol 295 URIs in general, her role (moderator, participant, observer, etc.), 296 her display text, her joining information and so on. A variety of 297 elements defined in the common element as specified 298 in the XCON data model are used to describe the users related to a 299 conference, in the first place the element, as well as each 300 element included in it. For example, it is possible to 301 determine how a specific user expects and is allowed to join a 302 conference by looking at the in : each 303 element involved in such a list represents a user and shows 304 a "method" attribute defining how the user is expected to join the 305 conference, i.e. "dial-in" for users that are allowed to dial, "dial- 306 out" for users that the conference focus will be trying to reach 307 (with "dial-in" being the default mode). If the conference is 308 currently active, dial-out users are contacted immediately; 309 otherwise, they are contacted at the start of the conference. The 310 CCMP, acting as the Conference Control Protocol, provides a means to 311 manipulate these and other kinds of user-related features. 313 As a consequence of an explicit user registration to a specific XCON 314 conferencing system, conferencing clients are usually provided 315 (besides the XCON-USERID) with log-in credentials (i.e. username and 316 password). Such credentials can be used to authenticate the XCON 317 aware client issuing CCMP requests. To this purpose, both username 318 and password should be carried in a CCMP request as part of the 319 "subject" parameter whenever a registered conferencing client wishes 320 to contact a CCMP server. The CCMP does not look after users 321 subscriptions at the conference server; hence, it does not provide 322 any specific mechanism allowing clients to register their 323 conferencing accounts. The "subject" parameter is just used for 324 carrying authentication data associated with pre-registered clients. 326 4. Protocol Overview 328 CCMP is a client-server, XML-based protocol, which has been 329 specifically conceived to provide users with the necessary means for 330 the creation, retrieval, modification and deletion of conference 331 objects. CCMP is also state-less, which means implementations can 332 safely handle transactions independently from each other. 333 Conference-related information is encapsulated into CCMP messages in 334 the form of XML documents or XML document fragments compliant with 335 the XCON data model representation. 337 Section 4.1 specifies the basic operations that can create, retrieve, 338 modify and delete conference-related information in a centralized 339 conference. The core set of objects manipulated in the CCMP protocol 340 includes conference blueprints, the conference object, users, and 341 sidebars. 343 CCMP has been conceived as completely independent from underlying 344 protocols, which means that there can be different ways to carry CCMP 345 messages across the network, from a conferencing client to a 346 conferencing server. Nevertheless, it is recommended to use HTTP as 347 a transport solution, including CCMP requests in HTTP POST messages 348 and CCMP responses in HTTP 200 OK replies. Implementation details 349 are presented in Section 4.2 351 4.1. Protocol Operations 353 The main operations provided by CCMP belong in four general 354 categories: 356 create: for the creation of a conference, a conference user, a 357 sidebar, or a blueprint. 358 retrieve: to get information about the current state of either a 359 conference object (be it an actual conference or a blueprint, or a 360 sidebar) or a conference user. A retrieve operation can also be 361 used to obtain the XCON-URIs of the current conferences (active or 362 registered) handled by the conferencing server and/or the 363 available blueprints. 364 update: to modify the current features of a specified conference or 365 conference user. 366 delete: to remove from the system a conference object or a 367 conference user. 369 Thus, the main targets of CCMP operations are: 371 o conference objects associated with either active or registered 372 conferences, 373 o conference objects associated with blueprints, 374 o conference objects associated with sidebars, both embedded in the 375 main conference (i.e. elements in ) and 376 external to it (i.e. whose xcon-uris are included in the 377 elements of ), 379 o elements associated with conference users, 380 o the list of XCON-URIs related to conferences and blueprints 381 available at the server, for which only retrieval operations are 382 allowed. 384 Each operation in the protocol model is atomic and either succeeds or 385 fails as a whole. The conference server must ensure that the 386 operations are atomic in that the operation invoked by a specific 387 conference client completes prior to another client's operation on 388 the same conference object. The details for this data locking 389 functionality are out of scope for the CCMP protocol specification 390 and are implementation specific for a conference server. Thus, the 391 conference server first checks all the parameters, before making any 392 changes to the internal representation of the conference object. For 393 example, it would be undesirable to change the of the 394 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 396 can modify the same conference objects, conference clients should 397 first obtain the current object from the conference server and then 398 update the relevant data elements in the conference object prior to 399 invoking a specific operation on the conference server. In order to 400 effectively manage modifications to conference data, a versioning 401 approach is exploited in the CCMP. More precisely, each conference 402 object is associated with a version number indicating the most up to 403 date view of the conference at the server's side. Such version 404 number is reported to the clients when answering their requests. A 405 client willing to make modifications to a conference object has to 406 send an update message to the server. In case the modifications are 407 all successfully applied, the server sends back to the client a "200" 408 response which also carries information about the current server-side 409 version of the modified object. With such approach, a client which 410 is working on version "X" of a conference object and finds inside a 411 "200" response a version number which is "X+1" can be sure that the 412 version it was aware of was the most up to date. On the other hand, 413 if the "200" response carries back a version which is at least "X+2", 414 the client can detect that the object that has been modified at the 415 server's side was more up to date than the one it was working upon. 416 This is clearly due to the effect of concurrent modification requests 417 issued by independent clients. Hence, for the sake of having 418 available the latest version of the modified object, the client can 419 send to the conference server a further "retrieve" request. In no 420 case a copy of the conference object available at the server is 421 returned to the client as part of the update response message. Such 422 a copy can always be obtained through an ad-hoc "retrieve" message. 424 Based on the above considerations, all CCMP response messages 425 carrying in their body a conference document (or a fragment of it) 426 must contain a "version" parameter. This does not hold for request 427 messages, for which the "version" parameter is not at all required, 428 since it represents useless information for the server: as long as 429 the required modifications can be applied to the target conference 430 object with no conflicts, the server does not care whether or not the 431 client had an up to date view of the information stored at its side. 432 This said, it stands clear that a client which has subscribed at the 433 server, through the XCON event package [I-D.ietf-xcon-event-package], 434 to notifications about conference object modifications, will always 435 have the most up to date version of that object available at his 436 side. 438 A final consideration concerns the relation between the CCMP and the 439 main entities it manages, i.e. conference objects. Such objects have 440 to be compliant with the XCON data-model, which identifies some 441 elements/attributes as mandatory. From the CCMP standpoint this can 442 become a problem in cases of client-initiated operations, like the 443 creation/update of conference objects. In such cases, not all of the 444 mandatory data can be known in advance to the client issuing a CCMP 445 request. As an example, a client has no means to know, at the time 446 it issues a conference creation request, the XCON-URI that the server 447 will assign to the yet-to-be-created conference and hence it is not 448 able to appropriately fill with that value the mandatory "entity" 449 attribute of the conference document contained in the request. To 450 solve this kind of issues, the CCMP will fill all mandatory data 451 model fields, for which no value is available at the client at the 452 time the request is constructed, with fake values in the form of 453 wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental 454 index initialized to a value of 1). Upon reception of the mentioned 455 kinds of requests, the server will: (i) generate the proper 456 identifier(s); (ii) produce a response in which the received fake 457 identifier(s) carried in the request has (have) been replaced by the 458 newly created one(s). With this approach we maintain compatibility 459 with the data model requirements, at the same time allowing for 460 client-initiated manipulation of conference objects at the server's 461 side (which is, by the way, one of the main goals for which the CCMP 462 protocol has been conceived at the outset). 464 4.2. Implementation Approach 466 There have been a number of different proposals as to the most 467 suitable implementation solution for the CCMP. A non-exhaustive 468 summary of the most interesting ones is provided in Appendix A. The 469 solution for the CCMP defined in this document is viewed as a good 470 compromise amongst the most notable past candidates and is referred 471 to as "HTTP single-verb transport plus CCMP body". With this 472 approach, CCMP is able to take advantage of existing HTTP 473 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 474 transport (i.e. a single transaction type for each request/response 475 pair); this allows decoupling CCMP messages from HTTP messages. 476 Similarly, as with any RESTful approach, CCMP messages are inserted 477 directly in the body of HTTP messages, thus avoiding any unnecessary 478 processing and communication burden associated with further 479 intermediaries. With this approach, no modification to the CCMP 480 messages/operations is required to use a different transport 481 protocol. 483 The remainder of this document focuses on the selected approach. The 484 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 485 POST operations and retrieves responses from the body of HTTP "200 486 OK" messages. CCMP messages have a MIME-type of "application/ 487 ccmp+xml", which appears inside the "Content-Type" and "Accept" 488 fields of HTTP requests and responses. Section 9 provides the 489 complete requirements for an HTTP implementation to support the CCMP. 491 5. CCMP messages 493 CCMP messages are either requests or responses. The general CCMP 494 request message is defined in Section 5.1. The general CCMP response 495 message is defined in Section 5.2. The details of the specific 496 message type which is carried in the CCMP request and response 497 messages are described in Section 5.3. CCMP response codes are 498 listed in Section 5.4 500 5.1. CCMP Request Message Type 502 A CCMP request message is comprised of the following parameters: 504 subject: An optional parameter containing username and password of 505 the client registered at the conferencing system. Each user who 506 subscribes to the conferencing system is assumed to be equipped 507 with those credentials and SHOULD enclose them in each CCMP 508 request she issues. These fields can be used to control that the 509 user sending the CCMP request has the authority to perform the 510 entailed operation. The same fields can also be exploited to 511 carry out other Authorization, Authentication and Accounting (AAA) 512 procedures. 513 confUserID: An optional parameter containing the XCON-USERID of the 514 client. The XCON-USERID is used to identify any conferencing 515 client within the context of the conferencing system and it is 516 assinged by the conferencing server at each conferencing client 517 who interacts with it. The "confUserID" parameter is REQUIRED in 518 the CCMP request and response messages with the exception of the 519 case of a user who has no XCON-USERID and who wants to enter, via 520 CCMP, a conference whose identifier is known. In such case, a 521 side-effect of the request is that the user is provided with an 522 appropriate XCON-USERID. An example of the above mentioned case 523 will be provided in Section 5.3.6. 524 confObjID: An optional parameter containing the XCON-URI of the 525 target conference object. 526 operation: An optional parameter refining the type of specialized 527 request message. The "operation" parameter is REQUIRED in all 528 requests except for the "blueprintsRequest" and "confsRequest" 529 specialized messages. 530 conference-password: An optional parameter that MUST be inserted in 531 all requests whose target conference object is password-protected 532 (as per the element in 533 [I-D.ietf-xcon-common-data-model]). 534 specialized request message: This is specialization of the generic 535 request message (e.g., blueprintsRequest), containing parameters 536 that are dependent on the specific request sent to the server. A 537 specialized request message MUST be included in the CCMP request 538 message. The details for the specialized messages and associated 539 parameters are provided in Section 5.3. 541 543 545 547 548 549 551 552 554 556 558 559 561 563 565 567 569 571 572 573 575 Figure 2: Structure of CCMP Request messages 577 5.2. CCMP Response Message Type 579 A CCMP response message is comprised of the following parameters: 581 confUserID: A mandatory parameter in CCMP response messages 582 containing the XCON-USERID of the conferencing client who issued 583 the CCMP request message. 585 confObjID: An optional parameter containing the XCON-URI of the 586 target conference object. 587 operation: An optional parameter for CCMP response messages. This 588 parameter is REQUIRED in all responses except for the 589 "blueprintsResponse" and "confsResponse" specialized messages. 590 response-code: A mandatory parameter containing the response code 591 associated with the request. The response code MUST be chosen 592 from the codes listed in Section 5.4. 593 response-string: An optional reason string associated with the 594 response. In case of an error, in particular, such string can be 595 used to provide the client with detailed information about the 596 error itself. 597 version: An optional parameter reflecting the current version number 598 of the conference object referred by the confObjID. This number 599 is contained in the "version" attribute of the 600 element related to that conference. 601 specialized response message: This is specialization of the generic 602 response message, containing parameters that are dependent on the 603 specific request sent to the server (e.g., blueprintsResponse). A 604 specialized response message SHOULD be included in the CCMP 605 response message, except in an error situation where the CCMP 606 request message did not contain a valid specialized message. In 607 this case, the conference server MUST return a "response-code" of 608 "400". The details for the specialized messages and associated 609 parameters are provided in Section 5.3. 611 613 615 617 618 619 621 622 624 626 628 629 631 633 635 637 639 641 643 644 645 647 Figure 3: Structure of CCMP Response message 649 5.3. Detailed messages 651 Based on the request and response message structures described in 652 Section 5.1 and Section 5.2, the following summarizes the specialized 653 CCMP request/response types described in this document: 655 1. blueprintsRequest/blueprintsResponse 656 2. confsRequest/confsResponse 657 3. blueprintRequest/blueprintResponse 658 4. confRequest/confResponse 659 5. usersRequest/usersResponse 660 6. userRequest/userResponse 661 7. sidebarsByValRequest/sidebarsByValResponse 662 8. sidebarsByRefRequest/sidebarsByRefResponse 663 9. sidebarByValRequest/sidebarByValResponse 664 10. sidebarByRefRequest/sidebarByRefResponse 665 11. extendedRequest/extendedResponse 666 12. optionsRequest/optionsResponse 668 These CCMP request/response pairs use the fundamental CCMP operations 669 as defined in Section 4.1 to manipulate the conference data. The 670 optionsRequest/optionsResponse message pair deserves a specific 671 discussion, since it is not used for manipulating information about 672 either conferences or conference users, but rather to retrieve 673 general information about conference server capabilities, in terms of 674 standard CCMP messages it supports, plus potential extension messages 675 it understands, as it will be further explained in Section 5.3.12. 676 Table 1 summarizes the remaining CCMP operations and corresponding 677 actions that are valid for a specific CCMP request type, noting that 678 neither the blueprintsRequest/blueprintsResponse nor confsRequest/ 679 confsResponse require an "operation" parameter. The corresponding 680 response MUST contain the same operation. Note that some entries are 681 labeled "N/A" indicating the operation is invalid for that request 682 type. In the case of an "N/A*", the operation MAY be allowed for 683 specific privileged users or system administrators, but is not part 684 of the functionality included in this document. 686 +---------------+------------+------------+------------+------------+ 687 | Operation | Retrieve | Create | Update | Delete | 688 | ------------- | | | | | 689 | Request Type | | | | | 690 +---------------+------------+------------+------------+------------+ 691 | blueprints | Get list | N/A | N/A | N/A | 692 | Request | of | | | | 693 | | blueprints | | | | 694 | ------------- | ---------- | ---------- | ---------- | ---------- | 695 | blueprint | Get | N/A* | N/A* | N/A* | 696 | Request | blueprint | | | | 697 | ------------- | ---------- | ---------- | ---------- | ---------- | 698 | confsRequest | Get list | N/A | N/A | N/A | 699 | | of confs | | | | 700 | ------------- | ---------- | ---------- | ---------- | ---------- | 701 | confRequest | Gets | Creates | Changes | Deletes | 702 | | conference | conference | conference | conference | 703 | | object | object | object | object | 704 | ------------- | ---------- | ---------- | ---------- | ---------- | 705 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 706 | | | | | | 707 | ------------- | ---------- | ---------- | ---------- | ---------- | 708 | userRequest | Gets | Adds a | Changes | Deletes | 709 | | specified | to | specified | specified | 710 | | | a conf | | | 711 | | | (***) | | | 712 | ------------- | ---------- | ---------- | ---------- | ---------- | 713 | sidebarsByVal | Gets | N/A | N/A | N/A | 714 | Request | | | | | 716 | ------------- | ---------- | ---------- | ---------- | ---------- | 717 | sidebarsByRef | Gets | N/A | N/A | N/A | 718 | Request | | | | | 720 | ------------- | ---------- | ---------- | ---------- | ---------- | 721 | sidebarByVal | Gets | Creates | Changes | Deletes | 722 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 723 | | by-val | by-val | by-val | by-val | 724 | ------------- | ---------- | ---------- | ---------- | ---------- | 725 | sidebarByRef | Gets | Creates | Changes | Deletes | 726 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 727 | | by-ref | by-ref | by-ref | by-ref | 728 +---------------+------------+------------+------------+------------+ 730 Table 1: Request Type Operation Specific Processing 732 (**): These operations are not allowed for a usersRequest message, 733 since the section, which is the target element of such a 734 request, is created and removed in conjuntcion with, respectively, 735 the creation and deletion of the associated conference document. 736 Thus, "update" and "retrieve" are the only semantically correct 737 operations for such message. 739 (***): This operation can involve the creation of an XCON-USERID, if 740 the sender does not add it in the "confUserID" parameter, and/or if 741 the "entity" field of the "userInfo" parameter is void. 743 Additional parameters included in the specialized CCMP request/ 744 response messages are detailed in the subsequent sections. 746 5.3.1. blueprintsRequest and blueprintsResponse 748 A "blueprintsRequest" (Figure 4) message is sent to request the list 749 of XCON-URIs associated with the available blueprints from the 750 conference server. Such URIs can be subsequently used by the client 751 to access detailed information about a specified blueprint with a 752 specific blueprintRequest message per Section 5.3.3. The 753 "confUserID" parameter MUST be included in every blueprintsRequest/ 754 Response message and reflect the XCON-USERID of the conferencing 755 client issuing the request. A blueprintsRequest message REQUIRES no 756 "confObjID" and "operation" parameters, since it is not targetted to 757 a specific conference instance and it is conceived as a "retrieve- 758 only" request. In order to obtain a specific subset of the available 759 blueprints, a client may specify a selection filter providing an 760 appropriate xpath query in the optional "xpathFilter" parameter of 761 the request. For example, to select blueprints having both audio and 762 video stream support, a possible xpathFilter value could be: "/ 763 conference-info[conference-description/available-media/entry/ 764 type='audio' and conference-description/available-media/entry/ 765 type='video']". 767 The associated "blueprintsResponse" message SHOULD contain, as shown 768 in Figure 4, a "blueprintsInfo" parameter containing the above 769 mentioned XCON-URI list. 771 773 774 775 776 777 778 779 781 782 784 786 788 789 790 791 793 794 795 797 799 800 801 802 803 804 805 806 807 809 811 813 814 815 817 819 820 821 823 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 824 messages 826 5.3.2. confsRequest and confsResponse 828 A "confsRequest" message is used to retrieve, from the server, the 829 list of XCON-URIs associated with active and registered conferences 830 currently handled by the conferencing system. The "confUserID" 831 parameter MUST be included in every confsRequest/Response message and 832 reflect the XCON-USERID of the conferencing client issuing the 833 request. The "confObjID" parameter MUST NOT be included in the 834 confsRequest message. The "confsRequest" message is of a "retrieve- 835 only" type, since the sole purpose is to collect information 836 available at the conference server. Thus, an "operation" parameter 837 MUST NOT be included in a "confsRequest" message. In order to 838 retrieve a specific subset of the available conferences, a client may 839 specify a selection filter providing an appropriate xpath query in 840 the optional "xpathFilter" parameter of the request. For example, to 841 select only the registered conferences, a possible xpathFilter value 842 could be: "/conference-info[conference-description/conference-state/ 843 active='false']". The associated "confsResponse" message SHOULD 844 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 845 upon receipt of the response message, can interact with the available 846 conference objects through further CCMP messages. 848 850 851 852 853 854 855 856 857 858 860 862 864 865 866 867 869 870 871 872 874 875 876 877 878 879 880 881 882 884 886 888 889 890 892 894 895 896 898 Figure 5: Structure of the confsRequest and confsResponse messages 900 5.3.3. blueprintRequest and blueprintResponse 902 Through a "blueprintRequest", a client can manipulate the conference 903 object associated with a specified blueprint. Further than the 904 "confUserID" parameter, the request MUST include the "confObjID" and 905 the "operation" one. Again, the "confUserID" parameter MUST be 906 included in every blueprintRequest/Response message and reflect the 907 XCON-USERID of the conferencing client issuing the request. The 908 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 909 which might have been previously retrieved through a 910 "blueprintsRequest" message. 912 The blueprintRequest message SHOULD NOT contain an "operation" 913 parameter other than "retrieve". The "create", "update" and "delete" 914 operations SHOULD NOT be included in a "blueprintRequest" message 915 except in the case of privileged users (e.g. the conference server 916 administration staff), who might authenticate themselves by the mean 917 of the "subject" request parameter. 919 A blueprintRequest/retrieve carrying a "confObjID" which is not 920 associated with one of the available system's blueprints will 921 generate, on the server's side, a blueprintResponse message 922 containing a "404" error code. This holds also for the case in which 923 the mentioned "confObjID" is related to an existing conference 924 document stored at the server, but associated with an actual 925 conference (be it active or registered) or with a sidebar rather than 926 a blueprint. 928 In the case of "response-code" of "200" for a "retrieve" operation, 929 the "blueprintInfo" parameter MUST be included in the 930 "blueprintResponse" message. The "blueprintInfo" parameter contains 931 the conference document associated with the blueprint as identified 932 by the "confObjID" parameter specified in the blueprintRequest. 934 936 937 938 939 940 941 942 943 944 946 948 950 951 952 954 956 957 958 960 962 963 964 965 966 967 968 969 970 972 974 976 977 978 980 982 983 984 986 Figure 6: Structure of the blueprintRequest and blueprintResponse 987 messages 989 5.3.4. confRequest and confResponse 991 With a "confRequest" message, CCMP clients can manipulate conference 992 objects associated with either active or registered conferences. The 993 "confUserID" parameter MUST be included in every confRequest/Response 994 message and reflect the XCON-USERID of the conferencing client 995 issuing the request. ConfRequest and confResponse messages MUST also 996 include an "operation" parameter. ConfResponse messages MUST return 997 to the requestor a "response-code" and MAY contain a "response- 998 string" explaining it. Depending upon the type of "operation", a 999 "confObjID" and "confInfo" parameter MAY be included in the 1000 confRequest and response. The requirements for inclusion of 1001 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1002 messages and are detailed below for each "operation" case. 1004 The creation case deserves care. To create a new conference through 1005 a "confRequest" message, two approaches can be considered: 1007 1. Creation through explicit cloning: the "confObjID" parameter MUST 1008 contain the XCON-URI of the blueprint or of the conference to be 1009 cloned, while the "confInfo" parameter MUST NOT be included in 1010 the confRequest; 1012 2. Creation through implicit cloning (also known as "direct 1013 creation"): the "confObjID" parameter MUST NOT be included in the 1014 request and the CCMP client can describe the desired conference 1015 to be created using the "confInfo" parameter. If no "confInfo" 1016 parameter is provided in the request, the new conference will be 1017 created as a clone of the system default blueprint. 1019 In both creation cases, the confResponse, for a successful completion 1020 of a "create" operation, contains a response-code of "200" and MUST 1021 contain the XCON-URI of the newly created conference in the 1022 "confObjID" parameter, in order to allow the conferencing client to 1023 manipulate that conference through following CCMP requests. In 1024 addition, the "confInfo" parameter transporting the created 1025 conference document MAY be included, at the discretion of the 1026 conferencing system implementation, along with an optional version 1027 parameter initialized at "1", since at creation time the conference 1028 object is at its first version. 1030 In the case of a confRequest with a "retrieve" operation, the 1031 "confObjID" representing the XCON-URI of the target conference MUST 1032 be included and the "confInfo" parameter MUST NOT be included in the 1033 request. The conferencing server MUST ignore any "confInfo" 1034 parameter that is received in a confRequest/retrieve. If the 1035 confResponse for the "retrieve" operation contains a "response-code" 1036 of "200", the "confInfo" parameter MUST be included in the response. 1037 The "confInfo" parameter MUST contain the entire conference document 1038 describing the target conference object in its current state. The 1039 current state of the retrieved conference object MUST also be 1040 reported in the proper "version" response parameter. 1042 In case of a confRequest with an "update" operation, the "confInfo" 1043 and "confObjID" MUST be included in the request. The "confInfo" 1044 represents an object of type "conference-type" containing all the 1045 changes to be applied to the conference whose identifier is 1046 "confObjID". Note that, in such a case, though the confInfo 1047 parameter has indeed to follow the rules indicated in the XCON data 1048 model, it does not represent the entire updated version of the target 1049 conference, since it rather conveys just the modifications to apply 1050 to that conference. For example, in order to change the conference 1051 title, the confInfo parameter will be of the form: 1053 1054 1055 *** NEW CONFERENCE TITLE *** 1056 1057 1058 Figure 7: Updating a conference object: modifying the title of a 1059 conference 1061 Similarly, to remove the title of an existing conference, a 1062 confRequest/update carrying the following "confInfo" parameter would 1063 do the job.: 1065 1066 1067 1068 1069 1071 Figure 8: Updating a conference object: removing the title of a 1072 conference 1074 In the case of a confResponse/update with a response-code of "200", 1075 no additional information is required in the response message, which 1076 means the return of confInfo parameter is not mandatory. A following 1077 confRequest/retrieve transaction might provide the CCMP client with 1078 the current aspect of the conference upon the modification, or the 1079 Notification Protocol might address that task as well. A "200" 1080 response-code indicates that the referenced conference document has 1081 been changed accordingly to the request by the conferencing server. 1082 The "version" parameter MUST be enclosed in the confResponse/update 1083 message, in order to let the client understand what is the actual 1084 current conference-object version, upon the applied modifications. 1085 An "409" response-code indicates that the changes reflected in the 1086 request "confInfo" are not feasible. This could be due to policies, 1087 requestor roles, specific privileges, unacceptable values etc., with 1088 the reason specific to a conferencing system and its configuration. 1089 Together with the "409" response-code, the "version" parameter MUST 1090 be attached in the confResponse/update, by this way allowing the 1091 client to eventually retrieve the current version of the target 1092 conference if the one she attempted to modify was not the most up-to- 1093 date. 1095 In the case of a confRequest with a "delete" operation, the 1096 "confObjID" representing the XCON-URI of the target conference MUST 1097 be included while the "confInfo" MUST NOT be included in the request. 1098 The conferencing server MUST ignore any "confInfo" parameter that is 1099 received within such a request. The confResponse MUST contain the 1100 same "confObjID" that was included in the confRequest. If the 1101 confResponse/delete operation contains a "200" response-code, the 1102 conference indicated in the "confObjID" has been successfully 1103 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1104 parameter. The "version" parameter SHOULD NOT be returned in any 1105 confResponse/delete. If the conferencing server cannot delete the 1106 conference referenced by the "confObjID" received in the confRequest 1107 because it is the parent of another conference object that is in use, 1108 the conferencing server MUST return a response-code of "425". 1110 A confRequest with an "operation" of "retrieve", "update" or "delete" 1111 carrying a "confObjID" which is not associated with one of the 1112 conferences (active or registered) the system is holding will 1113 generate, on the server's side, a confResponse message containing a 1114 "404" error code. This holds also for the case in which the 1115 mentioned "confObjID" is related to an existing conference object 1116 stored at the server, but associated with a blueprint or with a 1117 sidebar rather than an actual conference. 1119 The schema for the confRequest/confResponse pair is shown in 1120 Figure 9. 1122 1124 1125 1126 1127 1128 1129 1130 1131 1132 1134 1136 1138 1139 1140 1142 1144 1145 1146 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1159 1161 1163 1164 1165 1167 1169 1170 1171 1173 Figure 9: Structure of the confRequest and confResponse messages 1175 5.3.5. usersRequest and usersResponse 1177 Through a "usersRequest" message the CCMP client manipulates the XML 1178 element of the conference document associated with the 1179 conference identified by the "confObjID" parameter complusory 1180 included in the request. Inside the element, along with the 1181 list of elements associated with conference participants, 1182 there is information that the client may be interested in 1183 controlling, such the list of the users to which access to the 1184 conference is allowed/denied, conference participation policies, 1185 etc.; for this reason, a customized message has been designed to 1186 allow for the manipulation of this specific part of a conference 1187 document. 1189 A "usersInfo" parameter MAY be included in a usersRequest message 1190 depending upon the operation. If the "usersInfo" parameter is 1191 included in the usersRequest message, the parameter MUST be compliant 1192 with the field of the XCON data model. 1194 Two operations are allowed for a "usersRequest" message: 1196 1. "retrieve": In this case the request MUST NOT include a 1197 "usersInfo" parameter, while the successful response MUST contain 1198 the desired element in the "usersInfo" parameter. The 1199 conference server MUST ignore a "usersInfo" parameter if it is 1200 received in a request with a "retrieve" operation. 1201 2. update: In this case, the "usersInfo" parameter MUST contain the 1202 modifications to be applied to the referred element. If 1203 the "response-code" is "200", then the "usersInfo" parameter 1204 SHOULD NOT be returned. Any "usersInfo" parameter that is 1205 returned SHOULD be ignored. A "response-code" of "426" indicates 1206 that the conferencing client is not allowed to make the changes 1207 reflected in the "usersInfo" contained in the usersRequest 1208 message. This could be due to policies, roles, specific 1209 privileges, etc., with the reason specific to a conferencing 1210 system and its configuration. 1212 Operations of "create" and "delete" are not applicable to a 1213 usersRequest message and MUST NOT be considered by the server, which 1214 means that a "response-code" of "403" MUST be included in the 1215 usersResponse message. 1217 1219 1220 1221 1222 1223 1224 1225 1226 1227 1229 1231 1233 1234 1235 1237 1239 1240 1242 1244 1246 1247 1248 1249 1250 1251 1252 1253 1254 1256 1258 1260 1261 1262 1264 1266 1267 1268 1270 Figure 10: Structure of the usersRequest and usersResponse messages 1272 5.3.6. userRequest and userResponse 1274 A "userRequest" message is used to manipulate elements inside 1275 a conference document associated with a conference identified by the 1276 "confObjID" parameter. Besides retrieving information about a 1277 specific conference user, the message is used to request that the 1278 conference server either create, modify, or delete information about 1279 a user. A "userRequest" message MUST include the "confObjID", the 1280 "operation" parameter, and MAY include a "userInfo" parameter 1281 containing the detailed user's information depending upon the 1282 operation and whether the "userInfo" has already been populated for a 1283 specific user. Note that a user may not necessarily be a 1284 conferencing control client (i.e., some participants in a conference 1285 are not "XCON aware"). 1287 An XCON-USERID SHOULD be assigned to each and every user subscribed 1288 to the system. In such a way, a user who is not a conference 1289 participant can make requests (provided she has successfully passed 1290 AAA checks), like creating a conference, retrieving conference 1291 information, etc.. 1293 Conference users can be created in a number of different ways. In 1294 each of these cases the operation MUST be set to "create" in the 1295 userRequest message. Each of the userResponse messages for these 1296 cases MUST include the "confObjID", "confUserID", "operation" and 1297 "response-code" parameters. In the case of a response code of "200", 1298 the userResponse message MAY include the "userInfo" parameter 1299 depending upon the manner in which the user was created: 1301 o Conferencing client with an XCON-USERID adds itself to the 1302 conference: In this case, the "userInfo" parameter MAY be included 1303 in the userRequest. The "userInfo" parameter MUST contain a 1304 element (compliant with the XCON data model) and the 1305 "entity" attribute MUST be set to a value which represents the 1306 XCON-USERID of the user initiating the request. No additional 1307 parameters beyond those previously described are required in the 1308 userResponse message, in the case of a "response-code" of "200". 1309 o Conferencing client acts on behalf of a third user whose XCON- 1310 USERID is known: in this case, the "userInfo" parameter MUST be 1311 included in the userRequest. The "userInfo" parameter MUST 1312 contain a element and the "entity" attribute value MUST be 1313 set to the XCON-USERID of the third user in question. No 1314 additional parameters beyond those previously described are 1315 required in the userResponse message, in the case of a "response- 1316 code" of "200". 1317 o A conferencing client who has no XCON-USERID and who wants to 1318 enter, via CCMP, a conference whose identifier is known. In such 1319 case, a side-effect of the request is that the user is provided 1320 with a new XCON-USERID (created by the server) carried inside the 1321 "confUserID" parameter of the response. This is the only case in 1322 which a CCMP request can be valid though carrying a void 1323 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1324 in the request, providing at least a contact URI of the joining 1325 client, in order to let the focus instigate the signaling phase 1326 needed to add her to the conference. The mandatory "entity" 1327 attribute of the "userInfo" parameter in the request is filled 1328 with a dummy value recognizable on the server side, so to conform 1329 to the rules contained in the XCON data model XML schema. The 1330 involved messages (userRequest and userResponse) in such case 1331 should look like the following: 1333 Request fields: 1335 confUserID=null; 1336 confObjID=confXYZ; 1337 operation=create; 1338 userInfo= 1340 1341 1342 ... 1344 Response fields (in case of success): 1346 confUserID=user345; 1347 confObjID=confXYZ; 1348 operation=create; 1349 response-code=200; 1350 userInfo=null; //or the entire userInfo object 1352 Figure 11: userRequest and userResponse in the absence of an xcon- 1353 userid 1355 o Conferencing client is unaware of the XCON-USERID of a third user: 1356 In this case, the XCON-USERID in the request "confUserID" is the 1357 sender's one and the "entity" attribute of the attached userInfo 1358 is filled with the pre-defined fake value 1359 "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the 1360 third user MUST be returned to the client issuing the request in 1361 the "entity" attribute of the response "userInfo" parameter, if 1362 the "response-code" is "200". This scenario is intended to 1363 support both the case where a brand new conferencing system user 1364 is added to a conference by a third party (i.e. a user who is not 1365 yet provided with an XCON-USERID) and the case where the CCMP 1366 client issuing the request does not know the to-be-added user's 1367 XCON-USERID (which means such an identifier could already exist on 1368 the server's side for that user). In this last case, the 1369 conferencing server is in charge of avoiding XCON-URI duplicates 1370 for the same conferencing client, looking at key fields in the 1371 request provided "userInfo" parameter, such as the signalling URI: 1372 if the joining user is a brand new one, then the generation of a 1373 new XCON identifier is needed; otherwise, if that user is an 1374 existing one, the server must recover the corresponding XCON 1375 identifier. 1377 In the case of a userRequest with a "retrieve" operation, the 1378 "confObjID" representing the XCON-URI of the target conference MUST 1379 be included. The "confUserID", containing the CCMP client's xcon- 1380 userid, MUST also be included in the userRequest message. If the 1381 client wants to retrieve information about her profile in the 1382 specified conference, no "userInfo" parameter is needed in the 1383 retrieve request. On the other hand, if the client wants to obtain 1384 someone else's info within the given conference, she MUST include in 1385 the userRequest/retrieve a "userInfo" parameter whose "entity" 1386 attribute conveys the desired user's xcon-userid. If the 1387 userResponse for the "retrieve" operation contains a "response-code" 1388 of "200", the "userInfo" parameter MUST be included in the response. 1390 In case of a userRequest with an "update" operation, the "confObjID", 1391 "confUserID" and "userInfo" MUST be included in the request. The 1392 "userInfo" is of type "user-type" and contains all the changes to be 1393 applied to a specific element in the conference object 1394 identified by the "confObjID" in the userRequest message. The user 1395 to be modified is identified through the "entity" attribute of the 1396 "userInfo" parameter included in the request. In the case of a 1397 userResponse with a "response-code" of "200", no additional 1398 information is required in the "userResponse" message. A "response- 1399 code" of "200" indicates that the referenced user element has been 1400 updated by the conference server. A "response-code" of "426" 1401 indicates that the conferencing client is not allowed to make the 1402 changes reflected in the "userInfo" in the initial request. This 1403 could be due to policies, roles, specific privileges, etc., with the 1404 reason specific to a conferencing system and its configuration. 1406 In the case of a userRequest with a "delete" operation, the 1407 "confObjID" representing the XCON-URI of the target conference MUST 1408 be included. The "confUserID", containing the CCMP client's xcon- 1409 userid, MUST be included in the userRequest message. If the client 1410 wants to exit the specified conference, no "userInfo" parameter is 1411 needed in the delete request. On the other hand, if the client wants 1412 to remove another participant from the given conference, she MUST 1413 include in the userRequest/delete a "userInfo" parameter whose 1414 "entity" attribute conveys the xcon-userid of that participant. The 1415 userResponse MUST contain the same "confObjID" that was included in 1416 the userRequest. The userResponse MUST contain a "response-code" of 1417 "200" if the target element has been successfully deleted. If 1418 the userResponse for the "delete" operation contains a "response- 1419 code" of "200", the userResponse MUST NOT contain the "userInfo" 1420 parameter. 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1433 1435 1437 1438 1439 1441 1443 1444 1445 1447 1449 1450 1451 1452 1453 1454 1455 1456 1457 1459 1461 1463 1464 1465 1467 1469 1470 1472 1474 Figure 12: Structure of the userRequest and userResponse messages 1476 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1478 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1479 on the field of the conference object represented 1480 by the "confObjID". The "sidebarsByValRequest" message is of a 1481 "retrieve-only" type, so an "operation" parameter MUST NOT be 1482 included in a "sidebarsByValRequest" message. As with blueprints and 1483 conferences, also with sidebars, CCMP allows for the use of xpath 1484 filters whenever a selected subset of the sidebars available at the 1485 server's side has to be retrieved by the client. This applies both 1486 to sidebars by reference and to sidebars by value. A 1487 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1488 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1490 the client a "version" element related to the current version of the 1491 main conference object (i.e. the one whose identifier is contained in 1492 the "confObjId" field of the request) to which the sidebars in 1493 question are associated. The "sidebarsByValInfo" parameter contains 1494 the list of the conference objects associated with the sidebars by 1495 value derived from the main conference. The retrieved sidebars can 1496 then be updated or deleted using the "sidebarByValRequest" message, 1497 which is described in Section 5.3.8. 1499 1501 1502 1503 1504 1505 1506 1507 1508 1509 1511 1513 1516 1517 1518 1519 1521 1522 1523 1525 1527 1528 1529 1530 1531 1532 1533 1534 1535 1537 1539 1542 1543 1544 1546 1548 1549 1550 1552 Figure 13: Structure of the sidebarsByValRequest and 1553 sidebarsByValResponse messages 1555 5.3.8. sidebarByValRequest and sidebarByValResponse 1557 A sidebarByValRequest message MUST contain the "operation" parameter 1558 which discriminates among retrieval, creation, modification and 1559 deletion of a specific sidebar. The other required parameters depend 1560 upon the type of operation. 1562 In the case of a "create" operation, the "confObjID" parameter MUST 1563 be included in the sidebyValRequest message. In this case, the 1564 "confObjID" parameter contains the XCON-URI of the main conference in 1565 which the sidebar has to be created. If no "sidebarByValInfo" 1566 parameter is included, as envisaged in the XCON framework 1567 ([RFC5239]), the sidebar is created by cloning the main conference, 1568 following the implementation specific cloning rules. Otherwise, 1569 similarly to the case of direct creation, the sidebar conference 1570 object is built on the basis of the "sidebarByValInfo" parameter 1571 provided by the requestor. As a consequence of a sidebar-by-val 1572 creation, the conference server MUST update the main conference 1573 object reflected by the "confObjID" parameter in the 1574 sidebarbyValRequest/create message introducing the new sidebar object 1575 as a new new in the proper section . The 1576 newly created sidebar conference object MAY be included in the 1577 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1578 "response-code" is "200". The XCON-URI of the newly created sidebar 1579 MUST appear in the "confObjID" parameter of the response. The 1580 conference server can notify any conferencing clients that have 1581 subscribed to the conference event package, and are authorized to 1582 receive the notifications, of the addition of the sidebar to the 1583 conference. 1585 In the case of a "sidebarByVal" request with an operation of 1586 "retrieve", the URI for the conference object created for the sidebar 1587 (received in the response to a "create" operation or in a 1588 sidebarsByValResponse message) MUST be included in the "confObjID" 1589 parameter in the request. This "retrieve" operation is handled by 1590 the conference server in the same manner as a "retrieve" operation 1591 included in a confRequest message as detailed in Section 5.3.4. 1593 In the case of a "sidebarByVal" request with an operation of 1594 "update", the "sidebarByValInfo" MUST also be included in the 1595 request. The "confObjID" parameter contained in the request message 1596 identifies the specific sidebar instance to be updated. An "update" 1597 operation on the "sidebarByValInfo" is handled by the conference 1598 server in the same manner as an "update" operation on the confInfo 1599 included in a confRequest message as detailed in Section 5.3.4. A 1600 "sidebarByValResponse" message MUST carry back to the client a 1601 "version" element related to the current version of the sidebar whose 1602 identifier is contained in the "confObjId" field of the request. 1604 If an "operation" of "delete" is included in the sidebarByVal 1605 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1606 request. Any "sidebarByValInfo" included in the request MUST be 1607 ignored by the conference server. The URI for the conference object 1608 associated with the sidebar MUST be included in the "confObjID" 1609 parameter in the request. If the specific conferencing user as 1610 reflected by the "confUserID" in the request is authorized to delete 1611 the conference, the conference server deletes the conference object 1612 reflected by the "confObjID" parameter and updates the data in the 1613 conference object from which the sidebar was cloned. The conference 1614 server can notify any conferencing clients that have subscribed to 1615 the conference event package, and are authorized to receive the 1616 notifications, of the deletion of the sidebar to the conference. 1618 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1619 or "delete" carries a "confObjID" which is not associated with any 1620 existing sidebar-by-val, a confResponse message containing a "404" 1621 error code will be generated on the server's side. This holds also 1622 for the case in which the mentioned "confObjID" is related to an 1623 existing conference object stored at the server, but associated with 1624 a blueprint or with an actual conference or with a sidebar-by-ref 1625 rather than a sidebar-by-val. 1627 1629 1630 1631 1632 1633 1634 1635 1636 1637 1639 1641 1644 1645 1646 1648 1650 1651 1652 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1665 1667 1670 1671 1672 1674 1676 1677 1678 1680 Figure 14: Structure of the sidebarByValRequest and 1681 sidebarByValResponse messages 1683 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1685 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1686 invoked to retrieve the element of the conference 1687 object identified by the "confObjID" parameter. The 1688 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1689 "operation" parameter MUST NOT be included in a 1690 "sidebarsByRefRequest" message. In the case of a "response-code" of 1691 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1693 response. The element represents the set of URIs 1694 of the sidebars associated with the main conference, whose 1695 description (in the form of a standard XCON conference document) is 1696 external to the main conference itself. Through the retrieved URIs, 1697 it is then possible to access single sidebars using the 1698 "sidebarByRef" request message, described in Section 5.3.10. A 1699 "sidebarsByRefResponse" message MUST carry back to the client a 1700 "version" element related to the current version of the main 1701 conference object (i.e. the one whose identifier is contained in the 1702 "confObjId" field of the request) to which the sidebars in question 1703 are associated. 1705 1707 1708 1709 1710 1711 1712 1713 1714 1715 1717 1719 1722 1723 1724 1726 1728 1729 1730 1732 1734 1735 1736 1737 1738 1739 1740 1741 1742 1744 1746 1749 1750 1751 1753 1755 1756 1757 1759 Figure 15: Structure of the sidebarsByRefRequest and 1760 sidebarsByRefResponse messages 1762 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1764 A sidebarByRefRequest message MUST contain the "operation" parameter 1765 which discriminates among retrieval, creation, modification and 1766 deletion of a specific sidebar. The other required parameters depend 1767 upon the type of operation. 1769 In the case of a "create" operation, the "confObjID" parameter MUST 1770 be included in the sidebyRefRequest message. In this case, the 1771 "confObjID" parameter contains the XCON-URI of the main conference in 1772 which the sidebar has to be created. If no "sidebarByRefInfo" 1773 parameter is included, as envisaged in the XCON framework 1774 ([RFC5239]), the sidebar is created by cloning the main conference, 1775 following the implementation specific cloning rules. Otherwise, 1776 similarly to the case of direct creation, the sidebar conference 1777 object is built on the basis of the "sidebarByRefInfo" parameter 1778 provided by the requestor. If the creation of the sidebar is 1779 successful, the conference server MUST update the "sidebars-by-ref" 1780 element in the conference object from which the sidebar was created 1781 (i.e., as identified by the "confObjID" in the original sidebarByRef 1782 request), with the URI of the newly created sidebar. The newly 1783 created conference object MAY be included in the response in the 1784 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1785 URI for the conference object associated with the newly created 1786 sidebar object MUST appear in the "confObjID" parameter of the 1787 response. The conference server can notify any conferencing clients 1788 that have subscribed to the conference event package, and are 1789 authorized to receive the notifications, of the addition of the 1790 sidebar to the conference. 1792 In the case of a "sidebarByRef" request with an operation of 1793 "retrieve", the URI for the conference object created for the sidebar 1794 MUST be included in the "confObjID" parameter in the request. A 1795 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1796 conference server in the same manner as a "retrieve" operation on the 1797 confInfo included in a confRequest message as detailed in 1798 Section 5.3.4. 1800 In the case of a "sidebarByRef" request with an operation of 1801 "update", the URI for the conference object created for the sidebar 1802 MUST be included in the "confObjID" parameter in the request. The 1803 "sidebarByRefInfo" MUST also be included in the request in the case 1804 of an "operation" of "update". An "update" operation on the 1805 "sidebarByRefInfo" is handled by the conference server in the same 1806 manner as an "update" operation on the confInfo included in a 1807 confRequest message as detailed in Section 5.3.4. A 1808 "sidebarByRefResponse" message MUST carry back to the client a 1809 "version" element related to the current version of the sidebar whose 1810 identifier is contained in the "confObjId" field of the request. 1812 If an "operation" of "delete" is included in the sidebarByRef 1813 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1814 request. Any "sidebarByRefInfo" included in the request MUST be 1815 ignored by the conference server. The URI for the conference object 1816 for the sidebar MUST be included in the "confObjID" parameter in the 1817 request. If the specific conferencing user as reflected by the 1818 "confUserID" in the request is authorized to delete the conference, 1819 the conference server SHOULD delete the conference object reflected 1820 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1821 element in the conference object from which the sidebar was 1822 originally cloned. The conference server can notify any conferencing 1823 clients that have subscribed to the conference event package, and are 1824 authorized to receive the notifications, of the deletion of the 1825 sidebar. 1827 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1828 or "delete" carries a "confObjID" which is not associated with any 1829 existing sidebar-by-ref, a confResponse message containing a "404" 1830 error code will be generated on the server's side. This holds also 1831 for the case in which the mentioned "confObjID" is related to an 1832 existing conference object stored at the server, but associated with 1833 a blueprint or with an actual conference or with a sidebar-by-val 1834 rather than a sidebar-by-ref. 1836 1838 1839 1840 1841 1842 1843 1844 1845 1846 1848 1850 1853 1854 1855 1857 1859 1860 1861 1863 1865 1866 1867 1868 1869 1870 1871 1872 1873 1875 1877 1880 1881 1882 1884 1886 1887 1889 1891 Figure 16: Structure of the sidebarByRefRequest and 1892 sidebarByRefResponse messages 1894 5.3.11. extendedRequest and extendedResponse 1896 In order to facilitate the possibility of specifying new request/ 1897 response pairs for conference control, CCMP makes available the 1898 "extendedRequest" and "extendedResponse" messages. Such messages 1899 constitute a CCMP skeleton in which implementors can transport the 1900 information needed to realize conference control mechanisms not 1901 explicitly envisioned in the CCMP specification; these mechanisms are 1902 called, in this context, "extensions". Each extension is assumed to 1903 be characterized by an appropriate name that MUST be carried in the 1904 extendedRequest/extendedResponse pair in the provided 1905 field. Extension-specific information can be transported in the form 1906 of schema-defined XML elements inside the element present in 1907 both extendedRequest and extendedResponse. 1909 The conferencing client SHOULD be able to be informed about the 1910 extensions supported by a CCMP server and to recover the XML Schema 1911 defining the related specific elements by means of an optionsRequest/ 1912 optionsResponse CCMP transaction (see Section 5.3.12). 1914 The meaning of the common CCMP parameters inherited by the 1915 extendedRequest and extendedResponse from the basic CCMP request and 1916 response messages SHOULD be preserved and exploited appropriately 1917 while defining an extension. 1919 1921 1922 1923 1924 1925 1926 1927 1928 1929 1931 1933 1934 1935 1936 1938 1941 1942 1944 1946 1947 1948 1949 1950 1951 1952 1953 1954 1956 1958 1960 1961 1962 1965 1968 1969 1971 Figure 17: Structure of the extendedRequest and extendedResponse 1972 messages 1974 5.3.12. optionsRequest and optionsResponse 1976 An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. 1977 it does not represent a specialization of the general CCMP request. 1978 It allows a CCMP client to become aware of CCMP server capabilities 1979 in terms of CCMP supported messages. 1981 Indeed, the "optionsResponse" returns, in the appropriate 1982 field, information about both standard (i.e. IETF-defined) CCMP 1983 messages and extension messages the server is able to handle. 1984 Supported messages are listed into two separate groups, namely 1985 and . Such groups are 1986 represented, respectively, by a entry (for 1987 standard messages) and an entry (for extensions). 1988 In both cases, for each message the following information is 1989 provided: 1990 o (mandatory): in case of standard messages, it can be one of 1991 the ten standard message names defined in this document (i.e. 1992 "blueprintsRequest", "confsRequest", etc.). In case of 1993 extensions, this element MUST carry the same value of the 1994 inserted in the corresponding extendedRequest/ 1995 extendedResponse message pair 1996 o (optional): this field is a list of 1997 entries, each representing the CRUD operation supported by the 1998 server for the message. If this optional element is absent, the 1999 client SHOULD assume the server is able to handle the entire set 2000 of CRUD operations or, in case of standard messages, all the 2001 operations envisioned for that message in this document. 2002 o (optional): since all CCMP messages can potentially 2003 contain XML elements not envisioned in the CCMP schema (due to the 2004 presence of elements and attributes), a reference to a 2005 proper schema definition specifying such new elements/attributes 2006 can also be sent back to the clients by means of such field. If 2007 this element is absent, no new elements are introduced in the 2008 messages further than those explicitly defined in the CCMP 2009 specification. 2010 o (optional): human readable information about the 2011 related message 2013 The only parameter needed in the optionsRequest is the sender 2014 confUserID, which is mirrored in the homologous parameter of the 2015 corresponding optionsResponse. 2017 The MUST appear in the optionsResponse and 2018 MUST NOT be void, since a CCMP server MUST be able to handle at least 2019 one of the standard messages in at least one of the envisioned 2020 operations, i.e. the aforementioned list MUST carry at least one 2021 containing at least one element. 2023 2025 2026 2027 2028 2029 2031 2033 2034 2035 2036 2037 2038 2039 2040 2041 2043 2045 2048 2049 2050 2052 2054 2055 2056 2058 2060 2061 2062 2065 2068 2070 2071 2072 2073 2075 2076 2077 2080 2082 2083 2084 2086 2088 2089 2090 2093 2096 2098 2100 2102 2103 2104 2106 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2122 2124 2126 2127 2128 2130 2131 2132 2134 Figure 18: Structure of the optionsRequest and optionsResponse 2135 messages 2137 5.4. CCMP Response Codes 2139 All CCMP response messages MUST include a ""response-code"". The 2140 following summarizes the CCMP response codes: 2142 200 Success: Successful completion of the requested operation. 2143 400 Bad Request: Syntactically malformed request. 2144 401 Unauthorized: User not allowed to perform the required 2145 operation. 2146 403 Forbidden: Operation not allowed (e.g., cancellation of a 2147 blueprint). 2148 404 Object Not Found: Target conference object missing at the server 2149 (it refers to the "confObjID" parameter in the generic request 2150 message) 2151 409 Conflict: A generic error associated with all those situations 2152 in which a requested client operation cannot be successfully 2153 completed by the server. An example of such situation is when the 2154 modification of an object cannot be applied due to conflicts 2155 arising at the server's side, e.g. because the client version of 2156 the object is an obsolete one and the requested modifications 2157 collide with the up-to-date state of the object stored at the 2158 server. Such code would also be used if a client attempts to 2159 create an object (conference or user) with an entity that already 2160 exists. 2161 420 User Not Found: Target user missing at the server (it is related 2162 to the XCON-USERID in the "entity" attribute of the "userInfo" 2163 parameter when it is included in userRequests) 2164 421 Invalid confUserID: User missing at the server (this code is 2165 returned in the case of requests in which the "confUserID" of the 2166 sender is invalid). 2168 422 Invalid Conference Password: Target conference object's password 2169 contained in the request is wrong. 2170 423 Conference Password Required: "conference-password" missing in a 2171 request to access a password-protected conference object. 2172 424 Authentication Required: User's authentication information is 2173 missing or invalid. 2174 425 Forbidden Delete Parent: Cancel operation failed since the 2175 target object is a parent of child objects which depend on it, or 2176 because it effects, based on the "parent-enforceable" mechanism, 2177 the corresponding element in a child object. 2178 426 Forbidden Change Protected: Update refused by the server because 2179 the target element cannot be modified due to its implicit 2180 dependence on the value of a parent object ("parent-enforceable" 2181 mechanism). 2182 500 Server Internal Error: The server cannot complete the required 2183 service due to a system internal error. 2184 501 Not Implemented: Operation envisaged in the protocol, but not 2185 implemented in the contacted server. 2186 510 Request Timeout: The time required to serve the request has 2187 exceeded the envisaged service threshold. 2188 511 Resources Not Available: This code is used when the CCMP server 2189 cannot execute a command because of resource issues, e.g. it 2190 cannot create a sub conference because the system has reached its 2191 limits on the number of sub conferences, or if a request for 2192 adding a new user fails because the max number of users has been 2193 reached for the conference or the max number of users has been 2194 reached for the conferencing system. 2196 The handling of a "response-code" of "404", "409", "420", "421", 2197 "425" and "426" are only applicable to specific operations for 2198 specialized message responses and the details are provided in 2199 Section 5.3. The following table summarizes these response codes and 2200 the specialized message and operation to which they are applicable: 2202 +---------------+------------+------------+------------+------------+ 2203 | Response code | Create | Retrieve | Update | Delete | 2204 +---------------+------------+------------+------------+------------+ 2205 | 404 | userReques | All | All update | All delete | 2206 | | t, | retrieve | requests | requests | 2207 | | sidebarBy | requests, | | | 2208 | | ValRequest | EXCEPT: | | | 2209 | | sidebars | blueprints | | | 2210 | | ByRefReque | Request, | | | 2211 | | st | confsRequ | | | 2212 | | | est | | | 2213 | ------------- | ---------- | ---------- | ---------- | ---------- | 2214 | 409 | N/A | N/A | All update | N/A | 2215 | | | | requests | | 2216 | ------------- | ---------- | ---------- | ---------- | ---------- | 2217 | 420 | userReques | userReques | userReques | userReques | 2218 | | t(3rd part | t | t | t | 2219 | | yinvite | | | | 2220 | | with thir | | | | 2221 | | duser | | | | 2222 | | entity) | | | | 2223 | | (*) | | | | 2224 | ------------- | ---------- | ---------- | ---------- | ---------- | 2225 | 421 | All create | All | All update | All delete | 2226 | | requests, | retrieve | requests | requests | 2227 | | EXCEPT: | requests | | | 2228 | | userReques | | | | 2229 | | twith no | | | | 2230 | | confUserI | | | | 2231 | | D(**) | | | | 2232 | ------------- | ---------- | ---------- | ---------- | ---------- | 2233 | 425 | N/A | N/A | N/A | All delete | 2234 | | | | | request | 2235 | ------------- | ---------- | ---------- | ---------- | ---------- | 2236 | 426 | N/A | N/A | All update | N/A | 2237 | | | | requests | | 2238 +---------------+------------+------------+------------+------------+ 2240 Table 2: Response codes and associated operations 2242 (*) "420" in answer to a "userRequest/create" operation: in the case 2243 of a third-party invite, this code can be returned if the 2244 "confUserID" (contained in the "entity" attribute of the "userInfo" 2245 parameter) of the user to be added is unknown. In the case above, if 2246 instead it is the "confUserID" of the sender of the request that is 2247 invalid, a "421" error code is returned to the client. 2249 (**) "421" is not sent in answers to "userRequest/create" messages 2250 having a "null" confUserID, since this case is associated with a user 2251 who is unaware of his own XCON-USERID, but wants to enter a known 2252 conference. 2254 In the case of a response code of "510", a conferencing client MAY 2255 re-attempt the request within a period of time that would be specific 2256 to a conference control client or conference control server. 2258 A response code of "400" indicates that the conference control client 2259 sent a malformed request, which is indicative of an error in the 2260 conference control client or in the conference control server. The 2261 handling is specific to the conference control client implementation 2262 (e.g., generate a log, display an error message, etc.). It is NOT 2263 RECOMMENDED that the client re-attempt the request in this case. 2265 Response codes such as "401" and "403" indicate the client does not 2266 have the appropriate permissions, or there is an error in the 2267 permissions: re-attempting the request would likely not succeed and 2268 thus it is NOT RECOMMENDED. 2270 Any unexpected or unknown "response-code" SHOULD be treated by the 2271 client in the same manner as a "500" "response-code", the handling of 2272 which is specific to the conference control client implementation. 2274 6. A complete example of the CCMP in action 2276 In this section a typical, not normative, scenario in which the CCMP 2277 comes into play is described, by showing the actual composition of 2278 the various CCMP messages. In the call flows of the example, the 2279 Conference Control Client is a CCMP-enabled client, whereas the 2280 Conference Control Server is a CCMP-enabled server. The "confUserID" 2281 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2282 in all requests. The sequence of operations is as follows: 2284 1. Alice retrieves from the server the list of available blueprints 2285 (Section 6.1); 2286 2. Alice asks for detailed information about a specific blueprint 2287 (Section 6.2); 2288 3. Alice decides to create a new conference by cloning the retrieved 2289 blueprint (Section 6.3); 2290 4. Alice modifies information (e.g. XCON-URI, name, description) 2291 associated with the newly created blueprint (Section 6.4); 2292 5. Alice specifies a list of users to be contacted when the 2293 conference is activated (Section 6.5); 2294 6. Alice joins the conference (Section 6.6); 2295 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2296 "xcon-userid:Ciccio@example.com") join the conference 2297 (Section 6.7). 2298 8. Alice asks for the CCMP server capabilities (Section 6.8); 2299 9. Alice exploits an extension of the CCMP server (Section 6.9). 2301 Note, the examples do not include any details beyond the basic 2302 operation. 2304 In the following sections we deal with each of the above mentioned 2305 actions separately. 2307 6.1. Alice retrieves the available blueprints 2309 This section illustrates the transaction associated with retrieval of 2310 the blueprints, together with a dump of the two messages exchanged 2311 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2312 the figure, the "blueprintsResponse" message contains, in the 2313 "blueprintsInfo" parameter, information about the available 2314 blueprints, in the form of the standard XCON-URI of the blueprint, 2315 plus additional (and optional) information, like its display-text and 2316 purpose. 2318 Alice retrieves from the server the list of available blueprints: 2320 CCMP Client CCMP Server 2321 | | 2322 | CCMP blueprintsRequest message | 2323 | - confUserID: Alice | 2324 | - confObjID: (null) | 2325 |------------------------------------------------------>| 2326 | | 2327 | CMP blueprintsResponse message | 2328 | - confUserID: Alice | 2329 | - confObjID: (null) | 2330 | - response-code: 200 | 2331 | - blueprintsInfo: bp123,bp124,.. | 2332 |<------------------------------------------------------| 2333 | | 2334 . . 2335 . . 2337 1. blueprintsRequest message: 2339 2340 2343 2345 xcon-userid:Alice@example.com 2346 2347 2349 2. blueprintsResponse message form the server: 2351 2352 2356 2359 xcon-userid:Alice@example.com 2360 200 2361 2362 2363 2364 xcon:AudioRoom@example.com 2365 AudioRoom 2366 Simple Room: 2367 conference room with public access, 2368 where only audio is available, more users 2369 can talk at the same time 2370 and the requests for the AudioFloor 2371 are automatically accepted. 2372 2373 2374 2375 xcon:VideoRoom@example.com 2376 VideoRoom 2377 Video Room: 2378 conference room with public access, 2379 where both audio and video are available, 2380 8 users can talk and be seen at the same time, 2381 and the floor requests are automatically accepted. 2382 2383 2384 2385 xcon:AudioConference1@example.com 2386 AudioConference1 2387 Public Audio Conference: 2389 conference with public access, 2390 where only audio is available, 2391 only one user can talk at the same time, 2392 and the requests for the AudioFloor MUST 2393 be accepted by a Chair. 2394 2395 2396 2397 xcon:VideoConference1@example.com 2398 VideoConference1 2399 Public Video Conference: conference 2400 where both audio and video are available, 2401 only one user can talk 2402 2403 2404 2405 xcon:AudioConference2@example.com 2406 AudioConference2 2407 Basic Audio Conference: 2408 conference with private access, 2409 where only audio is available, 2410 only one user can talk at the same time, 2411 and the requests for the AudioFloor MUST 2412 be accepted by a Chair. 2413 2414 2415 2416 2417 2418 2420 Figure 19: Getting blueprints from the server 2422 6.2. Alice gets detailed information about a specific blueprint 2424 This section illustrates the second transaction in the overall flow. 2425 In this case, Alice, who now knows the XCON-URIs of the blueprints 2426 available at the server, makes a drill-down query, in the form of a 2427 CCMP "blueprintRequest" message, to get detailed information about 2428 one of them (the one called with XCON-URI 2429 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2430 Notice that the response contains, in the "blueprintInfo" parameter, 2431 a document compliant with the standard XCON data model. 2433 Alice retrieves detailed information about a specified blueprint: 2435 CCMP Client CCMP Server 2436 | | 2437 | CCMP blueprintRequest message | 2438 | - confUserID: Alice | 2439 | - confObjID: bp123 | 2440 | - operation: retrieve | 2441 | - blueprintInfo: (null) | 2442 |------------------------------------------------------>| 2443 | | 2444 | CCMP blueprintResponse message | 2445 | - confUserID: Alice | 2446 | - confObjID: bp123 | 2447 | - operation: retrieve | 2448 | - response-code: 200 | 2449 | - blueprintInfo: bp123Info | 2450 |<------------------------------------------------------| 2451 | | 2452 . . 2453 . . 2455 1. blueprintRequest message: 2457 2458 2462 2464 xcon-userid:Alice@example.com 2465 xcon:AudioRoom@example.com 2466 retrieve 2467 2468 2469 2471 2. blueprintResponse message form the server: 2473 2474 2478 2480 xcon-userid:Alice@example.com 2481 xcon:AudioRoom@example.com 2482 retrieve 2483 200 2484 2485 2486 2487 AudioRoom 2488 2 2489 2490 2491 audio 2492 2493 2494 2495 2496 allow 2497 2498 2499 confirm 2500 2501 2502 2503 2504 2505 2506 2507 2508 2510 Figure 20: Getting info about a specific blueprint 2512 6.3. Alice creates a new conference through a cloning operation 2514 This section illustrates the third transaction in the overall flow. 2515 Alice decides to create a new conference by cloning the blueprint 2516 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2517 retrieved detailed information through the "blueprintRequest" 2518 message. This is achieved by sending a "confRequest/create" message 2519 having the blueprint's URI in the "confObjID" parameter. The picture 2520 shows such transaction. Notice that the response contains, in the 2521 "confInfo" parameter, the document associated with the newly created 2522 conference, which is compliant with the standard XCON data model. 2523 The "confObjID" in the response is set to the XCON-URI of the new 2524 conference (in this case, "xcon:8977794@example.com"). We also 2525 notice that this value is equal to the value of the "entity" 2526 attribute of the element of the document 2527 representing the newly created conference object. 2529 Alice creates a new conference by cloning the 2530 "xcon:AudioRoom@example.com" blueprint: 2532 CCMP Client CCMP Server 2533 | | 2534 | CCMP confRequest message | 2535 | - confUserID: Alice | 2536 | - confObjID: AudioRoom | 2537 | - operation: create | 2538 | - confInfo: (null) | 2539 |------------------------------------------------------>| 2540 | | 2541 | CCMP confResponse message | 2542 | - confUserID: Alice | 2543 | - confObjID: newConfId | 2544 | - operation: create | 2545 | - response-code: 200 | 2546 | - version: 1 | 2547 | - confInfo: newConfInfo | 2548 |<------------------------------------------------------| 2549 | | 2550 . . 2551 . . 2553 1. confRequest message: 2555 2556 2560 2563 xcon-userid:Alice@example.com 2564 xcon:AudioRoom@example.com 2565 create 2566 2567 2568 2570 2. confResponse message from the server: 2572 2573 2577 2580 xcon-userid:Alice@example.com 2581 xcon:8977794@example.com 2582 create 2583 200 2584 1 2585 2586 2587 2588 2589 New conference by Alice cloned from AudioRoom 2590 2591 2592 2593 2594 xcon:8977794@example.com 2595 2596 2597 conference xcon-uri 2598 2599 2600 2601 10 2602 2603 2604 audio 2605 2606 2607 2608 2609 allow 2610 2611 2612 2613 confirm 2614 2615 2616 2617 2618 2619 2620 2622 2624 Figure 21: Creating a new conference by cloning a blueprint 2626 6.4. Alice updates conference information 2628 This section illustrates the fourth transaction in the overall flow. 2629 Alice decides to modify some of the details associated with the 2630 conference she just created. More precisely, she changes the 2631 element under the element of 2632 the document representing the conference. This is achieved through a 2633 "confRequest/update" message carrying the fragment of the conference 2634 document to which the required changes have to be applied. As shown 2635 in the picture, the response contains a code of "200", which 2636 acknowledges the modifications requested by the client, while also 2637 updating the conference version number from 1 to 2, as reflected in 2638 the "version" parameter. 2640 Alice updates information about the conference she just created: 2642 CCMP Client CCMP Server 2643 | | 2644 | CCMP confRequest message | 2645 | - confUserID: Alice | 2646 | - confObjID: 8977794 | 2647 | - operation: update | 2648 | - confInfo: confUpdates | 2649 |------------------------------------------------------>| 2650 | | 2651 | CCMP confResponse message | 2652 | - confUserID: Alice | 2653 | - confObjID: 8977794 | 2654 | - operation: update | 2655 | - response-code: 200 | 2656 | - version: 2 | 2657 | - confInfo: (null) | 2658 |<------------------------------------------------------| 2659 | | 2660 . . 2661 . . 2663 1. confRequest message: 2665 2666 2670 2673 xcon-userid:Alice@example.com 2674 xcon:8977794@example.com 2675 update 2676 2677 2678 2679 2680 Alice's conference 2681 2682 2683 2684 2685 2686 2688 2. confResponse message form the server: 2690 2691 2695 2697 xcon-userid:Alice@example.com 2698 xcon:8977794@example.com 2699 update 2700 200 2701 2 2702 2703 2704 2706 Figure 22: Updating conference information 2708 6.5. Alice inserts a list of users in the conference object 2710 This section illustrates the fifth transaction in the overall flow. 2711 Alice modifies the under the element in 2712 the document associated with the conference she created. To the 2713 purpose, she exploits the "usersRequest" message provided by the 2714 CCMP. The picture below shows the transaction. 2716 Alice updates information about the list of users to whom access to 2717 the conference is permitted: 2719 CCMP Client CCMP Server 2720 | | 2721 | CCMP usersRequest message | 2722 | - confUserID: Alice | 2723 | - confObjID: 8977794 | 2724 | - operation: update | 2725 | - usersInfo: usersUpdates | 2726 |------------------------------------------------------>| 2727 | | 2728 | CCMP usersResponse message | 2729 | - confUserID: Alice | 2730 | - confObjID: 8977794 | 2731 | - operation: update | 2732 | - response-code: 200 | 2733 | - version: 3 | 2734 | - usersInfo: (null) | 2735 |<------------------------------------------------------| 2736 | | 2737 . . 2738 . . 2740 1. usersRequest message: 2742 2743 2747 2749 xcon-userid:Alice@example.com 2750 xcon:8977794@example.com 2751 update 2752 2753 2754 2755 2757 2759 2761 2762 2763 2764 2765 2767 2. usersResponse message form the server: 2769 2770 2774 2776 xcon-userid:Alice@example.com 2777 xcon:8977794@example.com 2778 update 2779 200 2780 3 2781 2782 2783 2785 Figure 23: Updating the list of allowed users for the conference 2786 'xcon:8977794@example.com' 2788 6.6. Alice joins the conference 2790 This section illustrates the sixth transaction in the overall flow. 2791 Alice uses the CCMP to add herself to the newly created conference. 2792 This is achieved through a "userRequest/create" message containing, 2793 in the "userInfo" parameter, a element compliant with the XCON 2794 data model representation. Notice that such element includes 2795 information about the user's Address of Records, as well as her 2796 current end-point. The picture below shows the transaction. Notice 2797 how the "confUserID" parameter is equal to the "entity" attribute of 2798 the element, which indicates that the request issued by 2799 the client is a first-party one. 2801 Alice joins the conference by issuing a "userRequest/create" message 2802 with her own id to the server: 2804 CCMP Client CCMP Server 2805 | | 2806 | CCMP userRequest message | 2807 | - confUserID: Alice | 2808 | - confObjID: 8977794 | 2809 | - operation: create | 2810 | - userInfo: AliceUserInfo | 2811 |------------------------------------------------------>| 2812 | | 2813 | CCMP userResponse message | 2814 | - confUserID: Alice | 2815 | - confObjID: 8977794 | 2816 | - operation: create | 2817 | - response-code: 200 | 2818 | - version: 4 | 2819 | - userInfo: (null) | 2820 |<------------------------------------------------------| 2821 | | 2822 . . 2823 . . 2825 1. userRequest message: 2827 2828 2832 2834 xcon-userid:Alice@example.com 2835 xcon:8977794@example.com 2836 create 2837 2838 2839 2840 2841 2842 mailto:Alice83@example.com 2843 2844 email 2846 2847 2848 2849 2850 2851 2852 2854 2. userResponse message form the server: 2856 2857 2861 2863 xcon-userid:Alice@example.com 2864 xcon:8977794@example.com 2865 create 2866 200 2867 4 2868 2869 2870 2872 Figure 24: Alice joins the conference through the CCMP 2874 6.7. Alice adds a new user to the conference 2876 This section illustrates the seventh and last transaction in the 2877 overall flow. Alice uses the CCMP to add a new conferencing system 2878 user, Ciccio, to the conference. This "third-party" request is 2879 realized through a "userRequest/create" message containing, in the 2880 "userInfo" parameter, a element compliant with the XCON data 2881 model representation. Notice that such element includes information 2882 about Ciccio's Address of Records, as well as his current end-point, 2883 but has a fake "entity" attribute, since it is unknown to Alice, in 2884 this example. Thus, the server is in charge of generating a new 2885 XCON-USERID for the user Alice indicates, and returning it in the 2886 "entity" attribute of the "userInfo" parameter carried in the 2887 response, as well as adding the user to the conference. The picture 2888 below shows the transaction. 2890 Alice adds user "Ciccio" to the conference by issuing a third-party 2891 "userRequest/create" message to the server: 2893 CCMP Client CCMP Server 2894 | | 2895 | CCMP userRequest message | 2896 | - confUserID: Alice | 2897 | - confObjID: 8977794 | 2898 | - operation: create | 2899 | - userInfo: CiccioUserInfo(with dummy "entity") | 2900 |------------------------------------------------------>| 2901 | | 2902 | CCMP optionsResponse message | 2903 | - confUserID: Alice | 2904 | - confObjID: 8977794 | 2905 | - operation: create | 2906 | - response-code: 200 | 2907 | - version: 5 | 2908 | - userInfo: CiccioUserInfo | 2909 | (with actual "entity") | 2910 |<------------------------------------------------------| 2911 | | 2912 . . 2913 . . 2915 1. "third party" userRequest message from Alice: 2917 2918 2922 2924 xcon-userid:Alice@example.com 2925 xcon:8977794@example.com 2926 create 2927 2928 2929 2930 2931 2932 mailto:Ciccio@example.com 2933 2934 email 2935 2936 2937 2938 2939 2940 2941 2943 2. "third party" userResponse message from the server: 2945 2946 2950 2952 xcon-userid:Alice@example.com 2953 xcon:8977794@example.com 2954 create 2955 200 2956 5 2957 2958 2959 2960 2961 2962 mailto:Ciccio@example.com 2963 2964 email 2965 2966 2967 2968 2969 2970 2971 2973 Figure 25: Alice adds a new user to the conference through the CCMP 2975 6.8. Alice asks for the CCMP server capabilities 2977 This section illustrates how Alice can discover which standard CCMP 2978 messages and what extensions are supported by the CCMP server she 2979 interacts with through an optionsRequest/optionsResponse transaction. 2981 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 2982 confUserID parameter. Looking at the element in the 2983 received optionsResponse, Alice infers the following server 2984 capabilities as regards standard CCMP messages: 2985 o the server doesn't support neither sidebarsByValRequest nor 2986 sidebarByValRequest messages, since they do not appear in the 2987 ; 2988 o the only implemented operation for the blueprintRequest message is 2989 "retrieve", since no other entries are included in the 2990 related field. 2992 Besides, by analyzing the , Alice discovers 2993 the server implements an extension named "confSummaryRequest" 2994 allowing conferencing clients to recover via CCMP a brief description 2995 of a specific conference; the XML elements involved in this extended 2996 conference control transaction are available at the URL indicated in 2997 the element and the only operation envisioned for this 2998 extension is "retrieve". To better understand how Alice can exploit 2999 the "confSummaryRequest" extension via CCMP, see Section 6.9. 3001 The picture below shows the optionsRequest/optionsResponse message 3002 exchanging between Alice and the CCMP server. 3004 CCMP Client CCMP Server 3005 | | 3006 | CCMP optionsRequest message | 3007 | - confUserID: Alice | 3008 |------------------------------------------------------>| 3009 | | 3010 | CCMP userResponse message | 3011 | - confUserID: Alice | 3012 | - response-code: 200 | 3013 | - options (list of both | 3014 | standard and extended | 3015 | supported messages) | 3016 |<------------------------------------------------------| 3017 | | 3018 . . 3019 . . 3021 1. optionsRequest (Alice asks for CCMP server capabilities) 3023 3024 3028 3030 xcon-userid:Alice@example.com 3031 3032 3034 2. optionsResponse (the server returns the list of its conference 3035 control capabilities) 3037 3038 3041 3043 xcon-userid:Alice@example.com 3044 200 3045 success 3046 3047 3048 3049 3050 blueprintsRequest 3051 3052 3053 blueprintRequest 3054 3055 retrieve 3056 3057 3058 3059 confsRequest 3060 3061 confRequest 3062 3063 3064 usersRequest 3065 3066 3067 userRequest 3068 3069 3070 sidebarsByRefRequest 3071 3072 3073 sidebarByRefRequest 3074 3076 3077 3078 3079 confSummaryRequest 3080 3081 request 3082 3083 3084 http://example.com/ccmp-extension-schema.xsd 3085 3086 3087 confSummaryRequest is intented 3088 to allow the requestor to retrieve 3089 a brief description 3090 of the conference indicated in the 3091 confObjID request parameter 3092 3093 3094 3095 3096 3097 3098 3100 Figure 26: Alice asks for the server control capabilities 3102 6.9. Alice exploits a CCMP server extension 3104 In this section, a very simple example of CCMP extension support is 3105 provided. Alice can recover information about this and other server- 3106 supported extensions by issuing an optionsRequest (see Section 6.8). 3108 The extension in question is named "confSummaryRequest" and is 3109 conceived to allow a CCMP client to obtain from the CCMP server 3110 synthetic information about a specific conference. The conference 3111 summary is carried in the form of an XML element, , 3112 defined by the following XML schema: 3114 3115 3117 3119 3120 3121 3122 3123 3124 3125 3126 3128 element 3134 contains conference information related to: 3136 o title 3137 o status (active or registered) 3138 o participation modality (if everyone is allowed to participate, the 3139 boolean element is set to "true") 3140 o involved media 3142 In order to retrieve a conference summary related to the conference 3143 she participates in, Alice then sends to the CCMP server an 3144 extendedRequest with a "confSummaryRequest" , 3145 specifying the conference xcon-uri in the confObjID request 3146 parameter, as depicted in the figure below. 3148 CCMP Client CCMP Server 3149 | | 3150 | CCMP extendedRequest message | 3151 | - confUserID: Alice | 3152 | - confObjID: 8977794 | 3153 | - operation: retrieve | 3154 | - extensionName: confSummaryRequest | 3155 |------------------------------------------------------>| 3156 | | 3157 | CCMP extendedResponse message | 3158 | - confUserID: Alice | 3159 | - confObjID: 8977794 | 3160 | - operation: retrieve | 3161 | - response-code: 200 | 3162 | - extensionName: | 3163 | confSummaryRequest | 3164 | - confSummary | 3165 |<------------------------------------------------------| 3166 | | 3167 . . 3168 . . 3170 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3172 3173 3177 3179 xcon-userid:Alice@example.com 3180 xcon:8977794@example.com 3181 retrieve 3182 3183 confRequestSummary 3184 3185 3186 3188 2. extendedResponse (the server provides Alice with a brief description 3189 of the desired conference) 3191 3192 3196 3198 xcon-userid:Alice@example.com 3199 xcon:8977794@example.com 3200 retrieve 3201 200 3202 success 3203 3204 confSummaryRequest 3205 3206 Alice's conference 3207 active 3208 true 3209 audio 3210 3211 3212 3213 3215 Figure 28: Alice exploits the 'confSummaryRequest' extension 3217 7. Locating a Conference Control Server 3219 If a conference control client is not pre-configured to use a 3220 specific conference control server for the requests, the client MUST 3221 first discover the conference control server before it can send any 3222 requests. The result of the discovery process, is the address of the 3223 server supporting conferencing. In this document, the result is an 3224 http: or https: URI, which identifies a conference server. 3226 This document proposes the use of DNS to locate the conferencing 3227 server. U-NAPTR resolution for conferencing takes a domain name as 3228 input and produces a URI that identifies the conferencing server. 3229 This process also requires an Application Service tag and an 3230 Application Protocol tag, which differentiate conferencing-related 3231 NAPTR records from other records for that domain. 3233 Section 12.4.1 defines an Application Service tag of "XCON", which is 3234 used to identify the centralized conferencing (XCON) server for a 3235 particular domain. The Application Protocol tag "CCMP", defined in 3236 Section 12.4.2, is used to identify an XCON server that understands 3237 the CCMP protocol. 3239 The NAPTR records in the following example Figure 29 demonstrate the 3240 use of the Application Service and Protocol tags. Iterative NAPTR 3241 resolution is used to delegate responsibility for the conferencing 3242 service from "zonea.example.com." and "zoneb.example.com." to 3243 "outsource.example.com.". 3245 zonea.example.com. 3246 ;; order pref flags 3247 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3248 "" ; regex 3249 outsource.example.com. ; replacement 3250 ) 3251 zoneb.example.com. 3252 ;; order pref flags 3253 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3254 "" ; regex 3255 outsource.example.com. ; replacement 3256 ) 3257 outsource.example.com. 3258 ;; order pref flags 3259 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 3260 "!*.!https://confs.example.com/!" ; regex 3261 . ; replacement 3262 ) 3264 Figure 29: Sample XCON:CCMP Service NAPTR Records 3266 Details for the "XCON" Application Service tag and the "CCMP" 3267 Application Protocol tag are included in Section 12.4. 3269 8. Managing Notifications 3271 As per [RFC5239], the CCMP is one of the following four protocols 3272 which have been formally identified within the XCON framework: 3273 Conference Control Protocol: between Conference and Media Control 3274 Client and Conference Server. Such protocol is the subject of the 3275 present document. 3276 Binary floor Control Protocol: between the Floor Control Client and 3277 the Floor Control Server. Such protocol is the BFCP, specified in 3278 [RFC4582]. 3279 Call Signaling Protocol: between the Call Signaling Client and the 3280 Focus. Such protocol can be either SIP or any other call 3281 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3282 a conferencing session. 3283 Notification Protocol: between the Notification Client and the XCON 3284 Notification Service. Such protocol has not been identified as 3285 yet. 3287 The CCMP protocol specified in this document is a pro-active one and 3288 is used by a conferencing client to send requests to a conferencing 3289 server in order to retrieve information about the conference objects 3290 it stores and potentially manipulate them. Though, it stands clear 3291 that a complete conferencing solution cannot refrain from providing 3292 clients with a means for receiving asynchronous updates about the 3293 status of the objects available at the server. The notification 3294 protocol to be adopted in XCON, while conceptually independent of all 3295 the mentioned companion protocols, can nonetheless be chosen in a way 3296 that is consistent with the overall protocol architecture 3297 characterizing a specific deployment, as it is discussed in the 3298 following. 3300 When the conference control client uses SIP [RFC3261] as the 3301 signaling protocol to participate in the conference, SIP event 3302 notification can be used. In such a case, the conference control 3303 client MUST implement the Conference event package for XCON 3304 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3305 conferencing clients as is SIP for signaling per the XCON Framework 3306 [RFC5239]. 3308 In the case where the interface to the conference server is entirely 3309 web based, there is a common mechanism for web-based systems that 3310 could be used - a "call back". With this mechanism, the conference 3311 client provides the conference server with an HTTP URL which is 3312 invoked when a change occurs. This is a common implementation 3313 mechanism for e-commerce. This works well in the scenarios whereby 3314 the conferencing client is a web server that provides the graphical 3315 HTML user interface and uses CCMP as the backend interface to the 3316 conference server. And, this model can co-exist with the SIP event 3317 notification model. PC-based clients behind NATs could provide a SIP 3318 event URI, whereas web-based clients using CCMP in the backend would 3319 probably find the HTTP call back approach much easier. The details 3320 of this approach are out of scope for the CCMP per se, thus the 3321 expectation is that a future specification will document this 3322 solution. 3324 9. HTTP Transport 3326 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3327 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3328 conforming conference Server and Conferencing client MUST support. 3330 Although CCMP uses HTTP as a transport, it uses a strict subset of 3331 HTTP features, and due to the restrictions of some features, a 3332 conferencing server may not be a fully compliant HTTP server. It is 3333 intended that a conference server can easily be built using an HTTP 3334 server with extensibility mechanisms, and that a conferencing client 3335 can trivially use existing HTTP libraries. This subset of 3336 requirements helps implementors avoid ambiguity with the many options 3337 the full HTTP protocol offers. 3339 A conferencing client that conforms to this specification is not 3340 required to support HTTP authentication [RFC2617] or cookies 3341 [RFC2965]. These mechanism are unnecessary because CCMP requests 3342 carry their own authentication information (in the "subject" field; 3343 see Section 5.1). 3345 A CCMP request is carried in the body of an HTTP POST request. The 3346 conferencing client MUST include a Host header in the request. 3348 The MIME type of CCMP request and response bodies is "application/ 3349 ccmp+xml". The conference server and conferencing client MUST 3350 provide this value in the HTTP Content-Type and Accept header fields. 3351 If the conference server does not receive the appropriate Content- 3352 Type and Accept header fields, the conference server SHOULD fail the 3353 request, returning a 406 (not acceptable) response. CCMP responses 3354 SHOULD include a Content-Length header. 3356 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3357 header in CCMP requests. The conference server MAY return 501 (not 3358 implemented) errors if either of these HTTP features are used. In 3359 the case that the conference server receives a request from the 3360 conferencing client containing a If-* (conditional) header, the 3361 conference server SHOULD return a 412 (precondition failed) response. 3363 The POST method is the only method REQUIRED for CCMP. If a 3364 conference server chooses to support GET or HEAD, it SHOULD consider 3365 the kind of application doing the GET. Since a conferencing client 3366 only uses a POST method, the GET or HEAD MUST be either an escaped 3367 URL (e.g., somebody found a URL in protocol traces or log files and 3368 fed it into their browser) or somebody doing testing/ debugging. The 3369 conference server could provide information in the CCMP response 3370 indicating that the URL corresponds to a conference server and only 3371 responds to CCMP POST requests or the conference server could instead 3372 try to avoid any leak of information by returning a very generic HTTP 3373 error message such as 405 (method not allowed). 3375 The conference server populates the HTTP headers of responses so that 3376 they are consistent with the contents of the message. In particular, 3377 the "CacheControl" header SHOULD be set to disable caching of any 3378 conference information by HTTP intermediaries. Otherwise, there is 3379 the risk of stale information and/or the unauthorized disclosure of 3380 the information. The HTTP status code MUST indicate a 2xx series 3381 response for all CCMP Response and Error messages. 3383 The conference server MAY redirect a CCMP request. A conferencing 3384 client MUST handle redirects, by using the Location header provided 3385 by the server in a 3xx response. When redirecting, the conferencing 3386 client MUST observe the delay indicated by the Retry-After header. 3388 The conferencing client MUST authenticate the server that returns the 3389 redirect response before following the redirect. A conferencing 3390 client SHOULD authenticate the conference server indicated in a 3391 redirect. 3393 The conference server SHOULD support persistent connections and 3394 request pipelining. If pipelining is not supported, the conference 3395 server MUST NOT allow persistent connections. The conference server 3396 MUST support termination of a response by the closing of a 3397 connection. 3399 Implementations of CCMP that implement HTTP transport MUST implement 3400 transport over TLS [RFC2818]. TLS provides message integrity and 3401 confidentiality between the conference control client and the 3402 conference control server. The conferencing client MUST implement 3403 the server authentication method described in HTTPS [RFC2818]. The 3404 device uses the URI obtained during conference server discovery to 3405 authenticate the server. The details of this authentication method 3406 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3407 the conferencing client SHOULD fail a request if server 3408 authentication fails. 3410 10. Security Considerations 3412 As identified in the XCON framework [RFC5239], there are a wide 3413 variety of potential attacks related to conferencing, due to the 3414 natural involvement of multiple endpoints and the capability to 3415 manipulate the data on the conference server using CCMP. Examples of 3416 attacks include the following: an endpoint attempting to listen to 3417 conferences in which it is not authorized to participate, an endpoint 3418 attempting to disconnect or mute other users, and theft of service by 3419 an endpoint in attempting to create conferences it is not allowed to 3420 create. 3422 The following summarizes the security considerations for CCMP: 3423 1. The client MUST determine the proper conference server. The 3424 conference server discovery is described in Section 7. 3425 2. The client MUST connect to the proper conference server. The 3426 mechanisms for addressing this security consideration are 3427 described in Section 10.1. 3428 3. The protocol MUST support a confidentiality and integrity 3429 mechanism. As described in Section 9, implementations of CCMP 3430 MUST implement the HTTP transport over TLS [RFC2818]. 3431 4. There are security issues associated with the authorization to 3432 perform actions on the conferencing system to invoke specific 3433 capabilities. A conference server SHOULD ensure that only 3434 authorized entities can manipulate the conference data. The 3435 mechanisms for addressing this security consideration are 3436 described in Section 10.2. 3437 5. The privacy and security of the identity of a user in the 3438 conference MUST be assured. The mechanisms to ensure the 3439 security and privacy of identity are discussed in Section 10.3. 3440 6. A final issue is related to Denial of Service (DoS) attacks on 3441 the conferencing server itself. In order to minimize the 3442 potential for DoS attacks, it is RECOMMENDED that conferencing 3443 systems require user authentication and authorization for any 3444 client participating in a conference. This can be accomplished 3445 through the use of the mechanisms described in Section 10.2, as 3446 well as by using the security mechanisms associated with the 3447 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 3449 10.1. Assuring that the Proper Conferencing Server has been contacted 3451 When the CCMP transaction is conducted using TLS [RFC5246], the 3452 conference server can authenticate its identity, either as a domain 3453 name or as an IP address, to the conference client by presenting a 3454 certificate containing that identifier as a subjectAltName (i.e., as 3455 an iPAddress or dNSName, respectively). With the use of HTTP as a 3456 transport for CCMP, this is exactly the authentication described by 3457 TLS [RFC2818]. If the client has external information as to the 3458 expected identity or credentials of the proper conference server 3459 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 3460 implementation of CCMP MUST be capable of being transacted over TLS 3461 so that the client can request the above authentication, and a 3462 conference server implementation MUST include this feature. Note 3463 that in order for the presented certificate to be valid at the 3464 client, the client must be able to validate the certificate. In 3465 particular, the validation path of the certificate must end in one of 3466 the client's trust anchors, even if that trust anchor is the 3467 conference server certificate itself. 3469 10.2. User Authentication and Authorization 3471 Many policy authorization decisions are based on the identity of the 3472 user or the role that a user may have. The conferencing server MUST 3473 implement mechanisms for authentication of users to validate their 3474 identity. There are several ways that a user might authenticate its 3475 identity to the system. For users joining a conference using one of 3476 the call signaling protocols, the user authentication mechanisms for 3477 the specific protocol can be used. For the case of users joining the 3478 conference using the CCMP, TLS is RECOMMENDED. 3480 The XCON Framework [RFC5239] provides an overview of other 3481 authorization mechanisms. In the cases where a user is authorized 3482 via multiple mechanisms, it is RECOMMENDED that the conference server 3483 correlate the authorization of the CCMP interface with other 3484 authorization mechanisms - e.g., PSTN users that join with a PIN and 3485 control the conference using CCMP. When a conference server presents 3486 the identity of authorized users, it MAY provide information about 3487 the way the identity was proven or verified by the system. A 3488 conference server can also allow a completely unauthenticated user 3489 into the system - this information SHOULD also be communicated to 3490 interested parties. 3492 Once a user is authenticated and authorized through the various 3493 mechanisms available on the conference server, the conference server 3494 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3495 associate the XCON-USERID with any signaling specific user 3496 identifiers that were used for authentication and authorization. 3497 This XCON-USERID can be provided to a specific user through the 3498 conference notification interface and MUST be provided to users that 3499 interact with the conferencing system using the CCMP (i.e., in the 3500 appropriate CCMP response messages). This conference user identifier 3501 is REQUIRED for any subsequent operations on the conference object. 3503 We herein remark that the definition of a complete solution for 3504 policy-based management of an XCON-compliant conference system is out 3505 of the scope of this document, as well as of the XCON WG. We believe 3506 that the specification of such a framework is orthogonal to the 3507 overall XCON architecture, especially if a Role Based Access Control 3508 (RBAC) approach is embraced. In RBAC, the following elements are 3509 identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; 3510 (v) Permissions. For all of the above elements a direct mapping 3511 exists onto the main XCON entities. As an example, RBAC objects map 3512 onto XCON data model objects and RBAC operations map onto CCMP 3513 operations. 3515 Future documents might work on the definition of an RBAC framework 3516 for XCON, by first focusing on the definition of roles and eventually 3517 arriving at the specification of the needed permission policy sets 3518 and role policy sets (used to associate policy permission sets with 3519 specific roles). With these policies in place, access to a 3520 conference object compliant with the XCON data model can be 3521 appropriately controlled. Finally, coming to the issue of assigning 3522 users to roles, this can be done through so-called role-assignment 3523 policies. Such assignment should be under the responsibility of an 3524 ad-hoc dedicated Role Assignment entity. 3526 10.3. Security and Privacy of Identity 3528 An overview of the required privacy and anonymity for users of a 3529 conferencing system are provided in the XCON Framework [RFC5239]. 3530 The security of the identity in the form of the XCON-USERID is 3531 provided in the CCMP protocol through the use of TLS. 3533 The conference server SHOULD provide mechanisms to ensure the privacy 3534 of the XCON-USERID. This is accomplished by the conference client 3535 manipulation of the "provide-anonymity" element defined in the XCON 3536 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 3537 anonymity" element controls the degree to which a user reveals their 3538 identity. The conference client MUST set the "provide-anonymity" 3539 element to "hidden" if the user does not want other participants to 3540 even be aware that there is an additional participant in the 3541 conference. The conference client MUST set the "provide-anonymity" 3542 field to "private" if the user wants to be entirely "anonymous" 3543 (i.e., other participants are aware that there is another 3544 participant, but have no information as to their identity). The 3545 conference client MUST set the "provide-anonymity" field to "semi- 3546 private" if their identity is only to be revealed to other 3547 participants or users that have a higher level authorization (e.g., a 3548 conferencing system can be configured such that an administrator can 3549 see all users). To provide the required privacy, the conference 3550 client SHOULD include the "provide-anonymity" element in the 3551 "confInfo" parameter in a CCMP confRequest message with an "update" 3552 or "create" operation or in the "userInfo" parameter in a CCMP 3553 userRequest message with an "update" or "create" operation, to ensure 3554 the user is provided the appropriate level of privacy. If the 3555 "provide-anonymity" element is not included in the conference object, 3556 then other users can see the participant's identity. 3558 11. XML Schema 3560 This section provides the XML schema definition of the "application/ 3561 ccmp+xml" format. 3563 3565 3574 3577 3580 3581 3583 3585 3586 3587 3589 3590 3592 3594 3596 3597 3599 3601 3603 3605 3607 3609 3610 3611 3613 3615 3616 3617 3619 3620 3622 3624 3625 3626 3628 3630 3633 3635 3637 3639 3641 3642 3643 3645 3647 3649 3650 3651 3652 3653 3654 3655 3656 3657 3659 3661 3663 3664 3665 3667 3669 3670 3671 3672 3674 3675 3676 3677 3678 3679 3680 3681 3682 3684 3686 3688 3689 3690 3692 3694 3695 3696 3698 3700 3701 3702 3703 3704 3705 3706 3707 3708 3710 3712 3714 3715 3716 3718 3721 3722 3723 3725 3727 3728 3729 3730 3731 3732 3733 3734 3735 3737 3739 3741 3742 3743 3745 3747 3748 3749 3751 3753 3754 3755 3756 3757 3758 3759 3760 3761 3763 3765 3767 3768 3769 3771 3773 3774 3775 3777 3779 3780 3781 3782 3783 3784 3785 3786 3787 3789 3791 3793 3794 3795 3797 3799 3800 3801 3803 3805 3806 3807 3808 3809 3810 3811 3812 3813 3815 3816 3819 3820 3821 3823 3825 3826 3827 3829 3831 3832 3833 3834 3835 3836 3837 3838 3839 3841 3843 3846 3847 3848 3850 3852 3853 3854 3856 3858 3859 3860 3861 3862 3863 3865 3866 3867 3869 3871 3874 3875 3876 3878 3880 3881 3882 3884 3886 3887 3888 3889 3890 3891 3892 3893 3894 3896 3898 3901 3902 3903 3905 3907 3908 3909 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3922 3924 3926 3927 3928 3930 3932 3933 3935 3937 3938 3939 3940 3941 3942 3944 3946 3948 3949 3950 3951 3952 3953 3954 3955 3956 3958 3959 3961 3962 3963 3965 3967 3968 3969 3971 3973 3974 3975 3976 3977 3978 3979 3980 3981 3983 3985 3987 3988 3989 3991 3993 3994 3995 3997 3999 4000 4001 4002 4003 4004 4005 4006 4008 4010 4012 4014 4015 4016 4018 4020 4021 4022 4024 4026 4027 4028 4029 4030 4031 4032 4033 4034 4036 4038 4040 4041 4042 4044 4046 4047 4048 4050 4052 4053 4054 4055 4056 4057 4058 4059 4060 4062 4064 4066 4067 4068 4070 4072 4073 4074 4076 4078 4079 4080 4081 4082 4083 4084 4085 4086 4088 4090 4092 4093 4094 4096 4098 4099 4100 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4113 4115 4118 4119 4120 4122 4124 4125 4126 4128 4130 4131 4132 4133 4134 4135 4136 4137 4138 4140 4142 4145 4146 4147 4149 4152 4153 4154 4156 4158 4159 4160 4161 4162 4163 4164 4165 4166 4168 4170 4173 4174 4175 4177 4179 4180 4181 4183 4185 4186 4187 4188 4189 4190 4191 4192 4193 4195 4197 4200 4201 4202 4204 4206 4207 4208 4210 4212 4213 4214 4215 4216 4217 4218 4219 4220 4222 4224 4226 4227 4228 4230 4233 4234 4236 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4249 4252 4253 4254 4256 4258 4259 4260 4262 4264 4266 4268 4269 4270 4271 4272 4274 4276 4277 4278 4279 4280 4281 4282 4283 4285 4287 4288 4289 4291 4293 4296 4297 4298 4300 4302 4303 4304 4307 4310 4312 4313 4314 4316 4318 4319 4320 4323 4325 4326 4327 4329 4331 4332 4333 4336 4339 4340 4341 4343 4344 4345 4347 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4364 4366 4367 4368 4370 4371 4372 4374 4376 4377 4378 4381 4383 4384 4385 4387 4389 4390 4391 4392 4395 4396 4399 4401 4402 4403 4405 4407 Figure 30 4409 12. IANA Considerations 4411 This document registers a new XML namespace, a new XML schema, and 4412 the MIME type for the schema. This document also registers the 4413 "XCON" Application Service tag and the "CCMP" Application Protocol 4414 tag. This document also defines registries for the CCMP operation 4415 types and response codes. 4417 12.1. URN Sub-Namespace Registration 4419 This section registers a new XML namespace, 4420 ""urn:ietf:params:xml:ns:xcon:ccmp"". 4422 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 4423 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4424 Mary Barnes (mary.ietf.barnes@gmail.com). 4425 XML: 4427 BEGIN 4428 4429 4431 4432 4433 CCMP Messages 4434 4435 4436

Namespace for CCMP Messages

4437

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

4438 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4439 with the RFC number for this specification.]] 4440

See RFCXXXX.

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