idnits 2.17.1 draft-ietf-xcon-ccmp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 31 characters in excess of 72. 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 (June 18, 2010) is 5060 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: 'RP' is mentioned on line 1472, but not defined == Missing Reference: '0-9' is mentioned on line 3797, but not defined == Unused Reference: 'RFC3966' is defined on line 4318, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-examples' is defined on line 4331, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-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) == Outdated reference: A later version (-10) exists of draft-ietf-xcon-examples-04 Summary: 6 errors (**), 0 flaws (~~), 8 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 Nortel 4 Intended status: Standards Track C. Boulton 5 Expires: December 20, 2010 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 June 18, 2010 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-08 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 December 20, 2010. 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. optionsRequest and optionsResponse . . . . . . . . . . 19 74 5.3.2. blueprintsRequest and blueprintsResponse . . . . . . . 21 75 5.3.3. confsRequest and confsResponse . . . . . . . . . . . . 23 76 5.3.4. blueprintRequest and blueprintResponse . . . . . . . . 25 77 5.3.5. confRequest and confResponse . . . . . . . . . . . . . 27 78 5.3.6. usersRequest and usersResponse . . . . . . . . . . . . 31 79 5.3.7. userRequest and userResponse . . . . . . . . . . . . . 33 80 5.3.8. sidebarsByValRequest and sidebarsByValResponse . . . . 37 81 5.3.9. sidebarByValRequest and sidebarByValResponse . . . . . 39 82 5.3.10. sidebarsByRefRequest and sidebarsByRefResponse . . . . 42 83 5.3.11. sidebarByRefRequest and sidebarByRefResponse . . . . . 43 84 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 46 85 6. A complete example of the CCMP in action . . . . . . . . . . . 49 86 6.1. Alice retrieves the available blueprints . . . . . . . . . 50 87 6.2. Alice gets detailed information about a specific 88 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 52 89 6.3. Alice creates a new conference through a cloning 90 operation . . . . . . . . . . . . . . . . . . . . . . . . 54 91 6.4. Alice updates conference information . . . . . . . . . . . 57 92 6.5. Alice inserts a list of users in the conference object . . 59 93 6.6. Alice joins the conference . . . . . . . . . . . . . . . . 60 94 6.7. Alice adds a new user to the conference . . . . . . . . . 62 95 7. Locating a Conference Control Server . . . . . . . . . . . . . 64 96 8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 66 97 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 67 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 99 10.1. Assuring that the Proper Conferencing Server has been 100 contacted . . . . . . . . . . . . . . . . . . . . . . . . 69 101 10.2. User Authentication and Authorization . . . . . . . . . . 70 102 10.3. Security and Privacy of Identity . . . . . . . . . . . . . 71 103 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 72 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 105 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 88 106 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 89 107 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 89 108 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 90 109 12.4.1. Registration of a Conference Control Server 110 Application Service Tag . . . . . . . . . . . . . . . 90 111 12.4.2. Registration of a Conference Control Server 112 Application Protocol Tag for CCMP . . . . . . . . . . 91 113 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 91 114 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 91 115 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 92 116 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 117 14. Changes since last Version . . . . . . . . . . . . . . . . . . 94 118 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 119 15.1. Normative References . . . . . . . . . . . . . . . . . . . 95 120 15.2. Informative References . . . . . . . . . . . . . . . . . . 95 121 Appendix A. Appendix A: Other protocol models and transports 122 considered for CCMP . . . . . . . . . . . . . . . . . 97 123 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 97 124 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 98 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 127 1. Introduction 129 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 130 defines a signaling-agnostic framework, naming conventions and 131 logical entities required for building advanced conferencing systems. 132 The XCON Framework introduces the conference object as a logical 133 representation of a conference instance, representing the current 134 state and capabilities of a conference. 136 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 137 this document allows authenticated and authorized users to create, 138 manipulate and delete conference objects. Operations on conferences 139 include adding and removing participants, changing their roles, as 140 well as adding and removing media streams and associated end points. 142 The CCMP implements the client-server model within the XCON 143 Framework, with the Conference Control Client and Conference Control 144 Server acting as client and server, respectively. The CCMP uses HTTP 145 [RFC2616] as the protocol to transfer requests and responses, which 146 contain the domain-specific XML-encoded data objects defined in 147 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 148 for Centralized Conferencing (XCON Data Model). 150 Section 2 clarifies the conventions and terminology used in the 151 document. Section 3 provides an overview of the Conference Control 152 functionality of the XCON framework, together with a description of 153 the main targets CCMP deals with, namely conference objects and 154 conference users. A general description of the operations associated 155 with protocol messages is given in Section 4 together with 156 implementation details. Section 5 delves into the details of the 157 specific CCMP messages. A complete, not normative, example of the 158 operation of the CCMP, describing a typical call flow associated with 159 conference creation and manipulation, is provided in Section 6. A 160 survey of the methods that can be used to locate a Conference Control 161 Server is provided in Section 7, whereas Section 8 discusses 162 potential approaches to notifications management. CCMP transport 163 over HTTP is highlighted in Section 9. Security considerations are 164 presented in Section 10. Finally, Section 11 provides the XML 165 schema. 167 2. Conventions and Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 In additon to the terms defined in the Framework for Centralized 174 Conferencing [RFC5239], this document uses the following terms and 175 acronyms: 177 XCON aware client: An XCON conferencing system client which is able 178 to issue CCMP requests. 180 3. XCON Conference Control System Architecture 182 CCMP supports the XCON framework . Figure 1 depicts a subset of the 183 "Conferencing System Logical Decomposition" architecture from the 184 XCON framework document. It illustrates the role that CCMP assumes 185 within the overall centralized architecture. 187 ........................................................ 188 . Conferencing System . 189 . . 190 . +---------------------------------------+ . 191 . | C O N F E R E N C E O B J E C T | . 192 . +-+-------------------------------------+ | . 193 . | C O N F E R E N C E O B J E C T | | . 194 . +-+-------------------------------------+ | | . 195 . | C O N F E R E N C E O B J E C T | | | . 196 . | | |-+ . 197 . | |-+ . 198 . +---------------------------------------+ . 199 . ^ . 200 . | . 201 . v . 202 . +-------------------+ . 203 . | Conference Control| . 204 . | Server | . 205 . +-------------------+ . 206 . ^ . 207 .........................|.............................. 208 | 209 |Centralized 210 |Conferencing 211 |Manipulation 212 |Protocol 213 | 214 .........................|.............................. 215 . V . 216 . +----------------+ . 217 . | Conference | . 218 . | Control | . 219 . | Client | . 220 . +----------------+ . 221 . . 222 . Conferencing Client . 223 ........................................................ 225 Figure 1: Conference Client Interaction 227 CCMP serves as the Conference Control Protocol, allowing the 228 conference control client to interface with the conference object 229 maintained by the conferencing system, as represented in Figure 1. 230 Conference Control is one part of functionality for advanced 231 conferencing supported by a conferencing client. Other functions are 232 discussed in the XCON framework and related documents. 234 Conference object and conference users do represent key elements 235 involved in Conference Control Protocol operations. Their 236 identifiers, respectively the conference XCON-URI and the 237 conferencing client XCON-USERID, and their XML representations 238 compliant with the XML Schema defined in the XCON data model are 239 widely used for creating the CCMP requests and responses. The main 240 conference objects and users features envisioned by the XCON 241 framework are briefly described in the following subsections. 243 3.1. Conference Objects 245 Conference objects feature a simple dynamic inheritance-and-override 246 mechanism. Conference objects are linked into a tree known as 247 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 248 node inherits attributes from its parent node. The roots of these 249 inheritance trees are conference templates also known as 250 "blueprints". Nodes in the inheritance tree can be active 251 conferences or simply descriptions that do not currently have any 252 resources associated with them (conference reservations). An object 253 can mark certain of its properties as unalterable, so that they 254 cannot be overridden. It is envisaged by the framework that a client 255 may specify a parent object (a conference or blueprint) from which 256 the conference to be created has to inherit values by the mean of the 257 Conference Control Protocol. 259 Conference objects are uniquely identified by the XCON-URI within the 260 scope of the conferencing system. Such identifier is introduced in 261 the XCON framework and defined in the XCON common data model. 263 Conference objects are comprehensively represented through XML 264 documents compliant with the XML Schema defined in the XCON data 265 model [I-D.ietf-xcon-common-data-model]. The root element of such 266 documents, called "", is of type "conference-type". 267 It encompasses other XML elements describing different conference 268 features and users as well. By the mean of CCMP, conferencing 269 clients can use such XML structures to express their preferences in 270 creation or update. A conferencing server can convey conference 271 information of such a form back to the clients. 273 3.2. Conference Users 275 Each conference can have zero or more users. All conference 276 participants are users, but some users may have only administrative 277 functions and do not contribute or receive media. Users are added 278 one user at a time to simplify error reporting. When a conference is 279 cloned from a parent object, users are inherited as well, so that it 280 is easy to set up a conference that has the same set of participants 281 or a common administrator. The Conference Control Server creates 282 individual users, assigning them a unique Conference User Identifier 283 (XCON-USERID). The XCON-USERID as identifier of each conferencing 284 system client is introduced in the XCON framework and defined in the 285 XCON common data model. Each CCMP request, with an exception pointed 286 out in Section 5.3.7 representing the case of a user at his first 287 entrance in the system as a conference participant, must carry the 288 XCON-USERID of the requestor in the proper "confUserID" parameter. 290 The XCON-USERID acts as a pointer to the user's profile as a 291 conference actor, e.g. her signalling URI and other XCON protocol 292 URIs in general, her role (moderator, participant, observer, etc.), 293 her display text, her joining information and so on. A variety of 294 elements defined in the common element as specified 295 in the XCON data model are used to describe the users related to a 296 conference, in the first place the element, as well as each 297 element included in it. For example, it is possible to 298 determine how a specific user expects and is allowed to join a 299 conference by looking at the in : each 300 element involved in such a list represents a user and shows 301 a "method" attribute defining how the user is expected to join the 302 conference, i.e. "dial-in" for users that are allowed to dial, "dial- 303 out" for users that the conference focus will be trying to reach 304 (with "dial-in" being the default mode). If the conference is 305 currently active, dial-out users are contacted immediately; 306 otherwise, they are contacted at the start of the conference. The 307 CCMP, acting as the Conference Control Protocol, provides a means to 308 manipulate these and other kinds of user-related features. 310 As a consequence of an explicit user registration to a specific XCON 311 conferencing system, conferencing clients are usually provided 312 (besides the XCON-USERID) with log-in credentials (i.e. username and 313 password). Such credentials can be used to authenticate the XCON 314 aware client issuing CCMP requests. To this purpose, both username 315 and password should be carried in a CCMP request as part of the 316 "subject" parameter whenever a registered conferencing client wishes 317 to contact a CCMP server. The CCMP does not look after users 318 subscriptions at the conference server; hence, it does not provide 319 any specific mechanism allowing clients to register their 320 conferencing accounts. The "subject" parameter is just used for 321 carrying authentication data associated with pre-registered clients. 323 4. Protocol Overview 325 CCMP is a client-server, XML-based protocol, which has been 326 specifically conceived to provide users with the necessary means for 327 the creation, retrieval, modification and deletion of conference 328 objects. CCMP is also state-less, which means implementations can 329 safely handle transactions independently from each other. 330 Conference-related information is encapsulated into CCMP messages in 331 the form of XML documents or XML document fragments compliant with 332 the XCON data model representation. 334 Section 4.1 specifies the basic operations that can create, retrieve, 335 modify and delete conference-related information in a centralized 336 conference. The core set of objects manipulated in the CCMP protocol 337 includes conference blueprints, the conference object, users, and 338 sidebars. 340 CCMP has been conceived as completely independent from underlying 341 protocols, which means that there can be different ways to carry CCMP 342 messages across the network, from a conferencing client to a 343 conferencing server. Nevertheless, it is recommended to use HTTP as 344 a transport solution, including CCMP requests in HTTP POST messages 345 and CCMP responses in HTTP 200 OK replies. Implementation details 346 are presented in Section 4.2 348 4.1. Protocol Operations 350 The main operations provided by CCMP belong in four general 351 categories: 353 create: for the creation of a conference, a conference user, a 354 sidebar, or a blueprint. 355 retrieve: to get information about the current state of either a 356 conference object (be it an actual conference or a blueprint, or a 357 sidebar) or a conference user. A retrieve operation can also be 358 used to obtain the XCON-URIs of the current conferences (active or 359 registered) handled by the conferencing server and/or the 360 available blueprints. 361 update: to modify the current features of a specified conference or 362 conference user. 363 delete: to remove from the system a conference object or a 364 conference user. 366 Thus, the main targets of CCMP operations are: 368 o conference objects associated with either active or registered 369 conferences, 370 o conference objects associated with blueprints, 371 o conference objects associated with sidebars, both embedded in the 372 main conference (i.e. elements in ) and 373 external to it (i.e. whose xcon-uris are included in the 374 elements of ), 376 o elements associated with conference users, 377 o the list of XCON-URIs related to conferences and blueprints 378 available at the server, for which only retrieval operations are 379 allowed. 381 Each operation in the protocol model is atomic and either succeeds or 382 fails as a whole. The conference server must ensure that the 383 operations are atomic in that the operation invoked by a specific 384 conference client completes prior to another client's operation on 385 the same conference object. The details for this data locking 386 functionality are out of scope for the CCMP protocol specification 387 and are implementation specific for a conference server. Thus, the 388 conference server first checks all the parameters, before making any 389 changes to the internal representation of the conference object. For 390 example, it would be undesirable to change the of the 391 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 393 can modify the same conference objects, conference clients should 394 first obtain the current object from the conference server and then 395 update the relevant data elements in the conference object prior to 396 invoking a specific operation on the conference server. In order to 397 effectively manage modifications to conference data, a versioning 398 approach is exploited in the CCMP. More precisely, each conference 399 object is associated with a version number indicating the most up to 400 date view of the conference at the server's side. Such version 401 number is reported to the clients when answering their requests. A 402 client willing to make modifications to a conference object has to 403 send an update message to the server. In case the modifications are 404 all successfully applied, the server sends back to the client a "200" 405 response which also carries information about the current server-side 406 version of the modified object. With such approach, a client which 407 is working on version "X" of a conference object and finds inside a 408 "200" response a version number which is "X+1" can be sure that the 409 version it was aware of was the most up to date. On the other hand, 410 if the "200" response carries back a version which is at least "X+2", 411 the client can detect that the object that has been modified at the 412 server's side was more up to date than the one it was working upon. 413 This is clearly due to the effect of concurrent modification requests 414 issued by independent clients. Hence, for the sake of having 415 available the latest version of the modified object, the client can 416 send to the conference server a further "retrieve" request. In no 417 case a copy of the conference object available at the server is 418 returned to the client as part of the update response message. Such 419 a copy can always be obtained through an ad-hoc "retrieve" message. 421 Based on the above considerations, all CCMP response messages 422 carrying in their body a conference document (or a fragment of it) 423 must contain a "version" parameter. This does not hold for request 424 messages, for which the "version" parameter is not at all required, 425 since it represents useless information for the server: as long as 426 the required modifications can be applied to the target conference 427 object with no conflicts, the server does not care whether or not the 428 client had an up to date view of the information stored at its side. 429 This said, it stands clear that a client which has subscribed at the 430 server, through the XCON event package [I-D.ietf-xcon-event-package], 431 to notifications about conference object modifications, will always 432 have the most up to date version of that object available at his 433 side. 435 A final consideration concerns the relation between the CCMP and the 436 main entities it manages, i.e. conference objects. Such objects have 437 to be compliant with the XCON data-model, which identifies some 438 elements/attributes as mandatory. From the CCMP standpoint this can 439 become a problem in cases of client-initiated operations, like the 440 creation/update of conference objects. In such cases, not all of the 441 mandatory data can be known in advance to the client issuing a CCMP 442 request. As an example, a client has no means to know, at the time 443 it issues a conference creation request, the XCON-URI that the server 444 will assign to the yet-to-be-created conference and hence it is not 445 able to appropriately fill with that value the mandatory "entity" 446 attribute of the conference document contained in the request. To 447 solve this kind of issues, the CCMP will fill all mandatory data 448 model fields, for which no value is available at the client at the 449 time the request is constructed, with fake values in the form of 450 wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental 451 index initialized to a value of 1). Upon reception of the mentioned 452 kinds of requests, the server will: (i) generate the proper 453 identifier(s); (ii) produce a response in which the received fake 454 identifier(s) carried in the request has (have) been replaced by the 455 newly created one(s). With this approach we maintain compatibility 456 with the data model requirements, at the same time allowing for 457 client-initiated manipulation of conference objects at the server's 458 side (which is, by the way, one of the main goals for which the CCMP 459 protocol has been conceived at the outset). 461 4.2. Implementation Approach 463 There have been a number of different proposals as to the most 464 suitable implementation solution for the CCMP. A non-exhaustive 465 summary of the most interesting ones is provided in Appendix A. The 466 solution for the CCMP defined in this document is viewed as a good 467 compromise amongst the most notable past candidates and is referred 468 to as "HTTP single-verb transport plus CCMP body". With this 469 approach, CCMP is able to take advantage of existing HTTP 470 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 471 transport (i.e. a single transaction type for each request/response 472 pair); this allows decoupling CCMP messages from HTTP messages. 473 Similarly, as with any RESTful approach, CCMP messages are inserted 474 directly in the body of HTTP messages, thus avoiding any unnecessary 475 processing and communication burden associated with further 476 intermediaries. With this approach, no modification to the CCMP 477 messages/operations is required to use a different transport 478 protocol. 480 The remainder of this document focuses on the selected approach. The 481 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 482 POST operations and retrieves responses from the body of HTTP "200 483 OK" messages. CCMP messages have a MIME-type of "application/ 484 ccmp+xml", which appears inside the "Content-Type" and "Accept" 485 fields of HTTP requests and responses. Section 9 provides the 486 complete requirements for an HTTP implementation to support the CCMP. 488 5. CCMP messages 490 CCMP messages are either requests or responses. The general CCMP 491 request message is defined in Section 5.1. The general CCMP response 492 message is defined in Section 5.2. The details of the specific 493 message type which is carried in the CCMP request and response 494 messages are described in Section 5.3. CCMP response codes are 495 listed in Section 5.4 497 5.1. CCMP Request Message Type 499 A CCMP request message is comprised of the following parameters: 501 subject: An optional parameter containing username and password of 502 the client registered at the conferencing system. Each user who 503 subscribes to the conferencing system is assumed to be equipped 504 with those credentials and SHOULD enclose them in each CCMP 505 request she issues. These fields can be used to control that the 506 user sending the CCMP request has the authority to perform the 507 entailed operation. The same fields can also be exploited to 508 carry out other Authorization, Authentication and Accounting (AAA) 509 procedures. 510 confUserID: An optional parameter containing the XCON-USERID of the 511 client. The XCON-USERID is used to identify any conferencing 512 client within the context of the conferencing system and it is 513 assinged by the conferencing server at each conferencing client 514 who interacts with it. The "confUserID" parameter is REQUIRED in 515 the CCMP request and response messages with the exception of the 516 case of a user who has no XCON-USERID and who wants to enter, via 517 CCMP, a conference whose identifier is known. In such case, a 518 side-effect of the request is that the user is provided with an 519 appropriate XCON-USERID. An example of the above mentioned case 520 will be provided in Section 5.3.7. 521 confObjID: An optional parameter containing the XCON-URI of the 522 target conference object. 523 operation: An optional parameter refining the type of specialized 524 request message. The "operation" parameter is REQUIRED in all 525 requests except for the "blueprintsRequest" and "confsRequest" 526 specialized messages. 527 conference-password: An optional parameter that MUST be inserted in 528 all requests whose target conference object is password-protected 529 (as per the element in 530 [I-D.ietf-xcon-common-data-model]). 531 specialized request message: This is specialization of the generic 532 request message (e.g., blueprintsRequest), containing parameters 533 that are dependent on the specific request sent to the server. A 534 specialized request message MUST be included in the CCMP request 535 message. The details for the specialized messages and associated 536 parameters are provided in Section 5.3. 538 540 542 544 545 546 548 549 551 553 555 556 558 560 562 564 566 568 569 570 572 Figure 2: Structure of CCMP Request messages 574 5.2. CCMP Response Message Type 576 A CCMP response message is comprised of the following parameters: 578 confUserID: A mandatory parameter in CCMP response messages 579 containing the XCON-USERID of the conferencing client who issued 580 the CCMP request message. 582 confObjID: An optional parameter containing the XCON-URI of the 583 target conference object. 584 operation: An optional parameter for CCMP response messages. This 585 parameter is REQUIRED in all responses except for the 586 "blueprintsResponse" and "confsResponse" specialized messages. 587 response-code: A mandatory parameter containing the response code 588 associated with the request. The response code MUST be chosen 589 from the codes listed in Section 5.4. 590 response-string: An optional reason string associated with the 591 response. In case of an error, in particular, such string can be 592 used to provide the client with detailed information about the 593 error itself. 594 version: An optional parameter reflecting the current version number 595 of the conference object referred by the confObjID. This number 596 is contained in the "version" attribute of the 597 element related to that conference. 598 specialized response message: This is specialization of the generic 599 response message, containing parameters that are dependent on the 600 specific request sent to the server (e.g., blueprintsResponse). A 601 specialized response message SHOULD be included in the CCMP 602 response message, except in an error situation where the CCMP 603 request message did not contain a valid specialized message. In 604 this case, the conference server MUST return a "response-code" of 605 "400". The details for the specialized messages and associated 606 parameters are provided in Section 5.3. 608 610 612 614 615 616 618 619 621 623 625 626 628 630 632 634 636 638 640 641 642 644 Figure 3: Structure of CCMP Response message 646 5.3. Detailed messages 648 Based on the request and response message structures described in 649 Section 5.1 and Section 5.2, the following summarizes the specialized 650 CCMP request/response types described in this document: 652 1. optionsRequest/optionsResponse 653 2. blueprintsRequest/blueprintsResponse 654 3. confsRequest/confsResponse 655 4. blueprintRequest/blueprintResponse 656 5. confRequest/confResponse 657 6. usersRequest/usersResponse 658 7. userRequest/userResponse 659 8. sidebarsByValRequest/sidebarsByValResponse 660 9. sidebarsByRefRequest/sidebarsByRefResponse 661 10. sidebarByValRequest/sidebarByValResponse 662 11. sidebarByRefRequest/sidebarByRefResponse 664 These CCMP request/response pairs use the fundamental CCMP operations 665 as defined in Section 4.1 to manipulate the conference data. The 666 optionsRequest/optionsResponse message pair deserves a specific 667 discussion, since it is not used for manipulating information about 668 either conferences or conference users, but rather to retrieve 669 general information about conference server capabilities, in terms of 670 standard CCMP messages it supports, plus potential extension messages 671 it understands, as it will be further explained in Section 5.3.1. 672 Table 1 summarizes the remaining CCMP operations and corresponding 673 actions that are valid for a specific CCMP request type, noting that 674 neither the blueprintsRequest/blueprintsResponse nor confsRequest/ 675 confsResponse require an "operation" parameter. The corresponding 676 response MUST contain the same operation. Note that some entries are 677 labeled "N/A" indicating the operation is invalid for that request 678 type. In the case of an "N/A*", the operation MAY be allowed for 679 specific privileged users or system administrators, but is not part 680 of the functionality included in this document. 682 +---------------+------------+------------+------------+------------+ 683 | Operation | Retrieve | Create | Update | Delete | 684 | ------------- | | | | | 685 | Request Type | | | | | 686 +---------------+------------+------------+------------+------------+ 687 | blueprints | Get list | N/A | N/A | N/A | 688 | Request | of | | | | 689 | | blueprints | | | | 690 | ------------- | ---------- | ---------- | ---------- | ---------- | 691 | blueprint | Get | N/A* | N/A* | N/A* | 692 | Request | blueprint | | | | 693 | ------------- | ---------- | ---------- | ---------- | ---------- | 694 | confsRequest | Get list | N/A | N/A | N/A | 695 | | of confs | | | | 696 | ------------- | ---------- | ---------- | ---------- | ---------- | 697 | confRequest | Gets | Creates | Changes | Deletes | 698 | | conference | conference | conference | conference | 699 | | object | object | object | object | 700 | ------------- | ---------- | ---------- | ---------- | ---------- | 701 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 702 | | | | | | 703 | ------------- | ---------- | ---------- | ---------- | ---------- | 704 | userRequest | Gets | Adds a | Changes | Deletes | 705 | | specified | to | specified | specified | 706 | | | a conf | | | 707 | | | (***) | | | 708 | ------------- | ---------- | ---------- | ---------- | ---------- | 709 | sidebarsByVal | Gets | N/A | N/A | N/A | 710 | Request | | | | | 712 | ------------- | ---------- | ---------- | ---------- | ---------- | 713 | sidebarsByRef | Gets | N/A | N/A | N/A | 714 | Request | | | | | 716 | ------------- | ---------- | ---------- | ---------- | ---------- | 717 | sidebarByVal | Gets | Creates | Changes | Deletes | 718 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 719 | | by-val | by-val | by-val | by-val | 720 | ------------- | ---------- | ---------- | ---------- | ---------- | 721 | sidebarByRef | Gets | Creates | Changes | Deletes | 722 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 723 | | by-ref | by-ref | by-ref | by-ref | 724 +---------------+------------+------------+------------+------------+ 726 Table 1: Request Type Operation Specific Processing 728 (**): These operations are not allowed for a usersRequest message, 729 since the section, which is the target element of such a 730 request, is created and removed in conjuntcion with, respectively, 731 the creation and deletion of the associated conference document. 732 Thus, "update" and "retrieve" are the only semantically correct 733 operations for such message. 735 (***): This operation can involve the creation of an XCON-USERID, if 736 the sender does not add it in the "confUserID" parameter, and/or if 737 the "entity" field of the "userInfo" parameter is void. 739 Additional parameters included in the specialized CCMP request/ 740 response messages are detailed in the subsequent sections. 742 5.3.1. optionsRequest and optionsResponse 744 An "optionsRequest" (Figure 4) message is basic CCMP message, i.e. it 745 does not provide any specialization of the general CCMP request. 746 Coming to the response, it can contain information about both 747 standard (i.e. IETF-defined) CCMP messages and extension messages 748 supported by the server. In both cases, the response carries back a 749 list of names of the supported (standard and extended) messages. 750 Since all CCMP messages can potentially contain XML elements not 751 envisioned in the CCMP schema (due to the presence of elements 752 and attributes), a reference to a proper schema definition specifying 753 such new elements/attributes can also be sent back to the clients (in 754 the element). 756 757 758 759 760 762 763 764 765 766 767 768 769 770 772 775 776 777 779 781 782 783 785 786 787 789 791 793 794 795 797 798 799 800 802 803 804 806 807 808 809 810 811 813 814 815 817 818 819 820 821 822 823 824 825 826 827 828 829 830 832 833 834 835 837 838 839 841 842 843 844 845 846 848 849 850 852 854 Figure 4: Structure of the optionsRequest and optionsResponse 855 messages 857 5.3.2. blueprintsRequest and blueprintsResponse 859 A "blueprintsRequest" (Figure 5) message is sent to request the list 860 of XCON-URIs associated with the available blueprints from the 861 conference server. Such URIs can be subsequently used by the client 862 to access detailed information about a specified blueprint with a 863 specific blueprintRequest message per Section 5.3.4. The 864 "confUserID" parameter MUST be included in every blueprintsRequest/ 865 Response message and reflect the XCON-USERID of the conferencing 866 client issuing the request. A blueprintsRequest message REQUIRES no 867 "confObjID" and "operation" parameters, since it is not targetted to 868 a specific conference instance and it is conceived as a "retrieve- 869 only" request. In order to obtain a specific subset of the available 870 blueprints, a client may specify a selection filter providing an 871 appropriate xpath query in the optional "xpathFilter" parameter of 872 the request. For example, to select blueprints having both audio and 873 video stream support, a possible xpathFilter value could be: "/ 874 conference-info[conference-description/available-media/entry/ 875 type='audio' and conference-description/available-media/entry/ 876 type='video']". 878 The associated "blueprintsResponse" message SHOULD contain, as shown 879 in Figure 5, a "blueprintsInfo" parameter containing the above 880 mentioned XCON-URI list. 882 884 885 886 887 888 889 890 891 892 894 896 898 899 900 901 903 904 905 907 909 910 911 912 913 914 915 917 918 920 922 924 925 926 928 930 931 932 934 Figure 5: Structure of the blueprintsRequest and blueprintsResponse 935 messages 937 5.3.3. confsRequest and confsResponse 939 A "confsRequest" message is used to retrieve, from the server, the 940 list of XCON-URIs associated with active and registered conferences 941 currently handled by the conferencing system. The "confUserID" 942 parameter MUST be included in every confsRequest/Response message and 943 reflect the XCON-USERID of the conferencing client issuing the 944 request. The "confObjID" parameter MUST NOT be included in the 945 confsRequest message. The "confsRequest" message is of a "retrieve- 946 only" type, since the sole purpose is to collect information 947 available at the conference server. Thus, an "operation" parameter 948 MUST NOT be included in a "confsRequest" message. In order to 949 retrieve a specific subset of the available conferences, a client may 950 specify a selection filter providing an appropriate xpath query in 951 the optional "xpathFilter" parameter of the request. For example, to 952 select only the registered conferences, a possible xpathFilter value 953 could be: "/conference-info[conference-description/conference-state/ 954 active='false']". The associated "confsResponse" message SHOULD 955 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 956 upon receipt of the response message, can interact with the available 957 conference objects through further CCMP messages. 959 961 962 963 964 965 966 967 968 969 971 973 975 976 977 978 980 981 982 984 986 987 988 989 990 991 992 993 994 996 998 1000 1001 1002 1004 1006 1007 1008 1009 Figure 6: Structure of the confsRequest and confsResponse messages 1011 5.3.4. blueprintRequest and blueprintResponse 1013 Through a "blueprintRequest", a client can manipulate the conference 1014 object associated with a specified blueprint. Further than the 1015 "confUserID" parameter, the request MUST include the "confObjID" and 1016 the "operation" one. Again, the "confUserID" parameter MUST be 1017 included in every blueprintRequest/Response message and reflect the 1018 XCON-USERID of the conferencing client issuing the request. The 1019 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 1020 which might have been previously retrieved through a 1021 "blueprintsRequest" message. 1023 The blueprintRequest message SHOULD NOT contain an "operation" 1024 parameter other than "retrieve". The "create", "update" and "delete" 1025 operations SHOULD NOT be included in a "blueprintRequest" message 1026 except in the case of privileged users (e.g. the conference server 1027 administration staff), who might authenticate themselves by the mean 1028 of the "subject" request parameter. 1030 A blueprintRequest/retrieve carrying a "confObjID" which is not 1031 associated with one of the available system's blueprints will 1032 generate, on the server's side, a blueprintResponse message 1033 containing a "404" error code. This holds also for the case in which 1034 the mentioned "confObjID" is related to an existing conference 1035 document stored at the server, but associated with an actual 1036 conference (be it active or registered) or with a sidebar rather than 1037 a blueprint. 1039 In the case of "response-code" of "200" for a "retrieve" operation, 1040 the "blueprintInfo" parameter MUST be included in the 1041 "blueprintResponse" message. The "blueprintInfo" parameter contains 1042 the conference document associated with the blueprint as identified 1043 by the "confObjID" parameter specified in the blueprintRequest. 1045 1047 1048 1049 1050 1051 1052 1053 1054 1056 1058 1060 1062 1063 1064 1066 1068 1069 1070 1072 1074 1075 1076 1077 1078 1079 1080 1081 1082 1084 1086 1088 1089 1090 1092 1094 1095 1096 1098 Figure 7: Structure of the blueprintRequest and blueprintResponse 1099 messages 1101 5.3.5. confRequest and confResponse 1103 With a "confRequest" message, CCMP clients can manipulate conference 1104 objects associated with either active or registered conferences. The 1105 "confUserID" parameter MUST be included in every confRequest/Response 1106 message and reflect the XCON-USERID of the conferencing client 1107 issuing the request. ConfRequest and confResponse messages MUST also 1108 include an "operation" parameter. ConfResponse messages MUST return 1109 to the requestor a "response-code" and MAY contain a "response- 1110 string" explaining it. Depending upon the type of "operation", a 1111 "confObjID" and "confInfo" parameter MAY be included in the 1112 confRequest and response. The requirements for inclusion of 1113 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1114 messages and are detailed below for each "operation" case. 1116 The creation case deserves care. To create a new conference through 1117 a "confRequest" message, two approaches can be considered: 1119 1. Creation through explicit cloning: the "confObjID" parameter MUST 1120 contain the XCON-URI of the blueprint or of the conference to be 1121 cloned, while the "confInfo" parameter MUST NOT be included in 1122 the confRequest; 1123 2. Creation through implicit cloning (also known as "direct 1124 creation"): the "confObjID" parameter MUST NOT be included in the 1125 request and the CCMP client can describe the desired conference 1126 to be created using the "confInfo" parameter. If no "confInfo" 1127 parameter is provided in the request, the new conference will be 1128 created as a clone of the system default blueprint. 1130 In both creation cases, the confResponse, for a successful completion 1131 of a "create" operation, contains a response-code of "200" and MUST 1132 contain the XCON-URI of the newly created conference in the 1133 "confObjID" parameter, in order to allow the conferencing client to 1134 manipulate that conference through following CCMP requests. In 1135 addition, the "confInfo" parameter transporting the created 1136 conference document MAY be included, at the discretion of the 1137 conferencing system implementation, along with an optional version 1138 parameter initialized at "1", since at creation time the conference 1139 object is at its first version. 1141 In the case of a confRequest with a "retrieve" operation, the 1142 "confObjID" representing the XCON-URI of the target conference MUST 1143 be included and the "confInfo" parameter MUST NOT be included in the 1144 request. The conferencing server MUST ignore any "confInfo" 1145 parameter that is received in a confRequest/retrieve. If the 1146 confResponse for the "retrieve" operation contains a "response-code" 1147 of "200", the "confInfo" parameter MUST be included in the response. 1148 The "confInfo" parameter MUST contain the entire conference document 1149 describing the target conference object in its current state. The 1150 current state of the retrieved conference object MUST also be 1151 reported in the proper "version" response parameter. 1153 In case of a confRequest with an "update" operation, the "confInfo" 1154 and "confObjID" MUST be included in the request. The "confInfo" 1155 represents an object of type "conference-type" containing all the 1156 changes to be applied to the conference whose identifier is 1157 "confObjID". Note that, in such a case, though the confInfo 1158 parameter has indeed to follow the rules indicated in the XCON data 1159 model, it does not represent the entire updated version of the target 1160 conference, since it rather conveys just the modifications to apply 1161 to that conference. For example, in order to change the conference 1162 title, the confInfo parameter will be of the form: 1164 1165 1166 *** NEW CONFERENCE TITLE *** 1167 1168 1170 Figure 8: Updating a conference object: modifying the title of a 1171 conference 1173 Similarly, to remove the title of an existing conference, a 1174 confRequest/update carrying the following "confInfo" parameter would 1175 do the job.: 1177 1178 1179 1180 1181 1183 Figure 9: Updating a conference object: removing the title of a 1184 conference 1186 In the case of a confResponse/update with a response-code of "200", 1187 no additional information is required in the response message, which 1188 means the return of confInfo parameter is not mandatory. A following 1189 confRequest/retrieve transaction might provide the CCMP client with 1190 the current aspect of the conference upon the modification, or the 1191 Notification Protocol might address that task as well. A "200" 1192 response-code indicates that the referenced conference document has 1193 been changed accordingly to the request by the conferencing server. 1194 The "version" parameter MUST be enclosed in the confResponse/update 1195 message, in order to let the client understand what is the actual 1196 current conference-object version, upon the applied modifications. 1197 An "409" response-code indicates that the changes reflected in the 1198 request "confInfo" are not feasible. This could be due to policies, 1199 requestor roles, specific privileges, unacceptable values etc., with 1200 the reason specific to a conferencing system and its configuration. 1201 Together with the "409" response-code, the "version" parameter MUST 1202 be attached in the confResponse/update, by this way allowing the 1203 client to eventually retrieve the current version of the target 1204 conference if the one she attempted to modify was not the most up-to- 1205 date. 1207 In the case of a confRequest with a "delete" operation, the 1208 "confObjID" representing the XCON-URI of the target conference MUST 1209 be included while the "confInfo" MUST NOT be included in the request. 1210 The conferencing server MUST ignore any "confInfo" parameter that is 1211 received within such a request. The confResponse MUST contain the 1212 same "confObjID" that was included in the confRequest. If the 1213 confResponse/delete operation contains a "200" response-code, the 1214 conference indicated in the "confObjID" has been successfully 1215 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1216 parameter. The "version" parameter SHOULD NOT be returned in any 1217 confResponse/delete. If the conferencing server cannot delete the 1218 conference referenced by the "confObjID" received in the confRequest 1219 because it is the parent of another conference object that is in use, 1220 the conferencing server MUST return a response-code of "425". 1222 A confRequest with an "operation" of "retrieve", "update" or "delete" 1223 carrying a "confObjID" which is not associated with one of the 1224 conferences (active or registered) the system is holding will 1225 generate, on the server's side, a confResponse message containing a 1226 "404" error code. This holds also for the case in which the 1227 mentioned "confObjID" is related to an existing conference object 1228 stored at the server, but associated with a blueprint or with a 1229 sidebar rather than an actual conference. 1231 The schema for the confRequest/confResponse pair is shown in 1232 Figure 10. 1234 1236 1237 1238 1239 1240 1241 1242 1243 1244 1246 1248 1250 1251 1252 1254 1256 1257 1258 1260 1262 1263 1264 1265 1266 1267 1268 1269 1270 1272 1274 1276 1277 1278 1280 1282 1283 1284 1285 Figure 10: Structure of the confRequest and confResponse messages 1287 5.3.6. usersRequest and usersResponse 1289 Through a "usersRequest" message the CCMP client manipulates the XML 1290 element of the conference document associated with the 1291 conference identified by the "confObjID" parameter complusory 1292 included in the request. Inside the element, along with the 1293 list of elements associated with conference participants, 1294 there is information that the client may be interested in 1295 controlling, such the list of the users to which access to the 1296 conference is allowed/denied, conference participation policies, 1297 etc.; for this reason, a customized message has been designed to 1298 allow for the manipulation of this specific part of a conference 1299 document. 1301 A "usersInfo" parameter MAY be included in a usersRequest message 1302 depending upon the operation. If the "usersInfo" parameter is 1303 included in the usersRequest message, the parameter MUST be compliant 1304 with the field of the XCON data model. 1306 Two operations are allowed for a "usersRequest" message: 1307 1. "retrieve": In this case the request MUST NOT include a 1308 "usersInfo" parameter, while the successful response MUST contain 1309 the desired element in the "usersInfo" parameter. The 1310 conference server MUST ignore a "usersInfo" parameter if it is 1311 received in a request with a "retrieve" operation. 1312 2. update: In this case, the "usersInfo" parameter MUST contain the 1313 modifications to be applied to the referred element. If 1314 the "response-code" is "200", then the "usersInfo" parameter 1315 SHOULD NOT be returned. Any "usersInfo" parameter that is 1316 returned SHOULD be ignored. A "response-code" of "426" indicates 1317 that the conferencing client is not allowed to make the changes 1318 reflected in the "usersInfo" contained in the usersRequest 1319 message. This could be due to policies, roles, specific 1320 privileges, etc., with the reason specific to a conferencing 1321 system and its configuration. 1323 Operations of "create" and "delete" are not applicable to a 1324 usersRequest message and MUST NOT be considered by the server, which 1325 means that a "response-code" of "403" MUST be included in the 1326 usersResponse message. 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1339 1341 1343 1344 1345 1347 1349 1350 1351 1353 1355 1356 1357 1358 1359 1360 1361 1362 1363 1365 1367 1369 1370 1371 1373 1375 1376 1378 1380 Figure 11: Structure of the usersRequest and usersResponse messages 1382 5.3.7. userRequest and userResponse 1384 A "userRequest" message is used to manipulate elements inside 1385 a conference document associated with a conference identified by the 1386 "confObjID" parameter. Besides retrieving information about a 1387 specific conference user, the message is used to request that the 1388 conference server either create, modify, or delete information about 1389 a user. A "userRequest" message MUST include the "confObjID", the 1390 "operation" parameter, and MAY include a "userInfo" parameter 1391 containing the detailed user's information depending upon the 1392 operation and whether the "userInfo" has already been populated for a 1393 specific user. Note that a user may not necessarily be a 1394 conferencing control client (i.e., some participants in a conference 1395 are not "XCON aware"). 1397 An XCON-USERID SHOULD be assigned to each and every user subscribed 1398 to the system. In such a way, a user who is not a conference 1399 participant can make requests (provided she has successfully passed 1400 AAA checks), like creating a conference, retrieving conference 1401 information, etc.. 1403 Conference users can be created in a number of different ways. In 1404 each of these cases the operation MUST be set to "create" in the 1405 userRequest message. Each of the userResponse messages for these 1406 cases MUST include the "confObjID", "confUserID", "operation" and 1407 "response-code" parameters. In the case of a response code of "200", 1408 the userResponse message MAY include the "userInfo" parameter 1409 depending upon the manner in which the user was created: 1411 o Conferencing client with an XCON-USERID adds itself to the 1412 conference: In this case, the "userInfo" parameter MAY be included 1413 in the userRequest. The "userInfo" parameter MUST contain a 1414 element (compliant with the XCON data model) and the 1415 "entity" attribute MUST be set to a value which represents the 1416 XCON-USERID of the user initiating the request. No additional 1417 parameters beyond those previously described are required in the 1418 userResponse message, in the case of a "response-code" of "200". 1419 o Conferencing client acts on behalf of a third user whose XCON- 1420 USERID is known: in this case, the "userInfo" parameter MUST be 1421 included in the userRequest. The "userInfo" parameter MUST 1422 contain a element and the "entity" attribute value MUST be 1423 set to the XCON-USERID of the third user in question. No 1424 additional parameters beyond those previously described are 1425 required in the userResponse message, in the case of a "response- 1426 code" of "200". 1427 o A conferencing client who has no XCON-USERID and who wants to 1428 enter, via CCMP, a conference whose identifier is known. In such 1429 case, a side-effect of the request is that the user is provided 1430 with a new XCON-USERID (created by the server) carried inside the 1431 "confUserID" parameter of the response. This is the only case in 1432 which a CCMP request can be valid though carrying a void 1433 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1434 in the request, providing at least a contact URI of the joining 1435 client, in order to let the focus instigate the signaling phase 1436 needed to add her to the conference. The mandatory "entity" 1437 attribute of the "userInfo" parameter in the request is filled 1438 with a dummy value recognizable on the server side, so to conform 1439 to the rules contained in the XCON data model XML schema. The 1440 involved messages (userRequest and userResponse) in such case 1441 should look like the following: 1443 Request fields: 1445 confUserID=null; 1446 confObjID=confXYZ; 1447 operation=create; 1448 userInfo= 1450 1451 1452 ... 1454 Response fields (in case of success): 1456 confUserID=user345; 1457 confObjID=confXYZ; 1458 operation=create; 1459 response-code=200; 1460 userInfo=null; //or the entire userInfo object 1462 Figure 12: userRequest and userResponse in the absence of an xcon- 1463 userid 1465 o Conferencing client is unaware of the XCON-USERID of a third user: 1466 In this case, the XCON-USERID in the request "confUserID" is the 1467 sender's one and the "entity" attribute of the attached userInfo 1468 is filled with the pre-defined fake value 1469 "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the 1470 third user MUST be returned to the client issuing the request in 1471 the "entity" attribute of the response "userInfo" parameter, if 1472 the "response-code" is "200". [RP] This scenario is intended to 1473 support both the case where a brand new conferencing system user 1474 is added to a conference by a third party (i.e. a user who is not 1475 yet provided with an XCON-USERID) and the case where the CCMP 1476 client issuing the request does not know the to-be-added user's 1477 XCON-USERID (which means such an identifier could already exist on 1478 the server's side for that user). In this last case, the 1479 conferencing server is in charge of avoiding XCON-URI duplicates 1480 for the same conferencing client, looking at key fields in the 1481 request provided "userInfo" parameter, such as the signalling URI: 1482 if the joining user is a brand new one, then the generation of a 1483 new XCON identifier is needed; otherwise, if that user is an 1484 existing one, the server must recover the corresponding XCON 1485 identifier. 1487 In the case of a userRequest with a "retrieve" operation, the 1488 "confObjID" representing the XCON-URI of the target conference MUST 1489 be included. The "confUserID", containing the CCMP client's xcon- 1490 userid, MUST also be included in the userRequest message. If the 1491 client wants to retrieve information about her profile in the 1492 specified conference, no "userInfo" parameter is needed in the 1493 retrieve request. On the other hand, if the client wants to obtain 1494 someone else's info within the given conference, she MUST include in 1495 the userRequest/retrieve a "userInfo" parameter whose "entity" 1496 attribute conveys the desired user's xcon-userid. If the 1497 userResponse for the "retrieve" operation contains a "response-code" 1498 of "200", the "userInfo" parameter MUST be included in the response. 1500 In case of a userRequest with an "update" operation, the "confObjID", 1501 "confUserID" and "userInfo" MUST be included in the request. The 1502 "userInfo" is of type "user-type" and contains all the changes to be 1503 applied to a specific element in the conference object 1504 identified by the "confObjID" in the userRequest message. The user 1505 to be modified is identified through the "entity" attribute of the 1506 "userInfo" parameter included in the request. In the case of a 1507 userResponse with a "response-code" of "200", no additional 1508 information is required in the "userResponse" message. A "response- 1509 code" of "200" indicates that the referenced user element has been 1510 updated by the conference server. A "response-code" of "426" 1511 indicates that the conferencing client is not allowed to make the 1512 changes reflected in the "userInfo" in the initial request. This 1513 could be due to policies, roles, specific privileges, etc., with the 1514 reason specific to a conferencing system and its configuration. 1516 In the case of a userRequest with a "delete" operation, the 1517 "confObjID" representing the XCON-URI of the target conference MUST 1518 be included. The "confUserID", containing the CCMP client's xcon- 1519 userid, MUST be included in the userRequest message. If the client 1520 wants to exit the specified conference, no "userInfo" parameter is 1521 needed in the delete request. On the other hand, if the client wants 1522 to remove another participant from the given conference, she MUST 1523 include in the userRequest/delete a "userInfo" parameter whose 1524 "entity" attribute conveys the xcon-userid of that participant. The 1525 userResponse MUST contain the same "confObjID" that was included in 1526 the userRequest. The userResponse MUST contain a "response-code" of 1527 "200" if the target element has been successfully deleted. If 1528 the userResponse for the "delete" operation contains a "response- 1529 code" of "200", the userResponse MUST NOT contain the "userInfo" 1530 parameter. 1532 1534 1535 1536 1537 1538 1539 1540 1541 1542 1544 1546 1548 1549 1550 1552 1554 1555 1556 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1569 1571 1573 1574 1575 1577 1579 1580 1581 1583 Figure 13: Structure of the userRequest and userResponse messages 1585 5.3.8. sidebarsByValRequest and sidebarsByValResponse 1587 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1588 on the field of the conference object represented 1589 by the "confObjID". The "sidebarsByValRequest" message is of a 1590 "retrieve-only" type, so an "operation" parameter MUST NOT be 1591 included in a "sidebarsByValRequest" message. As with blueprints and 1592 conferences, also with sidebars, CCMP allows for the use of xpath 1593 filters whenever a selected subset of the sidebars available at the 1594 server's side has to be retrieved by the client. This applies both 1595 to sidebars by reference and to sidebars by value. A 1596 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1597 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1599 the client a "version" element related to the current version of the 1600 main conference object (i.e. the one whose identifier is contained in 1601 the "confObjId" field of the request) to which the sidebars in 1602 question are associated. The "sidebarsByValInfo" parameter contains 1603 the list of the conference objects associated with the sidebars by 1604 value derived from the main conference. The retrieved sidebars can 1605 then be updated or deleted using the "sidebarByValRequest" message, 1606 which is described in Section 5.3.9. 1608 1610 1611 1612 1613 1614 1615 1616 1617 1618 1620 1622 1625 1626 1627 1628 1630 1631 1632 1634 1636 1637 1638 1639 1640 1641 1642 1643 1644 1646 1648 1651 1652 1653 1655 1657 1658 1659 1661 Figure 14: Structure of the sidebarsByValRequest and 1662 sidebarsByValResponse messages 1664 5.3.9. sidebarByValRequest and sidebarByValResponse 1666 A sidebarByValRequest message MUST contain the "operation" parameter 1667 which discriminates among retrieval, creation, modification and 1668 deletion of a specific sidebar. The other required parameters depend 1669 upon the type of operation. 1671 In the case of a "create" operation, the "confObjID" parameter MUST 1672 be included in the sidebyValRequest message. In this case, the 1673 "confObjID" parameter contains the XCON-URI of the main conference in 1674 which the sidebar has to be created. If no "sidebarByValInfo" 1675 parameter is included, as envisaged in the XCON framework 1676 ([RFC5239]), the sidebar is created by cloning the main conference, 1677 following the implementation specific cloning rules. Otherwise, 1678 similarly to the case of direct creation, the sidebar conference 1679 object is built on the basis of the "sidebarByValInfo" parameter 1680 provided by the requestor. As a consequence of a sidebar-by-val 1681 creation, the conference server MUST update the main conference 1682 object reflected by the "confObjID" parameter in the 1683 sidebarbyValRequest/create message introducing the new sidebar object 1684 as a new new in the proper section . The 1685 newly created sidebar conference object MAY be included in the 1686 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1687 "response-code" is "200". The XCON-URI of the newly created sidebar 1688 MUST appear in the "confObjID" parameter of the response. The 1689 conference server can notify any conferencing clients that have 1690 subscribed to the conference event package, and are authorized to 1691 receive the notifications, of the addition of the sidebar to the 1692 conference. 1694 In the case of a "sidebarByVal" request with an operation of 1695 "retrieve", the URI for the conference object created for the sidebar 1696 (received in the response to a "create" operation or in a 1697 sidebarsByValResponse message) MUST be included in the "confObjID" 1698 parameter in the request. This "retrieve" operation is handled by 1699 the conference server in the same manner as a "retrieve" operation 1700 included in a confRequest message as detailed in Section 5.3.5. 1702 In the case of a "sidebarByVal" request with an operation of 1703 "update", the "sidebarByValInfo" MUST also be included in the 1704 request. The "confObjID" parameter contained in the request message 1705 identifies the specific sidebar instance to be updated. An "update" 1706 operation on the "sidebarByValInfo" is handled by the conference 1707 server in the same manner as an "update" operation on the confInfo 1708 included in a confRequest message as detailed in Section 5.3.5. A 1709 "sidebarByValResponse" message MUST carry back to the client a 1710 "version" element related to the current version of the sidebar whose 1711 identifier is contained in the "confObjId" field of the request. 1713 If an "operation" of "delete" is included in the sidebarByVal 1714 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1715 request. Any "sidebarByValInfo" included in the request MUST be 1716 ignored by the conference server. The URI for the conference object 1717 associated with the sidebar MUST be included in the "confObjID" 1718 parameter in the request. If the specific conferencing user as 1719 reflected by the "confUserID" in the request is authorized to delete 1720 the conference, the conference server deletes the conference object 1721 reflected by the "confObjID" parameter and updates the data in the 1722 conference object from which the sidebar was cloned. The conference 1723 server can notify any conferencing clients that have subscribed to 1724 the conference event package, and are authorized to receive the 1725 notifications, of the deletion of the sidebar to the conference. 1727 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1728 or "delete" carries a "confObjID" which is not associated with any 1729 existing sidebar-by-val, a confResponse message containing a "404" 1730 error code will be generated on the server's side. This holds also 1731 for the case in which the mentioned "confObjID" is related to an 1732 existing conference object stored at the server, but associated with 1733 a blueprint or with an actual conference or with a sidebar-by-ref 1734 rather than a sidebar-by-val. 1736 1738 1739 1740 1741 1742 1743 1745 1746 1747 1749 1751 1754 1755 1756 1758 1760 1761 1762 1764 1766 1767 1768 1769 1770 1771 1772 1773 1774 1776 1778 1781 1782 1783 1785 1787 1788 1789 1790 Figure 15: Structure of the sidebarByValRequest and 1791 sidebarByValResponse messages 1793 5.3.10. sidebarsByRefRequest and sidebarsByRefResponse 1795 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1796 invoked to retrieve the element of the conference 1797 object identified by the "confObjID" parameter. The 1798 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1799 "operation" parameter MUST NOT be included in a 1800 "sidebarsByRefRequest" message. In the case of a "response-code" of 1801 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1803 response. The element represents the set of URIs 1804 of the sidebars associated with the main conference, whose 1805 description (in the form of a standard XCON conference document) is 1806 external to the main conference itself. Through the retrieved URIs, 1807 it is then possible to access single sidebars using the 1808 "sidebarByRef" request message, described in Section 5.3.11. A 1809 "sidebarsByRefResponse" message MUST carry back to the client a 1810 "version" element related to the current version of the main 1811 conference object (i.e. the one whose identifier is contained in the 1812 "confObjId" field of the request) to which the sidebars in question 1813 are associated. 1815 1817 1818 1819 1820 1821 1822 1823 1824 1825 1827 1829 1832 1833 1834 1835 1837 1838 1839 1841 1843 1844 1845 1846 1847 1848 1849 1850 1851 1853 1855 1858 1859 1860 1862 1864 1865 1866 1868 Figure 16: Structure of the sidebarsByRefRequest and 1869 sidebarsByRefResponse messages 1871 5.3.11. sidebarByRefRequest and sidebarByRefResponse 1873 A sidebarByRefRequest message MUST contain the "operation" parameter 1874 which discriminates among retrieval, creation, modification and 1875 deletion of a specific sidebar. The other required parameters depend 1876 upon the type of operation. 1878 In the case of a "create" operation, the "confObjID" parameter MUST 1879 be included in the sidebyRefRequest message. In this case, the 1880 "confObjID" parameter contains the XCON-URI of the main conference in 1881 which the sidebar has to be created. If no "sidebarByRefInfo" 1882 parameter is included, as envisaged in the XCON framework 1883 ([RFC5239]), the sidebar is created by cloning the main conference, 1884 following the implementation specific cloning rules. Otherwise, 1885 similarly to the case of direct creation, the sidebar conference 1886 object is built on the basis of the "sidebarByRefInfo" parameter 1887 provided by the requestor. If the creation of the sidebar is 1888 successful, the conference server MUST update the "sidebars-by-ref" 1889 element in the conference object from which the sidebar was created 1890 (i.e., as identified by the "confObjID" in the original sidebarByRef 1891 request), with the URI of the newly created sidebar. The newly 1892 created conference object MAY be included in the response in the 1893 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1894 URI for the conference object associated with the newly created 1895 sidebar object MUST appear in the "confObjID" parameter of the 1896 response. The conference server can notify any conferencing clients 1897 that have subscribed to the conference event package, and are 1898 authorized to receive the notifications, of the addition of the 1899 sidebar to the conference. 1901 In the case of a "sidebarByRef" request with an operation of 1902 "retrieve", the URI for the conference object created for the sidebar 1903 MUST be included in the "confObjID" parameter in the request. A 1904 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1905 conference server in the same manner as a "retrieve" operation on the 1906 confInfo included in a confRequest message as detailed in 1907 Section 5.3.5. 1909 In the case of a "sidebarByRef" request with an operation of 1910 "update", the URI for the conference object created for the sidebar 1911 MUST be included in the "confObjID" parameter in the request. The 1912 "sidebarByRefInfo" MUST also be included in the request in the case 1913 of an "operation" of "update". An "update" operation on the 1914 "sidebarByRefInfo" is handled by the conference server in the same 1915 manner as an "update" operation on the confInfo included in a 1916 confRequest message as detailed in Section 5.3.5. A 1917 "sidebarByRefResponse" message MUST carry back to the client a 1918 "version" element related to the current version of the sidebar whose 1919 identifier is contained in the "confObjId" field of the request. 1921 If an "operation" of "delete" is included in the sidebarByRef 1922 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1923 request. Any "sidebarByRefInfo" included in the request MUST be 1924 ignored by the conference server. The URI for the conference object 1925 for the sidebar MUST be included in the "confObjID" parameter in the 1926 request. If the specific conferencing user as reflected by the 1927 "confUserID" in the request is authorized to delete the conference, 1928 the conference server SHOULD delete the conference object reflected 1929 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1930 element in the conference object from which the sidebar was 1931 originally cloned. The conference server can notify any conferencing 1932 clients that have subscribed to the conference event package, and are 1933 authorized to receive the notifications, of the deletion of the 1934 sidebar. 1936 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1937 or "delete" carries a "confObjID" which is not associated with any 1938 existing sidebar-by-ref, a confResponse message containing a "404" 1939 error code will be generated on the server's side. This holds also 1940 for the case in which the mentioned "confObjID" is related to an 1941 existing conference object stored at the server, but associated with 1942 a blueprint or with an actual conference or with a sidebar-by-val 1943 rather than a sidebar-by-ref. 1945 1947 1948 1949 1950 1951 1952 1953 1954 1955 1957 1959 1962 1963 1964 1966 1968 1969 1970 1972 1974 1975 1976 1977 1978 1979 1980 1981 1982 1984 1986 1989 1990 1991 1993 1995 1996 1997 1999 Figure 17: Structure of the sidebarByRefRequest and 2000 sidebarByRefResponse messages 2002 5.4. CCMP Response Codes 2004 All CCMP response messages MUST include a ""response-code"". The 2005 following summarizes the CCMP response codes: 2007 200 Success: Successful completion of the requested operation. 2008 400 Bad Request: Syntactically malformed request. 2009 401 Unauthorized: User not allowed to perform the required 2010 operation. 2011 403 Forbidden: Operation not allowed (e.g., cancellation of a 2012 blueprint). 2013 404 Object Not Found: Target conference object missing at the server 2014 (it refers to the "confObjID" parameter in the generic request 2015 message) 2016 409 Conflict: A generic error associated with all those situations 2017 in which a requested client operation cannot be successfully 2018 completed by the server. An example of such situation is when the 2019 modification of an object cannot be applied due to conflicts 2020 arising at the server's side, e.g. because the client version of 2021 the object is an obsolete one and the requested modifications 2022 collide with the up-to-date state of the object stored at the 2023 server. Such code would also be used if a client attempts to 2024 create an object (conference or user) with an entity that already 2025 exists. 2026 420 User Not Found: Target user missing at the server (it is related 2027 to the XCON-USERID in the "entity" attribute of the "userInfo" 2028 parameter when it is included in userRequests) 2029 421 Invalid confUserID: User missing at the server (this code is 2030 returned in the case of requests in which the "confUserID" of the 2031 sender is invalid). 2032 422 Invalid Conference Password: Target conference object's password 2033 contained in the request is wrong. 2034 423 Conference Password Required: "conference-password" missing in a 2035 request to access a password-protected conference object. 2036 424 Authentication Required: User's authentication information is 2037 missing or invalid. 2038 425 Forbidden Delete Parent: Cancel operation failed since the 2039 target object is a parent of child objects which depend on it, or 2040 because it effects, based on the "parent-enforceable" mechanism, 2041 the corresponding element in a child object. 2042 426 Forbidden Change Protected: Update refused by the server because 2043 the target element cannot be modified due to its implicit 2044 dependence on the value of a parent object ("parent-enforceable" 2045 mechanism). 2046 500 Server Internal Error: The server cannot complete the required 2047 service due to a system internal error. 2048 501 Not Implemented: Operation envisaged in the protocol, but not 2049 implemented in the contacted server. 2050 510 Request Timeout: The time required to serve the request has 2051 exceeded the envisaged service threshold. 2052 511 Resources Not Available: This code is used when the CCMP server 2053 cannot execute a command because of resource issues, e.g. it 2054 cannot create a sub conference because the system has reached its 2055 limits on the number of sub conferences, or if a request for 2056 adding a new user fails because the max number of users has been 2057 reached for the conference or the max number of users has been 2058 reached for the conferencing system. 2060 The handling of a "response-code" of "404", "409", "420", "421", 2061 "425" and "426" are only applicable to specific operations for 2062 specialized message responses and the details are provided in 2063 Section 5.3. The following table summarizes these response codes and 2064 the specialized message and operation to which they are applicable: 2066 +---------------+------------+------------+------------+------------+ 2067 | Response code | Create | Retrieve | Update | Delete | 2068 +---------------+------------+------------+------------+------------+ 2069 | 404 | userReques | All | All update | All delete | 2070 | | t, | retrieve | requests | requests | 2071 | | sidebarBy | requests, | | | 2072 | | ValRequest | EXCEPT: | | | 2073 | | sidebars | blueprints | | | 2074 | | ByRefReque | Request, | | | 2075 | | st | confsRequ | | | 2076 | | | est | | | 2077 | ------------- | ---------- | ---------- | ---------- | ---------- | 2078 | 409 | N/A | N/A | All update | N/A | 2079 | | | | requests | | 2080 | ------------- | ---------- | ---------- | ---------- | ---------- | 2081 | 420 | userReques | userReques | userReques | userReques | 2082 | | t(3rd part | t | t | t | 2083 | | yinvite | | | | 2084 | | with thir | | | | 2085 | | duser | | | | 2086 | | entity) | | | | 2087 | | (*) | | | | 2088 | ------------- | ---------- | ---------- | ---------- | ---------- | 2089 | 421 | All create | All | All update | All delete | 2090 | | requests, | retrieve | requests | requests | 2091 | | EXCEPT: | requests | | | 2092 | | userReques | | | | 2093 | | twith no | | | | 2094 | | confUserI | | | | 2095 | | D(**) | | | | 2096 | ------------- | ---------- | ---------- | ---------- | ---------- | 2097 | 425 | N/A | N/A | N/A | All delete | 2098 | | | | | request | 2099 | ------------- | ---------- | ---------- | ---------- | ---------- | 2100 | 426 | N/A | N/A | All update | N/A | 2101 | | | | requests | | 2102 +---------------+------------+------------+------------+------------+ 2104 Table 2: Response codes and associated operations 2106 (*) "420" in answer to a "userRequest/create" operation: in the case 2107 of a third-party invite, this code can be returned if the 2108 "confUserID" (contained in the "entity" attribute of the "userInfo" 2109 parameter) of the user to be added is unknown. In the case above, if 2110 instead it is the "confUserID" of the sender of the request that is 2111 invalid, a "421" error code is returned to the client. 2113 (**) "421" is not sent in answers to "userRequest/create" messages 2114 having a "null" confUserID, since this case is associated with a user 2115 who is unaware of his own XCON-USERID, but wants to enter a known 2116 conference. 2118 In the case of a response code of "510", a conferencing client MAY 2119 re-attempt the request within a period of time that would be specific 2120 to a conference control client or conference control server. 2122 A response code of "400" indicates that the conference control client 2123 sent a malformed request, which is indicative of an error in the 2124 conference control client or in the conference control server. The 2125 handling is specific to the conference control client implementation 2126 (e.g., generate a log, display an error message, etc.). It is NOT 2127 RECOMMENDED that the client re-attempt the request in this case. 2129 Response codes such as "401" and "403" indicate the client does not 2130 have the appropriate permissions, or there is an error in the 2131 permissions: re-attempting the request would likely not succeed and 2132 thus it is NOT RECOMMENDED. 2134 Any unexpected or unknown "response-code" SHOULD be treated by the 2135 client in the same manner as a "500" "response-code", the handling of 2136 which is specific to the conference control client implementation. 2138 6. A complete example of the CCMP in action 2140 In this section a typical, not normative, scenario in which the CCMP 2141 comes into play is described, by showing the actual composition of 2142 the various CCMP messages. In the call flows of the example, the 2143 Conference Control Client is a CCMP-enabled client, whereas the 2144 Conference Control Server is a CCMP-enabled server. The "confUserID" 2145 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2146 in all requests. The sequence of operations is as follows: 2148 1. Alice retrieves from the server the list of available blueprints 2149 (Section 6.1); 2150 2. Alice asks for detailed information about a specific blueprint 2151 (Section 6.2); 2152 3. Alice decides to create a new conference by cloning the retrieved 2153 blueprint (Section 6.3); 2154 4. Alice modifies information (e.g. XCON-URI, name, description) 2155 associated with the newly created blueprint (Section 6.4); 2156 5. Alice specifies a list of users to be contacted when the 2157 conference is activated (Section 6.5); 2158 6. Alice joins the conference (Section 6.6); 2159 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2160 "xcon-userid:Ciccio@example.com") join the conference 2161 (Section 6.7). 2163 Note, the examples do not include any details beyond the basic 2164 operation. 2166 In the following sections we deal with each of the above mentioned 2167 actions separately. 2169 6.1. Alice retrieves the available blueprints 2171 This section illustrates the transaction associated with retrieval of 2172 the blueprints, together with a dump of the two messages exchanged 2173 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2174 the figure, the "blueprintsResponse" message contains, in the 2175 "blueprintsInfo" parameter, information about the available 2176 blueprints, in the form of the standard XCON-URI of the blueprint, 2177 plus additional (and optional) information, like its display-text and 2178 purpose. 2180 Alice retrieves from the server the list of available blueprints: 2182 CCMP Client CCMP Server 2183 | | 2184 | CCMP blueprintsRequest message | 2185 | - confUserID: Alice | 2186 | - confObjID: (null) | 2187 |------------------------------------------------------>| 2188 | | 2189 | CMP blueprintsResponse message | 2190 | - confUserID: Alice | 2191 | - confObjID: (null) | 2192 | - response-code: 200 | 2193 | - blueprintsInfo: bp123,bp124,.. | 2194 |<------------------------------------------------------| 2195 | | 2196 . . 2197 . . 2199 1. blueprintsRequest message: 2201 2202 2205 2207 xcon-userid:Alice@example.com 2208 2209 2211 2. blueprintsResponse message form the server: 2213 2214 2218 2221 xcon-userid:Alice@example.com 2222 200 2223 2224 2225 2226 xcon:AudioRoom@example.com 2227 AudioRoom 2228 Simple Room: 2229 conference room with public access, 2230 where only audio is available, more users 2231 can talk at the same time 2232 and the requests for the AudioFloor 2233 are automatically accepted. 2234 2235 2236 2237 xcon:VideoRoom@example.com 2238 VideoRoom 2239 Video Room: 2240 conference room with public access, 2241 where both audio and video are available, 2242 8 users can talk and be seen at the same time, 2243 and the floor requests are automatically accepted. 2244 2245 2246 2247 xcon:AudioConference1@example.com 2248 AudioConference1 2249 Public Audio Conference: 2250 conference with public access, 2251 where only audio is available, 2252 only one user can talk at the same time, 2253 and the requests for the AudioFloor MUST 2254 be accepted by a Chair. 2255 2256 2257 2258 xcon:VideoConference1@example.com 2259 VideoConference1 2260 Public Video Conference: conference 2261 where both audio and video are available, 2262 only one user can talk 2263 2264 2265 2266 xcon:AudioConference2@example.com 2267 AudioConference2 2268 Basic Audio Conference: 2269 conference with private access, 2270 where only audio is available, 2271 only one user can talk at the same time, 2272 and the requests for the AudioFloor MUST 2273 be accepted by a Chair. 2274 2275 2276 2277 2278 2279 2281 Figure 18: Getting blueprints from the server 2283 6.2. Alice gets detailed information about a specific blueprint 2285 This section illustrates the second transaction in the overall flow. 2286 In this case, Alice, who now knows the XCON-URIs of the blueprints 2287 available at the server, makes a drill-down query, in the form of a 2288 CCMP "blueprintRequest" message, to get detailed information about 2289 one of them (the one called with XCON-URI 2290 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2291 Notice that the response contains, in the "blueprintInfo" parameter, 2292 a document compliant with the standard XCON data model. 2294 Alice retrieves detailed information about a specified blueprint: 2296 CCMP Client CCMP Server 2297 | | 2298 | CCMP blueprintRequest message | 2299 | - confUserID: Alice | 2300 | - confObjID: bp123 | 2301 | - operation: retrieve | 2302 | - blueprintInfo: (null) | 2303 |------------------------------------------------------>| 2304 | | 2305 | CCMP blueprintResponse message | 2306 | - confUserID: Alice | 2307 | - confObjID: bp123 | 2308 | - operation: retrieve | 2309 | - response-code: 200 | 2310 | - blueprintInfo: bp123Info | 2311 |<------------------------------------------------------| 2312 | | 2313 . . 2314 . . 2316 1. blueprintRequest message: 2318 2319 2323 2325 xcon-userid:Alice@example.com 2326 xcon:AudioRoom@example.com 2327 retrieve 2328 2329 2330 2332 2. blueprintResponse message form the server: 2334 2335 2339 2341 xcon-userid:Alice@example.com 2342 xcon:AudioRoom@example.com 2343 retrieve 2344 200 2345 2346 2347 2348 AudioRoom 2349 2 2350 2351 2352 audio 2353 2354 2355 2356 2357 allow 2358 2359 2360 confirm 2361 2362 2363 2364 2365 2366 2367 2368 2369 2371 Figure 19: Getting info about a specific blueprint 2373 6.3. Alice creates a new conference through a cloning operation 2375 This section illustrates the third transaction in the overall flow. 2376 Alice decides to create a new conference by cloning the blueprint 2377 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2378 retrieved detailed information through the "blueprintRequest" 2379 message. This is achieved by sending a "confRequest/create" message 2380 having the blueprint's URI in the "confObjID" parameter. The picture 2381 shows such transaction. Notice that the response contains, in the 2382 "confInfo" parameter, the document associated with the newly created 2383 conference, which is compliant with the standard XCON data model. 2384 The "confObjID" in the response is set to the XCON-URI of the new 2385 conference (in this case, "xcon:8977794@example.com"). We also 2386 notice that this value is equal to the value of the "entity" 2387 attribute of the element of the document 2388 representing the newly created conference object. 2390 Alice creates a new conference by cloning the 2391 "xcon:AudioRoom@example.com" blueprint: 2393 CCMP Client CCMP Server 2394 | | 2395 | CCMP confRequest message | 2396 | - confUserID: Alice | 2397 | - confObjID: AudioRoom | 2398 | - operation: create | 2399 | - confInfo: (null) | 2400 |------------------------------------------------------>| 2401 | | 2402 | CCMP confResponse message | 2403 | - confUserID: Alice | 2404 | - confObjID: newConfId | 2405 | - operation: create | 2406 | - response-code: 200 | 2407 | - version: 1 | 2408 | - confInfo: newConfInfo | 2409 |<------------------------------------------------------| 2410 | | 2411 . . 2412 . . 2414 1. confRequest message: 2416 2417 2421 2424 xcon-userid:Alice@example.com 2425 xcon:AudioRoom@example.com 2426 create 2427 2428 2429 2431 2. confResponse message from the server: 2433 2434 2438 2441 xcon-userid:Alice@example.com 2442 xcon:8977794@example.com 2443 create 2444 200 2445 1 2446 2447 2448 2449 2450 New conference by Alice cloned from AudioRoom 2451 2452 2453 2454 2455 xcon:8977794@example.com 2456 2457 2458 conference xcon-uri 2459 2460 2461 8601 2462 2463 2464 2465 10 2466 2467 2468 audio 2469 2470 2471 2472 2473 allow 2474 2475 2476 2477 confirm 2478 2479 2480 2481 2483 2484 2485 2486 2488 Figure 20: Creating a new conference by cloning a blueprint 2490 6.4. Alice updates conference information 2492 This section illustrates the fourth transaction in the overall flow. 2493 Alice decides to modify some of the details associated with the 2494 conference she just created. More precisely, she changes the 2495 element under the element of 2496 the document representing the conference. This is achieved through a 2497 "confRequest/update" message carrying the fragment of the conference 2498 document to which the required changes have to be applied. As shown 2499 in the picture, the response contains a code of "200", which 2500 acknowledges the modifications requested by the client, while also 2501 updating the conference version number from 1 to 2, as reflected in 2502 the "version" parameter. 2504 Alice updates information about the conference she just created: 2506 CCMP Client CCMP Server 2507 | | 2508 | CCMP confRequest message | 2509 | - confUserID: Alice | 2510 | - confObjID: 8977794 | 2511 | - operation: update | 2512 | - confInfo: confUpdates | 2513 |------------------------------------------------------>| 2514 | | 2515 | CCMP confResponse message | 2516 | - confUserID: Alice | 2517 | - confObjID: 8977794 | 2518 | - operation: update | 2519 | - response-code: 200 | 2520 | - version: 2 | 2521 | - confInfo: (null) | 2522 |<------------------------------------------------------| 2523 | | 2524 . . 2526 . . 2528 1. confRequest message: 2530 2531 2535 2538 xcon-userid:Alice@example.com 2539 xcon:8977794@example.com 2540 update 2541 2542 2543 2544 2545 Alice's conference 2546 2547 2548 2549 2550 2551 2553 2. confResponse message form the server: 2555 2556 2560 2562 xcon-userid:Alice@example.com 2563 xcon:8977794@example.com 2564 update 2565 200 2566 2 2567 2568 2569 2570 Figure 21: Updating conference information 2572 6.5. Alice inserts a list of users in the conference object 2574 This section illustrates the fifth transaction in the overall flow. 2575 Alice modifies the under the element in 2576 the document associated with the conference she created. To the 2577 purpose, she exploits the "usersRequest" message provided by the 2578 CCMP. The picture below shows the transaction. 2580 Alice updates information about the list of users to whom access to 2581 the conference is permitted: 2583 CCMP Client CCMP Server 2584 | | 2585 | CCMP usersRequest message | 2586 | - confUserID: Alice | 2587 | - confObjID: 8977794 | 2588 | - operation: update | 2589 | - usersInfo: usersUpdates | 2590 |------------------------------------------------------>| 2591 | | 2592 | CCMP usersResponse message | 2593 | - confUserID: Alice | 2594 | - confObjID: 8977794 | 2595 | - operation: update | 2596 | - response-code: 200 | 2597 | - version: 3 | 2598 | - usersInfo: (null) | 2599 |<------------------------------------------------------| 2600 | | 2601 . . 2602 . . 2604 1. usersRequest message: 2606 2607 2611 2613 xcon-userid:Alice@example.com 2614 xcon:8977794@example.com 2615 update 2616 2617 2618 2619 2621 2623 2625 2626 2627 2628 2629 2631 2. usersResponse message form the server: 2633 2634 2638 2640 xcon-userid:Alice@example.com 2641 xcon:8977794@example.com 2642 update 2643 200 2644 3 2645 2646 2647 2649 Figure 22: Updating the list of allowed users for the conference 2650 'xcon:8977794@example.com' 2652 6.6. Alice joins the conference 2654 This section illustrates the sixth transaction in the overall flow. 2655 Alice uses the CCMP to add herself to the newly created conference. 2656 This is achieved through a "userRequest/create" message containing, 2657 in the "userInfo" parameter, a element compliant with the XCON 2658 data model representation. Notice that such element includes 2659 information about the user's Address of Records, as well as her 2660 current end-point. The picture below shows the transaction. Notice 2661 how the "confUserID" parameter is equal to the "entity" attribute of 2662 the element, which indicates that the request issued by 2663 the client is a first-party one. 2665 Alice joins the conference by issuing a "userRequest/create" message 2666 with her own id to the server: 2668 CCMP Client CCMP Server 2669 | | 2670 | CCMP userRequest message | 2671 | - confUserID: Alice | 2672 | - confObjID: 8977794 | 2673 | - operation: create | 2674 | - userInfo: AliceUserInfo | 2675 |------------------------------------------------------>| 2676 | | 2677 | CCMP userResponse message | 2678 | - confUserID: Alice | 2679 | - confObjID: 8977794 | 2680 | - operation: create | 2681 | - response-code: 200 | 2682 | - version: 4 | 2683 | - userInfo: (null) | 2684 |<------------------------------------------------------| 2685 | | 2686 . . 2687 . . 2689 1. userRequest message: 2691 2692 2696 2698 xcon-userid:Alice@example.com 2699 xcon:8977794@example.com 2700 create 2701 2702 2703 2704 2705 2706 mailto:Alice83@example.com 2708 2709 email 2710 2711 2712 2713 2714 2715 2716 2718 2. userResponse message form the server: 2720 2721 2725 2727 xcon-userid:Alice@example.com 2728 xcon:8977794@example.com 2729 create 2730 200 2731 4 2732 2733 2734 2736 Figure 23: Alice joins the conference through the CCMP 2738 6.7. Alice adds a new user to the conference 2740 This section illustrates the seventh and last transaction in the 2741 overall flow. Alice uses the CCMP to add a new conferencing system 2742 user, Ciccio, to the conference. This "third-party" request is 2743 realized through a "userRequest/create" message containing, in the 2744 "userInfo" parameter, a element compliant with the XCON data 2745 model representation. Notice that such element includes information 2746 about Ciccio's Address of Records, as well as his current end-point, 2747 but has a fake "entity" attribute, since it is unknown to Alice, in 2748 this example. Thus, the server is in charge of generating a new 2749 XCON-USERID for the user Alice indicates, and returning it in the 2750 "entity" attribute of the "userInfo" parameter carried in the 2751 response, as well as adding the user to the conference. The picture 2752 below shows the transaction. 2754 Alice adds user "Ciccio" to the conference by issuing a third-party 2755 "userRequest/create" message to the server: 2757 CCMP Client CCMP Server 2758 | | 2759 | CCMP userRequest message | 2760 | - confUserID: Alice | 2761 | - confObjID: 8977794 | 2762 | - operation: create | 2763 | - userInfo: CiccioUserInfo(with dummy "entity") | 2764 |------------------------------------------------------>| 2765 | | 2766 | CCMP userResponse message | 2767 | - confUserID: Alice | 2768 | - confObjID: 8977794 | 2769 | - operation: create | 2770 | - response-code: 200 | 2771 | - version: 5 | 2772 | - userInfo: CiccioUserInfo | 2773 | (with actual "entity") | 2774 |<------------------------------------------------------| 2775 | | 2776 . . 2777 . . 2779 1. "third party" userRequest message from Alice: 2781 2782 2786 2788 xcon-userid:Alice@example.com 2789 xcon:8977794@example.com 2790 create 2791 2792 2793 2794 2795 2796 mailto:Ciccio@example.com 2797 2798 email 2799 2801 2802 2803 2804 2805 2806 2808 2. "third party" userResponse message form the server: 2810 2811 2815 2817 xcon-userid:Alice@example.com 2818 xcon:8977794@example.com 2819 create 2820 200 2821 5 2822 2823 2824 2825 2826 2827 mailto:Ciccio@example.com 2828 2829 email 2830 2831 2832 2833 2834 2835 2836 2838 Figure 24: Alice adds a new user to the conference through the CCMP 2840 7. Locating a Conference Control Server 2842 If a conference control client is not pre-configured to use a 2843 specific conference control server for the requests, the client MUST 2844 first discover the conference control server before it can send any 2845 requests. The result of the discovery process, is the address of the 2846 server supporting conferencing. In this document, the result is an 2847 http: or https: URI, which identifies a conference server. 2849 This document proposes the use of DNS to locate the conferencing 2850 server. U-NAPTR resolution for conferencing takes a domain name as 2851 input and produces a URI that identifies the conferencing server. 2852 This process also requires an Application Service tag and an 2853 Application Protocol tag, which differentiate conferencing-related 2854 NAPTR records from other records for that domain. 2856 Section 12.4.1 defines an Application Service tag of "XCON", which is 2857 used to identify the centralized conferencing (XCON) server for a 2858 particular domain. The Application Protocol tag "CCMP", defined in 2859 Section 12.4.2, is used to identify an XCON server that understands 2860 the CCMP protocol. 2862 The NAPTR records in the following example Figure 25 demonstrate the 2863 use of the Application Service and Protocol tags. Iterative NAPTR 2864 resolution is used to delegate responsibility for the conferencing 2865 service from "zonea.example.com." and "zoneb.example.com." to 2866 "outsource.example.com.". 2868 zonea.example.com. 2869 ;; order pref flags 2870 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2871 "" ; regex 2872 outsource.example.com. ; replacement 2873 ) 2874 zoneb.example.com. 2875 ;; order pref flags 2876 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2877 "" ; regex 2878 outsource.example.com. ; replacement 2879 ) 2880 outsource.example.com. 2881 ;; order pref flags 2882 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 2883 "!*.!https://confs.example.com/!" ; regex 2884 . ; replacement 2885 ) 2887 Figure 25: Sample XCON:CCMP Service NAPTR Records 2889 Details for the "XCON" Application Service tag and the "CCMP" 2890 Application Protocol tag are included in Section 12.4. 2892 8. Managing Notifications 2894 As per [RFC5239], the CCMP is one of the following four protocols 2895 which have been formally identified within the XCON framework: 2896 Conference Control Protocol: between Conference and Media Control 2897 Client and Conference Server. Such protocol is the subject of the 2898 present document. 2899 Binary floor Control Protocol: between the Floor Control Client and 2900 the Floor Control Server. Such protocol is the BFCP, specified in 2901 [RFC4582]. 2902 Call Signaling Protocol: between the Call Signaling Client and the 2903 Focus. Such protocol can be either SIP or any other call 2904 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 2905 a conferencing session. 2906 Notification Protocol: between the Notification Client and the XCON 2907 Notification Service. Such protocol has not been identified as 2908 yet. 2910 The CCMP protocol specified in this document is a pro-active one and 2911 is used by a conferencing client to send requests to a conferencing 2912 server in order to retrieve information about the conference objects 2913 it stores and potentially manipulate them. Though, it stands clear 2914 that a complete conferencing solution cannot refrain from providing 2915 clients with a means for receiving asynchronous updates about the 2916 status of the objects available at the server. The notification 2917 protocol to be adopted in XCON, while conceptually independent of all 2918 the mentioned companion protocols, can nonetheless be chosen in a way 2919 that is consistent with the overall protocol architecture 2920 characterizing a specific deployment, as it is discussed in the 2921 following. 2923 When the conference control client uses SIP [RFC3261] as the 2924 signaling protocol to participate in the conference, SIP event 2925 notification can be used. In such a case, the conference control 2926 client MUST implement the Conference event package for XCON 2927 [I-D.ietf-xcon-event-package]. This is the default mechanism for 2928 conferencing clients as is SIP for signaling per the XCON Framework 2929 [RFC5239]. 2931 In the case where the interface to the conference server is entirely 2932 web based, there is a common mechanism for web-based systems that 2933 could be used - a "call back". With this mechanism, the conference 2934 client provides the conference server with an HTTP URL which is 2935 invoked when a change occurs. This is a common implementation 2936 mechanism for e-commerce. This works well in the scenarios whereby 2937 the conferencing client is a web server that provides the graphical 2938 HTML user interface and uses CCMP as the backend interface to the 2939 conference server. And, this model can co-exist with the SIP event 2940 notification model. PC-based clients behind NATs could provide a SIP 2941 event URI, whereas web-based clients using CCMP in the backend would 2942 probably find the HTTP call back approach much easier. The details 2943 of this approach are out of scope for the CCMP per se, thus the 2944 expectation is that a future specification will document this 2945 solution. 2947 9. HTTP Transport 2949 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 2950 [RFC2818] as transport mechanisms for the CCMP protocol, which a 2951 conforming conference Server and Conferencing client MUST support. 2953 Although CCMP uses HTTP as a transport, it uses a strict subset of 2954 HTTP features, and due to the restrictions of some features, a 2955 conferencing server may not be a fully compliant HTTP server. It is 2956 intended that a conference server can easily be built using an HTTP 2957 server with extensibility mechanisms, and that a conferencing client 2958 can trivially use existing HTTP libraries. This subset of 2959 requirements helps implementors avoid ambiguity with the many options 2960 the full HTTP protocol offers. 2962 A conferencing client that conforms to this specification is not 2963 required to support HTTP authentication [RFC2617] or cookies 2964 [RFC2965]. These mechanism are unnecessary because CCMP requests 2965 carry their own authentication information (in the "subject" field; 2966 see Section 5.1). 2968 A CCMP request is carried in the body of an HTTP POST request. The 2969 conferencing client MUST include a Host header in the request. 2971 The MIME type of CCMP request and response bodies is "application/ 2972 ccmp+xml". The conference server and conferencing client MUST 2973 provide this value in the HTTP Content-Type and Accept header fields. 2974 If the conference server does not receive the appropriate Content- 2975 Type and Accept header fields, the conference server SHOULD fail the 2976 request, returning a 406 (not acceptable) response. CCMP responses 2977 SHOULD include a Content-Length header. 2979 Conferencing clients MUST NOT use the "Expect" header or the "Range" 2980 header in CCMP requests. The conference server MAY return 501 (not 2981 implemented) errors if either of these HTTP features are used. In 2982 the case that the conference server receives a request from the 2983 conferencing client containing a If-* (conditional) header, the 2984 conference server SHOULD return a 412 (precondition failed) response. 2986 The POST method is the only method REQUIRED for CCMP. If a 2987 conference server chooses to support GET or HEAD, it SHOULD consider 2988 the kind of application doing the GET. Since a conferencing client 2989 only uses a POST method, the GET or HEAD MUST be either an escaped 2990 URL (e.g., somebody found a URL in protocol traces or log files and 2991 fed it into their browser) or somebody doing testing/ debugging. The 2992 conference server could provide information in the CCMP response 2993 indicating that the URL corresponds to a conference server and only 2994 responds to CCMP POST requests or the conference server could instead 2995 try to avoid any leak of information by returning a very generic HTTP 2996 error message such as 405 (method not allowed). 2998 The conference server populates the HTTP headers of responses so that 2999 they are consistent with the contents of the message. In particular, 3000 the "CacheControl" header SHOULD be set to disable caching of any 3001 conference information by HTTP intermediaries. Otherwise, there is 3002 the risk of stale information and/or the unauthorized disclosure of 3003 the information. The HTTP status code MUST indicate a 2xx series 3004 response for all CCMP Response and Error messages. 3006 The conference server MAY redirect a CCMP request. A conferencing 3007 client MUST handle redirects, by using the Location header provided 3008 by the server in a 3xx response. When redirecting, the conferencing 3009 client MUST observe the delay indicated by the Retry-After header. 3010 The conferencing client MUST authenticate the server that returns the 3011 redirect response before following the redirect. A conferencing 3012 client SHOULD authenticate the conference server indicated in a 3013 redirect. 3015 The conference server SHOULD support persistent connections and 3016 request pipelining. If pipelining is not supported, the conference 3017 server MUST NOT allow persistent connections. The conference server 3018 MUST support termination of a response by the closing of a 3019 connection. 3021 Implementations of CCMP that implement HTTP transport MUST implement 3022 transport over TLS [RFC2818]. TLS provides message integrity and 3023 confidentiality between the conference control client and the 3024 conference control server. The conferencing client MUST implement 3025 the server authentication method described in HTTPS [RFC2818]. The 3026 device uses the URI obtained during conference server discovery to 3027 authenticate the server. The details of this authentication method 3028 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3029 the conferencing client SHOULD fail a request if server 3030 authentication fails. 3032 10. Security Considerations 3034 As identified in the XCON framework [RFC5239], there are a wide 3035 variety of potential attacks related to conferencing, due to the 3036 natural involvement of multiple endpoints and the capability to 3037 manipulate the data on the conference server using CCMP. Examples of 3038 attacks include the following: an endpoint attempting to listen to 3039 conferences in which it is not authorized to participate, an endpoint 3040 attempting to disconnect or mute other users, and theft of service by 3041 an endpoint in attempting to create conferences it is not allowed to 3042 create. 3044 The following summarizes the security considerations for CCMP: 3045 1. The client MUST determine the proper conference server. The 3046 conference server discovery is described in Section 7. 3047 2. The client MUST connect to the proper conference server. The 3048 mechanisms for addressing this security consideration are 3049 described in Section 10.1. 3050 3. The protocol MUST support a confidentiality and integrity 3051 mechanism. As described in Section 9, implementations of CCMP 3052 MUST implement the HTTP transport over TLS [RFC2818]. 3053 4. There are security issues associated with the authorization to 3054 perform actions on the conferencing system to invoke specific 3055 capabilities. A conference server SHOULD ensure that only 3056 authorized entities can manipulate the conference data. The 3057 mechanisms for addressing this security consideration are 3058 described in Section 10.2. 3059 5. The privacy and security of the identity of a user in the 3060 conference MUST be assured. The mechanisms to ensure the 3061 security and privacy of identity are discussed in Section 10.3. 3062 6. A final issue is related to Denial of Service (DoS) attacks on 3063 the conferencing server itself. In order to minimize the 3064 potential for DoS attacks, it is RECOMMENDED that conferencing 3065 systems require user authentication and authorization for any 3066 client participating in a conference. This can be accomplished 3067 through the use of the mechanisms described in Section 10.2, as 3068 well as by using the security mechanisms associated with the 3069 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 3071 10.1. Assuring that the Proper Conferencing Server has been contacted 3073 When the CCMP transaction is conducted using TLS [RFC5246], the 3074 conference server can authenticate its identity, either as a domain 3075 name or as an IP address, to the conference client by presenting a 3076 certificate containing that identifier as a subjectAltName (i.e., as 3077 an iPAddress or dNSName, respectively). With the use of HTTP as a 3078 transport for CCMP, this is exactly the authentication described by 3079 TLS [RFC2818]. If the client has external information as to the 3080 expected identity or credentials of the proper conference server 3081 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 3082 implementation of CCMP MUST be capable of being transacted over TLS 3083 so that the client can request the above authentication, and a 3084 conference server implementation MUST include this feature. Note 3085 that in order for the presented certificate to be valid at the 3086 client, the client must be able to validate the certificate. In 3087 particular, the validation path of the certificate must end in one of 3088 the client's trust anchors, even if that trust anchor is the 3089 conference server certificate itself. 3091 10.2. User Authentication and Authorization 3093 Many policy authorization decisions are based on the identity of the 3094 user or the role that a user may have. The conferencing server MUST 3095 implement mechanisms for authentication of users to validate their 3096 identity. There are several ways that a user might authenticate its 3097 identity to the system. For users joining a conference using one of 3098 the call signaling protocols, the user authentication mechanisms for 3099 the specific protocol can be used. For the case of users joining the 3100 conference using the CCMP, TLS is RECOMMENDED. 3102 The XCON Framework [RFC5239] provides an overview of other 3103 authorization mechanisms. In the cases where a user is authorized 3104 via multiple mechanisms, it is RECOMMENDED that the conference server 3105 correlate the authorization of the CCMP interface with other 3106 authorization mechanisms - e.g., PSTN users that join with a PIN and 3107 control the conference using CCMP. When a conference server presents 3108 the identity of authorized users, it MAY provide information about 3109 the way the identity was proven or verified by the system. A 3110 conference server can also allow a completely unauthenticated user 3111 into the system - this information SHOULD also be communicated to 3112 interested parties. 3114 Once a user is authenticated and authorized through the various 3115 mechanisms available on the conference server, the conference server 3116 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3117 associate the XCON-USERID with any signaling specific user 3118 identifiers that were used for authentication and authorization. 3119 This XCON-USERID can be provided to a specific user through the 3120 conference notification interface and MUST be provided to users that 3121 interact with the conferencing system using the CCMP (i.e., in the 3122 appropriate CCMP response messages). This conference user identifier 3123 is REQUIRED for any subsequent operations on the conference object. 3125 We herein remark that the definition of a complete solution for 3126 policy-based management of an XCON-compliant conference system is out 3127 of the scope of this document, as well as of the XCON WG. We believe 3128 that the specification of such a framework is orthogonal to the 3129 overall XCON architecture, especially if a Role Based Access Control 3130 (RBAC) approach is embraced. In RBAC, the following elements are 3131 identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; 3132 (v) Permissions. For all of the above elements a direct mapping 3133 exists onto the main XCON entities. As an example, RBAC objects map 3134 onto XCON data model objects and RBAC operations map onto CCMP 3135 operations. 3137 Future documents might work on the definition of an RBAC framework 3138 for XCON, by first focusing on the definition of roles and eventually 3139 arriving at the specification of the needed permission policy sets 3140 and role policy sets (used to associate policy permission sets with 3141 specific roles). With these policies in place, access to a 3142 conference object compliant with the XCON data model can be 3143 appropriately controlled. Finally, coming to the issue of assigning 3144 users to roles, this can be done through so-called role-assignment 3145 policies. Such assignment should be under the responsibility of an 3146 ad-hoc dedicated Role Assignment entity. 3148 10.3. Security and Privacy of Identity 3150 An overview of the required privacy and anonymity for users of a 3151 conferencing system are provided in the XCON Framework [RFC5239]. 3152 The security of the identity in the form of the XCON-USERID is 3153 provided in the CCMP protocol through the use of TLS. 3155 The conference server SHOULD provide mechanisms to ensure the privacy 3156 of the XCON-USERID. This is accomplished by the conference client 3157 manipulation of the "provide-anonymity" element defined in the XCON 3158 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 3159 anonymity" element controls the degree to which a user reveals their 3160 identity. The conference client MUST set the "provide-anonymity" 3161 element to "hidden" if the user does not want other participants to 3162 even be aware that there is an additional participant in the 3163 conference. The conference client MUST set the "provide-anonymity" 3164 field to "private" if the user wants to be entirely "anonymous" 3165 (i.e., other participants are aware that there is another 3166 participant, but have no information as to their identity). The 3167 conference client MUST set the "provide-anonymity" field to "semi- 3168 private" if their identity is only to be revealed to other 3169 participants or users that have a higher level authorization (e.g., a 3170 conferencing system can be configured such that an administrator can 3171 see all users). To provide the required privacy, the conference 3172 client SHOULD include the "provide-anonymity" element in the 3173 "confInfo" parameter in a CCMP confRequest message with an "update" 3174 or "create" operation or in the "userInfo" parameter in a CCMP 3175 userRequest message with an "update" or "create" operation, to ensure 3176 the user is provided the appropriate level of privacy. If the 3177 "provide-anonymity" element is not included in the conference object, 3178 then other users can see the participant's identity. 3180 11. XML Schema 3182 This section provides the XML schema definition of the "application/ 3183 ccmp+xml" format. 3185 3186 3195 3197 3200 3201 3203 3205 3206 3207 3209 3210 3212 3214 3215 3216 3218 3219 3220 3222 3224 3225 3227 3229 3231 3233 3235 3237 3238 3239 3241 3243 3244 3245 3246 3247 3248 3249 3250 3251 3253 3255 3257 3258 3259 3261 3263 3264 3265 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3278 3280 3282 3283 3284 3286 3288 3289 3290 3292 3294 3295 3296 3297 3298 3299 3300 3301 3302 3304 3306 3308 3309 3310 3312 3314 3315 3317 3319 3321 3322 3323 3324 3325 3326 3327 3328 3329 3331 3333 3335 3336 3337 3339 3341 3342 3343 3345 3347 3348 3349 3350 3351 3352 3353 3354 3355 3357 3359 3361 3362 3363 3366 3368 3369 3370 3372 3374 3375 3376 3377 3378 3379 3380 3381 3382 3384 3386 3388 3389 3390 3392 3394 3395 3396 3398 3400 3401 3402 3403 3404 3405 3406 3407 3408 3410 3412 3415 3416 3417 3419 3421 3422 3423 3425 3427 3428 3429 3430 3431 3432 3433 3434 3435 3437 3439 3442 3443 3444 3446 3448 3449 3450 3452 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3465 3468 3469 3470 3472 3474 3475 3476 3478 3480 3481 3482 3483 3484 3485 3486 3487 3488 3490 3492 3495 3496 3497 3499 3501 3502 3503 3505 3507 3508 3509 3512 3514 3516 3518 3520 3522 3524 3525 3526 3528 3530 3531 3532 3533 3534 3535 3536 3537 3538 3540 3542 3544 3545 3546 3548 3550 3551 3552 3554 3556 3557 3558 3559 3560 3561 3562 3563 3564 3566 3568 3570 3571 3572 3574 3576 3577 3578 3580 3582 3583 3584 3585 3586 3587 3588 3589 3590 3592 3594 3596 3597 3598 3600 3602 3603 3604 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3617 3619 3621 3622 3623 3625 3627 3628 3629 3631 3633 3634 3635 3636 3637 3638 3639 3640 3641 3643 3645 3647 3648 3649 3651 3653 3654 3656 3658 3660 3661 3662 3663 3664 3665 3666 3667 3668 3670 3672 3674 3675 3676 3678 3680 3681 3682 3684 3686 3687 3688 3689 3690 3691 3692 3693 3694 3696 3698 3701 3702 3703 3705 3707 3708 3709 3711 3713 3714 3715 3716 3717 3718 3719 3720 3721 3723 3725 3728 3729 3730 3732 3734 3735 3736 3738 3740 3741 3742 3743 3744 3745 3746 3747 3748 3750 3751 3754 3755 3756 3758 3760 3761 3762 3764 3766 3767 3768 3769 3770 3771 3772 3773 3774 3776 3778 3781 3782 3783 3785 3787 3788 3789 3791 3793 3795 3796 3797 3798 3800 3802 3804 3805 3806 3807 3808 3809 3810 3811 3813 3815 3816 3817 3819 3821 3823 3824 3825 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3838 3840 3841 3842 3843 3845 3846 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3859 3861 3862 3863 3864 3866 3867 3869 3871 3872 3873 3874 3875 3877 3878 3879 3880 3881 3882 3883 3884 3885 3887 3890 3891 3892 3894 3897 3898 3899 3901 3902 3903 3905 3907 3909 3910 3911 3913 3914 3915 3916 3918 3919 3920 3922 3923 3924 3925 3926 3927 3929 3930 3931 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3948 3949 3950 3951 3953 3954 3955 3957 3958 3959 3960 3961 3962 3964 3965 3966 3968 3970 3972 Figure 26 3974 12. IANA Considerations 3976 This document registers a new XML namespace, a new XML schema, and 3977 the MIME type for the schema. This document also registers the 3978 "XCON" Application Service tag and the "CCMP" Application Protocol 3979 tag. This document also defines registries for the CCMP operation 3980 types and response codes. 3982 12.1. URN Sub-Namespace Registration 3984 This section registers a new XML namespace, 3985 ""urn:ietf:params:xml:ns:xcon:ccmp"". 3987 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 3988 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 3989 Mary Barnes (mary.barnes@nortel.com). 3990 XML: 3992 BEGIN 3993 3994 3996 3997 3998 CCMP Messages 3999 4000 4001

Namespace for CCMP Messages

4002

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

4003 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4004 with the RFC number for this specification.]] 4005

See RFCXXXX.

4006 4007 4008 END 4010 12.2. XML Schema Registration 4012 This section registers an XML schema as per the guidelines in 4013 [RFC3688]. 4015 URI: urn:ietf:params:xml:schema:xcon:ccmp 4016 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4017 Barnes (mary.barnes@nortel.com). 4018 Schema: The XML for this schema can be found as the entirety of 4019 Section 11 of this document. 4021 12.3. MIME Media Type Registration for 'application/ccmp+xml' 4023 This section registers the "application/ccmp+xml" MIME type. 4025 To: ietf-types@iana.org 4026 Subject: Registration of MIME media type application/ccmp+xml 4027 MIME media type name: application 4028 MIME subtype name: ccmp+xml 4029 Required parameters: (none) 4030 Optional parameters: charset 4031 Indicates the character encoding of enclosed XML for which the 4032 default is UTF-8. 4033 Encoding considerations: Uses XML, which can employ 8-bit 4034 characters, depending on the character encoding used. See RFC 4035 3023 [RFC3023], section 3.2. 4036 Security considerations: This content type is designed to carry 4037 protocol data related conference control. Some of the data could 4038 be considered private and thus should be protected. 4039 Interoperability considerations: None. 4040 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 4041 replace XXXX with the RFC number for this specification.]] 4042 Applications which use this media type: Centralized Conferencing 4043 control clients and servers. 4044 Additional Information: Magic Number(s): (none) 4045 File extension(s): .xml 4046 Macintosh File Type Code(s): (none) 4047 Person & email address to contact for further information: Mary 4048 Barnes 4049 Intended usage: LIMITED USE 4050 Author/Change controller: The IETF 4051 Other information: This media type is a specialization of 4052 application/xml [RFC3023], and many of the considerations 4053 described there also apply to application/ccmp+xml. 4055 12.4. DNS Registrations 4057 Section 12.4.1 defines an Application Service tag of "XCON", which is 4058 used to identify the centralized conferencing (XCON) server for a 4059 particular domain. The Application Protocol tag "CCMP", defined in 4060 Section 12.4.2, is used to identify an XCON server that understands 4061 the CCMP protocol. 4063 12.4.1. Registration of a Conference Control Server Application Service 4064 Tag 4066 This section registers a new S-NAPTR/U-NAPTR Application Service tag 4067 for XCON, as mandated by [RFC3958]. 4069 Application Service Tag: XCON 4071 Intended usage: Identifies a server that supports centralized 4072 conferencing. 4074 Defining publication: RFCXXXX 4076 Contact information: The authors of this document 4077 Author/Change controller: The IESG 4079 12.4.2. Registration of a Conference Control Server Application 4080 Protocol Tag for CCMP 4082 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 4083 for the CCMP protocol, as mandated by [RFC3958]. 4085 Application Service Tag: CCMP 4087 Intended Usage: Identifies the Centralized Conferencing (XCON) 4088 Manipulation Protocol. 4090 Applicable Service Tag(s): XCON 4092 Terminal NAPTR Record Type(s): U 4094 Defining Publication: RFCXXXX 4096 Contact Information: The authors of this document 4098 Author/Change Controller: The IESG 4100 12.5. CCMP Protocol Registry 4102 This document requests that the IANA create a new registry for the 4103 CCMP protocol including an initial registry for operation types and 4104 response codes. 4106 12.5.1. CCMP Message Types 4108 The CCMP messages are described in Section 4.1 and defined in the XML 4109 schema in Section 11. The following summarizes the requested 4110 registry: 4112 Related Registry: CCMP Message Types Registry 4113 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4114 with the RFC number for this specification.] 4115 Registration/Assignment Procedures: New CCMP message types are 4116 allocated on a specification required basis. 4117 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4118 Barnes (mary.barnes@nortel.com). 4120 This section pre-registers the following initial CCMP message types: 4122 optionsRequest: Used by a conference control client to query a 4123 conferencing system for its capabilities, in terms of supported 4124 messages (both standard and non-standard). 4125 optionsResponse: The optionsResponse returns a list of CCMP messages 4126 (both standard and non-standard) supported by the specific 4127 conference server. 4128 blueprintsRequest: Used by a conference control client to query a 4129 conferencing system for its capabilities, in terms of available 4130 conference blueprints. 4131 blueprintsResponse: The blueprintsResponse returns a list of 4132 blueprints supported by the specific conference server. 4133 confsRequest: Used by a conference control client to query a 4134 conferencing system for its scheduled/active conferences. 4135 confsResponse: The "confsResponse" returns the list of the currently 4136 activated/scheduled conferences at the server. 4137 confRequest: The "confRequest" is used to create a conference object 4138 and/or to request an operation on the conference object as a 4139 whole. 4140 confResponse: The "confResponse" indicates the result of the 4141 operation on the conference object as a whole. 4142 userRequest: The "userRequest" is used to request an operation on 4143 the "user" element in the conference object. 4144 userResponse: The "userResponse" indicates the result of the 4145 requested operation on the "user" element in the conference 4146 object. 4147 usersRequest This "usersRequest" is used to manipulate the "users" 4148 element in the conference object, including parameters such as the 4149 "allowed-users-list", "join-handling", etc. 4150 usersResponse: This "usersResponse" indicates the result of the 4151 request to manipulate the "users" element in the conference 4152 object. 4153 sidebarRequest: This "sidebarRequest" is used to retrieve the 4154 information related to a sidebar or to create, change or delete a 4155 specific sidebar. 4156 sidebarResponse: This "sidebarResponse" indicates the result of the 4157 sidebarRequest. 4159 12.5.2. CCMP Response Codes 4161 The following summarizes the requested registry for CCMP Response 4162 codes: 4164 Related Registry: CCMP Response Code Registry 4165 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 4166 with the RFC number for this specification.] 4168 Registration/Assignment Procedures: New response codes are allocated 4169 on a first-come/first-serve basis with specification required. 4170 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 4171 Barnes (mary.barnes@nortel.com). 4173 This section pre-registers the following thirteen initial response 4174 codes as described above in Section 4.1: 4176 200: This code indicates that the request was successfully 4177 processed. 4178 409: This code indicates that a requested "update" cannot be 4179 successfully completed by the server. An example of such 4180 situation is when the modification of an object cannot be applied 4181 due to conflicts arising at the server's side (e.g. because the 4182 client version of the object is an obsolete one and the requested 4183 modifications collide with the up-to-date state of the object 4184 stored at the server). 4185 400: This code indicates that the request was badly formed in some 4186 fashion. 4187 401: This code indicates that the user was not authorized for the 4188 specific operation on the conference object. 4189 403: This code indicates that the specific operation is not valid 4190 for the target conference object. 4191 404: This code indicates that the specific conference object was not 4192 found. 4193 420: This code is returned in answer to a "userRequest/create" 4194 operation, in the case of a third-party invite, when the 4195 "confUserID" (contained in the "entity" attribute of the 4196 "userInfo" parameter) of the user to be added is unknown. 4197 421: This code is returned in the case of requests in which the 4198 "confUserID" of the sender is invalid. 4199 422: This code is returned in response to all requests wishing to 4200 access/manipulate a password-protected conference object, when the 4201 "conference-password" parameter contained in the request is wrong. 4202 423: This code is returned in response to all requests wishing to 4203 access/manipulate a password-protected conference object, when the 4204 "conference-password" parameter is missing in the request. 4205 424: This code is returned in response whenever the server wants to 4206 authenticate the requestor through the "subject" parameter and 4207 such a parameter is not provided in the request. 4208 425: This code indicates that the conferencing system cannot delete 4209 the specific conference object because it is a parent for another 4210 conference object. 4211 426: This code indicates that the target conference object cannot be 4212 changed (e.g., due to policies, roles, privileges, etc.). 4214 510: This code indicates that the request could not be processed 4215 within a reasonable time, with the time specific to a conferencing 4216 system implementation. 4217 500: This code indicates that the conferencing system experienced 4218 some sort of internal error. 4219 501: This code indicates that the specific operation is not 4220 implemented on that conferencing system. 4222 13. Acknowledgments 4224 The authors appreciate the feedback provided by Dave Morgan, Pierre 4225 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 4226 Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special 4227 thanks go to Roberta Presta for her invaluable contribution to this 4228 document. Roberta has worked on the specification of the CCMP 4229 protocol at the University of Napoli for the preparation of her 4230 Master thesis. She has also implemented the CCMP prototype used for 4231 the trials and from which the dumps provided in Section 6 have been 4232 extracted. 4234 14. Changes since last Version 4236 NOTE TO THE RFC-Editor: Please remove this section prior to 4237 publication as an RFC. 4239 The following summarizes the changes between the WG 03 and the 04: 4241 1. Re-organized document based on feedback from Richard Barnes. 4242 2. Editorial clarifications and nits, including those identified by 4243 Richard and Simo Veikkolainen. 4245 The following summarizes the changes between the WG 07 and the 08: 4247 1. Added a new "optionsRequest" message (and related 4248 "optionsResponse" message) to the list of CCMP messages. 4249 2. Clarified discussion about notifications management, by 4250 clarifying they are out of the scope of the present document, but 4251 at the same time providing some pointers to potential ways for 4252 implementing them. 4253 3. Clarified discussion about policies in XCON, by clarifying they 4254 are out of the scope of the present document, but at the same 4255 time providing some pointers to potential ways for implementing 4256 them. 4257 4. Corrected minor typos in the schema. 4259 5. Corrected schema definitions which brought to Unique Particle 4260 Attribution exceptions. 4261 6. Added the newly defined "optionsRequest" and "optionsResponse" 4262 messages to the schema. 4263 7. Misc editorial nits... 4265 15. References 4267 15.1. Normative References 4269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4270 Requirement Levels", BCP 14, RFC 2119, March 1997. 4272 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4273 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4274 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4276 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 4277 Leach, P., Luotonen, A., and L. Stewart, "HTTP 4278 Authentication: Basic and Digest Access Authentication", 4279 RFC 2617, June 1999. 4281 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 4283 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 4284 Mechanism", RFC 2965, October 2000. 4286 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4287 January 2004. 4289 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 4290 Centralized Conferencing", RFC 5239, June 2008. 4292 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4293 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 4295 [I-D.ietf-xcon-common-data-model] 4296 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 4297 "Conference Information Data Model for Centralized 4298 Conferencing (XCON)", draft-ietf-xcon-common-data-model-19 4299 (work in progress), May 2010. 4301 15.2. Informative References 4303 [REST] Fielding, "Architectural Styles and the Design of Network- 4304 based Software Architectures", 2000. 4306 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 4307 Types", RFC 3023, January 2001. 4309 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4310 A., Peterson, J., Sparks, R., Handley, M., and E. 4311 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4312 June 2002. 4314 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 4315 Service Location Using SRV RRs and the Dynamic Delegation 4316 Discovery Service (DDDS)", RFC 3958, January 2005. 4318 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 4319 RFC 3966, December 2004. 4321 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 4322 Control Protocol (BFCP)", RFC 4582, November 2006. 4324 [I-D.ietf-xcon-event-package] 4325 Camarillo, G., Srinivasan, S., Even, R., and J. 4326 Urpalainen, "Conference Event Package Data Format 4327 Extension for Centralized Conferencing (XCON)", 4328 draft-ietf-xcon-event-package-01 (work in progress), 4329 September 2008. 4331 [I-D.ietf-xcon-examples] 4332 Barnes, M., Miniero, L., Presta, R., and S. Romano, 4333 "Centralized Conferencing Manipulation Protocol (CCMP) 4334 Call Flow Examples", draft-ietf-xcon-examples-04 (work in 4335 progress), April 2010. 4337 [W3C.REC-soap12-part1-20030624] 4338 Hadley, M., Gudgin, M., Nielsen, H., Moreau, J., and N. 4339 Mendelsohn, "SOAP Version 1.2 Part 1: Messaging 4340 Framework", World Wide Web Consortium FirstEdition REC- 4341 soap12-part1-20030624, June 2003, 4342 . 4344 [W3C.REC-soap12-part2-20030624] 4345 Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and 4346 M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 4347 Web Consortium FirstEdition REC-soap12-part2-20030624, 4348 June 2003, 4349 . 4351 Appendix A. Appendix A: Other protocol models and transports considered 4352 for CCMP 4354 The operations on the objects can be implemented in at least two 4355 different ways, namely as remote procedure calls - using SOAP as 4356 described in Appendix A.1 and by defining resources following a 4357 RESTful architecture Appendix A.2. 4359 In both approaches, servers will have to recreate their internal 4360 state representation of the object with each update request, checking 4361 parameters and triggering function invocations. In the SOAP 4362 approach, it would be possible to describe a separate operation for 4363 each atomic element, but that would greatly increase the complexity 4364 of the protocol. A coarser-grained approach to the CCMP does require 4365 that the server process XML elements in updates that have not changed 4366 and that there can be multiple changes in one update. 4368 For CCMP, the resource (REST) model might appear more attractive, 4369 since the conference operations fit the CRUD approach. 4371 Neither of these approaches were considered ideal as SOAP was not 4372 considered to be general purpose enough for use in a broad range of 4373 operational environments. It is quite awkward to apply a RESTful 4374 approach since the CCMP requires a more complex request/response 4375 protocol in order to maintain the data both in the server and at the 4376 client. This doesn't map very elegantly to the basic request/ 4377 response model, whereby a response typically indicates whether the 4378 request was successful or not, rather than providing additional data 4379 to maintain the synchronization between the client and server data. 4380 In addition, the CCMP clients may also receive the data in 4381 Notifications. While the notification method or protocol used by 4382 some conferencing clients can be independent of the CCMP, the same 4383 data in the server is used for both the CCMP and Notifications - this 4384 requires a server application above the transport layer (e.g., HTTP) 4385 for maintaining the data, which in the CCMP model is transparent to 4386 the transport protocol. 4388 A.1. Using SOAP for the CCMP 4390 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 4391 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 4392 -soap12-part2-20030624]), where conferences and the other objects are 4393 modeled as services with associated operations. Conferences and 4394 other objects are selected by their own local identifiers, such as 4395 email-like names for users. This approach has the advantage that it 4396 can easily define atomic operations that have well-defined error 4397 conditions. 4399 All SOAP operations would use a single HTTP verb. While the RESTful 4400 approach requires the use of a URI for each object, SOAP can use any 4401 token. 4403 A.2. A RESTful approach for the CCMP 4405 Conference objects can also be modeled as resources identified by 4406 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 4407 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 4408 changing objects and DELETE for deleting them. Many of the objects, 4409 such as conferences, already have natural URIs. 4411 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 4412 design pattern. The basic CRUD operations are used to manipulate 4413 conference objects, which are XML documents containing the 4414 information characterizing a specified conference instance, be it an 4415 active conference or a conference blueprint used by the conference 4416 server to create new conference instances through a simple clone 4417 operation. 4419 Following the CRUD approach, CCMP could use a general-purpose 4420 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 4421 encoded data objects defined in the Conference Information Data Model 4422 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 4424 Following on the CRUD approach, CCMP could follow the well-known REST 4425 (REpresentational State Transfer) architectural style [REST]. The 4426 CCMP could map onto the REST philosophy, by specifying resource URIs, 4427 resource formats, methods supported at each URI and status codes that 4428 have to be returned when a certain method is invoked on a specific 4429 URI. A REST-style approach must ensure sure that all operations can 4430 be mapped to HTTP operations. 4432 The following summarizes the specific HTTP method that could be used 4433 for each of the CCMP Requests: 4435 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 4436 obtain data about conference objects in the form of XML data model 4437 documents. 4439 Create: HTTP PUT could be used to create a new object as identified 4440 by the XCON-URI or XCON-USERID. 4442 Change: Either HTTP PATCH or HTTP POST could be used to change the 4443 conference object identified by the XCON-URI. 4445 Delete: HTTP DELETE could be used to delete conference objects and 4446 parameters within conference objects identified by the XCON-URI. 4448 Authors' Addresses 4450 Mary Barnes 4451 Nortel 4453 Email: mary.barnes@nortel.com 4455 Chris Boulton 4456 NS-Technologies 4458 Email: chris@ns-technologies.com 4460 Simon Pietro Romano 4461 University of Napoli 4462 Via Claudio 21 4463 Napoli 80125 4464 Italy 4466 Email: spromano@unina.it 4468 Henning Schulzrinne 4469 Columbia University 4470 Department of Computer Science 4471 450 Computer Science Building 4472 New York, NY 10027 4474 Email: hgs+xcon@cs.columbia.edu