idnits 2.17.1 draft-ietf-xcon-ccmp-09.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 18 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The MUST appear in the optionsResponse and MUST not be void, since a CCMP server MUST be able to handle at least one of the standard messages in at least one of the envisioned operations, i.e. the aforementioned list MUST carry at least one containing at least one element. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2010) is 5019 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 1362, but not defined == Missing Reference: '0-9' is mentioned on line 4252, but not defined == Unused Reference: 'RFC3966' is defined on line 4731, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-examples' is defined on line 4744, 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 (~~), 9 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: January 3, 2011 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 July 2, 2010 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-09 15 Abstract 17 The Centralized Conferencing Manipulation Protocol (CCMP) allows an 18 XCON conferencing system client to create, retrieve, change, and 19 delete objects that describe a centralized conference. CCMP is a 20 means to control basic and advanced conference features such as 21 conference state and capabilities, participants, relative roles, and 22 details. CCMP is a state-less, XML-based, client server protocol 23 that carries, in its request and response messages, conference 24 information in the form of XML documents and fragments conforming to 25 the centralized conferencing data model schema. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 3, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 3. XCON Conference Control System Architecture . . . . . . . . . 5 64 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7 65 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 68 4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11 69 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 71 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14 72 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 73 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19 74 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21 75 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22 76 5.3.4. confRequest and confResponse . . . . . . . . . . . . 24 77 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28 78 5.3.6. userRequest and userResponse . . . . . . . . . . . . 30 79 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35 80 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 36 81 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39 82 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41 83 5.3.11. extendedRequest and extendedResponse . . . . . . . . 44 84 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46 85 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49 86 6. A complete example of the CCMP in action . . . . . . . . . . 52 87 6.1. Alice retrieves the available blueprints . . . . . . . . 53 88 6.2. Alice gets detailed information about a specific 89 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55 90 6.3. Alice creates a new conference through a cloning 91 operation . . . . . . . . . . . . . . . . . . . . . . . . 57 92 6.4. Alice updates conference information . . . . . . . . . . 60 93 6.5. Alice inserts a list of users in the conference object . 62 94 6.6. Alice joins the conference . . . . . . . . . . . . . . . 63 95 6.7. Alice adds a new user to the conference . . . . . . . . . 65 96 6.8. Alice asks for the CCMP server capabilities . . . . . . . 67 97 6.9. Alice exploits a CCMP server extension . . . . . . . . . 70 98 7. Locating a Conference Control Server . . . . . . . . . . . . 73 99 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74 100 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 102 10.1. Assuring that the Proper Conferencing Server has been 103 contacted . . . . . . . . . . . . . . . . . . . . . . . . 78 104 10.2. User Authentication and Authorization . . . . . . . . . . 78 105 10.3. Security and Privacy of Identity . . . . . . . . . . . . 79 106 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80 107 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 108 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98 109 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 98 110 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99 111 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 99 112 12.4.1. Registration of a Conference Control Server 113 Application Service Tag . . . . . . . . . . . . . . . 100 114 12.4.2. Registration of a Conference Control Server 115 Application Protocol Tag for CCMP . . . . . . . . . . 100 116 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 100 117 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 100 118 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102 119 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 103 120 14. Changes since last Version . . . . . . . . . . . . . . . . . 103 121 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 122 15.1. Normative References . . . . . . . . . . . . . . . . . . 104 123 15.2. Informative References . . . . . . . . . . . . . . . . . 105 124 Appendix A. Appendix A: Other protocol models and transports 125 considered for CCMP . . . . . . . . . . . . . . . . 106 126 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 127 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 107 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 130 1. Introduction 132 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 133 defines a signaling-agnostic framework, naming conventions and 134 logical entities required for building advanced conferencing systems. 135 The XCON Framework introduces the conference object as a logical 136 representation of a conference instance, representing the current 137 state and capabilities of a conference. 139 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 140 this document allows authenticated and authorized users to create, 141 manipulate and delete conference objects. Operations on conferences 142 include adding and removing participants, changing their roles, as 143 well as adding and removing media streams and associated end points. 145 The CCMP implements the client-server model within the XCON 146 Framework, with the Conference Control Client and Conference Control 147 Server acting as client and server, respectively. The CCMP uses HTTP 148 [RFC2616] as the protocol to transfer requests and responses, which 149 contain the domain-specific XML-encoded data objects defined in 150 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 151 for Centralized Conferencing (XCON Data Model). 153 Section 2 clarifies the conventions and terminology used in the 154 document. Section 3 provides an overview of the Conference Control 155 functionality of the XCON framework, together with a description of 156 the main targets CCMP deals with, namely conference objects and 157 conference users. A general description of the operations associated 158 with protocol messages is given in Section 4 together with 159 implementation details. Section 5 delves into the details of the 160 specific CCMP messages. A complete, not normative, example of the 161 operation of the CCMP, describing a typical call flow associated with 162 conference creation and manipulation, is provided in Section 6. A 163 survey of the methods that can be used to locate a Conference Control 164 Server is provided in Section 7, whereas Section 8 discusses 165 potential approaches to notifications management. CCMP transport 166 over HTTP is highlighted in Section 9. Security considerations are 167 presented in Section 10. Finally, Section 11 provides the XML 168 schema. 170 2. Conventions and Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 In additon to the terms defined in the Framework for Centralized 177 Conferencing [RFC5239], this document uses the following terms and 178 acronyms: 180 XCON aware client: An XCON conferencing system client which is able 181 to issue CCMP requests. 183 3. XCON Conference Control System Architecture 185 CCMP supports the XCON framework . Figure 1 depicts a subset of the 186 "Conferencing System Logical Decomposition" architecture from the 187 XCON framework document. It illustrates the role that CCMP assumes 188 within the overall centralized architecture. 190 ........................................................ 191 . Conferencing System . 192 . . 193 . +---------------------------------------+ . 194 . | C O N F E R E N C E O B J E C T | . 195 . +-+-------------------------------------+ | . 196 . | C O N F E R E N C E O B J E C T | | . 197 . +-+-------------------------------------+ | | . 198 . | C O N F E R E N C E O B J E C T | | | . 199 . | | |-+ . 200 . | |-+ . 201 . +---------------------------------------+ . 202 . ^ . 203 . | . 204 . v . 205 . +-------------------+ . 206 . | Conference Control| . 207 . | Server | . 208 . +-------------------+ . 209 . ^ . 210 .........................|.............................. 211 | 212 |Centralized 213 |Conferencing 214 |Manipulation 215 |Protocol 216 | 217 .........................|.............................. 218 . V . 219 . +----------------+ . 220 . | Conference | . 221 . | Control | . 222 . | Client | . 223 . +----------------+ . 224 . . 225 . Conferencing Client . 226 ........................................................ 228 Figure 1: Conference Client Interaction 230 CCMP serves as the Conference Control Protocol, allowing the 231 conference control client to interface with the conference object 232 maintained by the conferencing system, as represented in Figure 1. 233 Conference Control is one part of functionality for advanced 234 conferencing supported by a conferencing client. Other functions are 235 discussed in the XCON framework and related documents. 237 Conference object and conference users do represent key elements 238 involved in Conference Control Protocol operations. Their 239 identifiers, respectively the conference XCON-URI and the 240 conferencing client XCON-USERID, and their XML representations 241 compliant with the XML Schema defined in the XCON data model are 242 widely used for creating the CCMP requests and responses. The main 243 conference objects and users features envisioned by the XCON 244 framework are briefly described in the following subsections. 246 3.1. Conference Objects 248 Conference objects feature a simple dynamic inheritance-and-override 249 mechanism. Conference objects are linked into a tree known as 250 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 251 node inherits attributes from its parent node. The roots of these 252 inheritance trees are conference templates also known as 253 "blueprints". Nodes in the inheritance tree can be active 254 conferences or simply descriptions that do not currently have any 255 resources associated with them (conference reservations). An object 256 can mark certain of its properties as unalterable, so that they 257 cannot be overridden. It is envisaged by the framework that a client 258 may specify a parent object (a conference or blueprint) from which 259 the conference to be created has to inherit values by the mean of the 260 Conference Control Protocol. 262 Conference objects are uniquely identified by the XCON-URI within the 263 scope of the conferencing system. Such identifier is introduced in 264 the XCON framework and defined in the XCON common data model. 266 Conference objects are comprehensively represented through XML 267 documents compliant with the XML Schema defined in the XCON data 268 model [I-D.ietf-xcon-common-data-model]. The root element of such 269 documents, called "", is of type "conference-type". 270 It encompasses other XML elements describing different conference 271 features and users as well. By the mean of CCMP, conferencing 272 clients can use such XML structures to express their preferences in 273 creation or update. A conferencing server can convey conference 274 information of such a form back to the clients. 276 3.2. Conference Users 278 Each conference can have zero or more users. All conference 279 participants are users, but some users may have only administrative 280 functions and do not contribute or receive media. Users are added 281 one user at a time to simplify error reporting. When a conference is 282 cloned from a parent object, users are inherited as well, so that it 283 is easy to set up a conference that has the same set of participants 284 or a common administrator. The Conference Control Server creates 285 individual users, assigning them a unique Conference User Identifier 286 (XCON-USERID). The XCON-USERID as identifier of each conferencing 287 system client is introduced in the XCON framework and defined in the 288 XCON common data model. Each CCMP request, with an exception pointed 289 out in Section 5.3.6 representing the case of a user at his first 290 entrance in the system as a conference participant, must carry the 291 XCON-USERID of the requestor in the proper "confUserID" parameter. 293 The XCON-USERID acts as a pointer to the user's profile as a 294 conference actor, e.g. her signalling URI and other XCON protocol 295 URIs in general, her role (moderator, participant, observer, etc.), 296 her display text, her joining information and so on. A variety of 297 elements defined in the common element as specified 298 in the XCON data model are used to describe the users related to a 299 conference, in the first place the element, as well as each 300 element included in it. For example, it is possible to 301 determine how a specific user expects and is allowed to join a 302 conference by looking at the in : each 303 element involved in such a list represents a user and shows 304 a "method" attribute defining how the user is expected to join the 305 conference, i.e. "dial-in" for users that are allowed to dial, "dial- 306 out" for users that the conference focus will be trying to reach 307 (with "dial-in" being the default mode). If the conference is 308 currently active, dial-out users are contacted immediately; 309 otherwise, they are contacted at the start of the conference. The 310 CCMP, acting as the Conference Control Protocol, provides a means to 311 manipulate these and other kinds of user-related features. 313 As a consequence of an explicit user registration to a specific XCON 314 conferencing system, conferencing clients are usually provided 315 (besides the XCON-USERID) with log-in credentials (i.e. username and 316 password). Such credentials can be used to authenticate the XCON 317 aware client issuing CCMP requests. To this purpose, both username 318 and password should be carried in a CCMP request as part of the 319 "subject" parameter whenever a registered conferencing client wishes 320 to contact a CCMP server. The CCMP does not look after users 321 subscriptions at the conference server; hence, it does not provide 322 any specific mechanism allowing clients to register their 323 conferencing accounts. The "subject" parameter is just used for 324 carrying authentication data associated with pre-registered clients. 326 4. Protocol Overview 328 CCMP is a client-server, XML-based protocol, which has been 329 specifically conceived to provide users with the necessary means for 330 the creation, retrieval, modification and deletion of conference 331 objects. CCMP is also state-less, which means implementations can 332 safely handle transactions independently from each other. 333 Conference-related information is encapsulated into CCMP messages in 334 the form of XML documents or XML document fragments compliant with 335 the XCON data model representation. 337 Section 4.1 specifies the basic operations that can create, retrieve, 338 modify and delete conference-related information in a centralized 339 conference. The core set of objects manipulated in the CCMP protocol 340 includes conference blueprints, the conference object, users, and 341 sidebars. 343 CCMP has been conceived as completely independent from underlying 344 protocols, which means that there can be different ways to carry CCMP 345 messages across the network, from a conferencing client to a 346 conferencing server. Nevertheless, it is recommended to use HTTP as 347 a transport solution, including CCMP requests in HTTP POST messages 348 and CCMP responses in HTTP 200 OK replies. Implementation details 349 are presented in Section 4.2 351 4.1. Protocol Operations 353 The main operations provided by CCMP belong in four general 354 categories: 356 create: for the creation of a conference, a conference user, a 357 sidebar, or a blueprint. 358 retrieve: to get information about the current state of either a 359 conference object (be it an actual conference or a blueprint, or a 360 sidebar) or a conference user. A retrieve operation can also be 361 used to obtain the XCON-URIs of the current conferences (active or 362 registered) handled by the conferencing server and/or the 363 available blueprints. 364 update: to modify the current features of a specified conference or 365 conference user. 366 delete: to remove from the system a conference object or a 367 conference user. 369 Thus, the main targets of CCMP operations are: 371 o conference objects associated with either active or registered 372 conferences, 373 o conference objects associated with blueprints, 374 o conference objects associated with sidebars, both embedded in the 375 main conference (i.e. elements in ) and 376 external to it (i.e. whose xcon-uris are included in the 377 elements of ), 379 o elements associated with conference users, 380 o the list of XCON-URIs related to conferences and blueprints 381 available at the server, for which only retrieval operations are 382 allowed. 384 Each operation in the protocol model is atomic and either succeeds or 385 fails as a whole. The conference server must ensure that the 386 operations are atomic in that the operation invoked by a specific 387 conference client completes prior to another client's operation on 388 the same conference object. The details for this data locking 389 functionality are out of scope for the CCMP protocol specification 390 and are implementation specific for a conference server. Thus, the 391 conference server first checks all the parameters, before making any 392 changes to the internal representation of the conference object. For 393 example, it would be undesirable to change the of the 394 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 396 can modify the same conference objects, conference clients should 397 first obtain the current object from the conference server and then 398 update the relevant data elements in the conference object prior to 399 invoking a specific operation on the conference server. In order to 400 effectively manage modifications to conference data, a versioning 401 approach is exploited in the CCMP. More precisely, each conference 402 object is associated with a version number indicating the most up to 403 date view of the conference at the server's side. Such version 404 number is reported to the clients when answering their requests. A 405 client willing to make modifications to a conference object has to 406 send an update message to the server. In case the modifications are 407 all successfully applied, the server sends back to the client a "200" 408 response which also carries information about the current server-side 409 version of the modified object. With such approach, a client which 410 is working on version "X" of a conference object and finds inside a 411 "200" response a version number which is "X+1" can be sure that the 412 version it was aware of was the most up to date. On the other hand, 413 if the "200" response carries back a version which is at least "X+2", 414 the client can detect that the object that has been modified at the 415 server's side was more up to date than the one it was working upon. 416 This is clearly due to the effect of concurrent modification requests 417 issued by independent clients. Hence, for the sake of having 418 available the latest version of the modified object, the client can 419 send to the conference server a further "retrieve" request. In no 420 case a copy of the conference object available at the server is 421 returned to the client as part of the update response message. Such 422 a copy can always be obtained through an ad-hoc "retrieve" message. 424 Based on the above considerations, all CCMP response messages 425 carrying in their body a conference document (or a fragment of it) 426 must contain a "version" parameter. This does not hold for request 427 messages, for which the "version" parameter is not at all required, 428 since it represents useless information for the server: as long as 429 the required modifications can be applied to the target conference 430 object with no conflicts, the server does not care whether or not the 431 client had an up to date view of the information stored at its side. 432 This said, it stands clear that a client which has subscribed at the 433 server, through the XCON event package [I-D.ietf-xcon-event-package], 434 to notifications about conference object modifications, will always 435 have the most up to date version of that object available at his 436 side. 438 A final consideration concerns the relation between the CCMP and the 439 main entities it manages, i.e. conference objects. Such objects have 440 to be compliant with the XCON data-model, which identifies some 441 elements/attributes as mandatory. From the CCMP standpoint this can 442 become a problem in cases of client-initiated operations, like the 443 creation/update of conference objects. In such cases, not all of the 444 mandatory data can be known in advance to the client issuing a CCMP 445 request. As an example, a client has no means to know, at the time 446 it issues a conference creation request, the XCON-URI that the server 447 will assign to the yet-to-be-created conference and hence it is not 448 able to appropriately fill with that value the mandatory "entity" 449 attribute of the conference document contained in the request. To 450 solve this kind of issues, the CCMP will fill all mandatory data 451 model fields, for which no value is available at the client at the 452 time the request is constructed, with fake values in the form of 453 wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental 454 index initialized to a value of 1). Upon reception of the mentioned 455 kinds of requests, the server will: (i) generate the proper 456 identifier(s); (ii) produce a response in which the received fake 457 identifier(s) carried in the request has (have) been replaced by the 458 newly created one(s). With this approach we maintain compatibility 459 with the data model requirements, at the same time allowing for 460 client-initiated manipulation of conference objects at the server's 461 side (which is, by the way, one of the main goals for which the CCMP 462 protocol has been conceived at the outset). 464 4.2. Implementation Approach 466 There have been a number of different proposals as to the most 467 suitable implementation solution for the CCMP. A non-exhaustive 468 summary of the most interesting ones is provided in Appendix A. The 469 solution for the CCMP defined in this document is viewed as a good 470 compromise amongst the most notable past candidates and is referred 471 to as "HTTP single-verb transport plus CCMP body". With this 472 approach, CCMP is able to take advantage of existing HTTP 473 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 474 transport (i.e. a single transaction type for each request/response 475 pair); this allows decoupling CCMP messages from HTTP messages. 476 Similarly, as with any RESTful approach, CCMP messages are inserted 477 directly in the body of HTTP messages, thus avoiding any unnecessary 478 processing and communication burden associated with further 479 intermediaries. With this approach, no modification to the CCMP 480 messages/operations is required to use a different transport 481 protocol. 483 The remainder of this document focuses on the selected approach. The 484 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 485 POST operations and retrieves responses from the body of HTTP "200 486 OK" messages. CCMP messages have a MIME-type of "application/ 487 ccmp+xml", which appears inside the "Content-Type" and "Accept" 488 fields of HTTP requests and responses. Section 9 provides the 489 complete requirements for an HTTP implementation to support the CCMP. 491 5. CCMP messages 493 CCMP messages are either requests or responses. The general CCMP 494 request message is defined in Section 5.1. The general CCMP response 495 message is defined in Section 5.2. The details of the specific 496 message type which is carried in the CCMP request and response 497 messages are described in Section 5.3. CCMP response codes are 498 listed in Section 5.4 500 5.1. CCMP Request Message Type 502 A CCMP request message is comprised of the following parameters: 504 subject: An optional parameter containing username and password of 505 the client registered at the conferencing system. Each user who 506 subscribes to the conferencing system is assumed to be equipped 507 with those credentials and SHOULD enclose them in each CCMP 508 request she issues. These fields can be used to control that the 509 user sending the CCMP request has the authority to perform the 510 entailed operation. The same fields can also be exploited to 511 carry out other Authorization, Authentication and Accounting (AAA) 512 procedures. 513 confUserID: An optional parameter containing the XCON-USERID of the 514 client. The XCON-USERID is used to identify any conferencing 515 client within the context of the conferencing system and it is 516 assinged by the conferencing server at each conferencing client 517 who interacts with it. The "confUserID" parameter is REQUIRED in 518 the CCMP request and response messages with the exception of the 519 case of a user who has no XCON-USERID and who wants to enter, via 520 CCMP, a conference whose identifier is known. In such case, a 521 side-effect of the request is that the user is provided with an 522 appropriate XCON-USERID. An example of the above mentioned case 523 will be provided in Section 5.3.6. 524 confObjID: An optional parameter containing the XCON-URI of the 525 target conference object. 526 operation: An optional parameter refining the type of specialized 527 request message. The "operation" parameter is REQUIRED in all 528 requests except for the "blueprintsRequest" and "confsRequest" 529 specialized messages. 530 conference-password: An optional parameter that MUST be inserted in 531 all requests whose target conference object is password-protected 532 (as per the element in 533 [I-D.ietf-xcon-common-data-model]). 534 specialized request message: This is specialization of the generic 535 request message (e.g., blueprintsRequest), containing parameters 536 that are dependent on the specific request sent to the server. A 537 specialized request message MUST be included in the CCMP request 538 message. The details for the specialized messages and associated 539 parameters are provided in Section 5.3. 541 543 545 547 548 549 551 552 554 556 558 559 561 563 565 567 569 571 572 573 575 Figure 2: Structure of CCMP Request messages 577 5.2. CCMP Response Message Type 579 A CCMP response message is comprised of the following parameters: 581 confUserID: A mandatory parameter in CCMP response messages 582 containing the XCON-USERID of the conferencing client who issued 583 the CCMP request message. 585 confObjID: An optional parameter containing the XCON-URI of the 586 target conference object. 587 operation: An optional parameter for CCMP response messages. This 588 parameter is REQUIRED in all responses except for the 589 "blueprintsResponse" and "confsResponse" specialized messages. 590 response-code: A mandatory parameter containing the response code 591 associated with the request. The response code MUST be chosen 592 from the codes listed in Section 5.4. 593 response-string: An optional reason string associated with the 594 response. In case of an error, in particular, such string can be 595 used to provide the client with detailed information about the 596 error itself. 597 version: An optional parameter reflecting the current version number 598 of the conference object referred by the confObjID. This number 599 is contained in the "version" attribute of the 600 element related to that conference. 601 specialized response message: This is specialization of the generic 602 response message, containing parameters that are dependent on the 603 specific request sent to the server (e.g., blueprintsResponse). A 604 specialized response message SHOULD be included in the CCMP 605 response message, except in an error situation where the CCMP 606 request message did not contain a valid specialized message. In 607 this case, the conference server MUST return a "response-code" of 608 "400". The details for the specialized messages and associated 609 parameters are provided in Section 5.3. 611 613 615 617 618 619 621 622 624 626 628 629 631 633 635 637 639 641 643 644 645 647 Figure 3: Structure of CCMP Response message 649 5.3. Detailed messages 651 Based on the request and response message structures described in 652 Section 5.1 and Section 5.2, the following summarizes the specialized 653 CCMP request/response types described in this document: 655 1. blueprintsRequest/blueprintsResponse 656 2. confsRequest/confsResponse 657 3. blueprintRequest/blueprintResponse 658 4. confRequest/confResponse 659 5. usersRequest/usersResponse 660 6. userRequest/userResponse 661 7. sidebarsByValRequest/sidebarsByValResponse 662 8. sidebarsByRefRequest/sidebarsByRefResponse 663 9. sidebarByValRequest/sidebarByValResponse 664 10. sidebarByRefRequest/sidebarByRefResponse 665 11. extendedRequest/extendedResponse 666 12. optionsRequest/optionsResponse 668 These CCMP request/response pairs use the fundamental CCMP operations 669 as defined in Section 4.1 to manipulate the conference data. The 670 optionsRequest/optionsResponse message pair deserves a specific 671 discussion, since it is not used for manipulating information about 672 either conferences or conference users, but rather to retrieve 673 general information about conference server capabilities, in terms of 674 standard CCMP messages it supports, plus potential extension messages 675 it understands, as it will be further explained in Section 5.3.12. 676 Table 1 summarizes the remaining CCMP operations and corresponding 677 actions that are valid for a specific CCMP request type, noting that 678 neither the blueprintsRequest/blueprintsResponse nor confsRequest/ 679 confsResponse require an "operation" parameter. The corresponding 680 response MUST contain the same operation. Note that some entries are 681 labeled "N/A" indicating the operation is invalid for that request 682 type. In the case of an "N/A*", the operation MAY be allowed for 683 specific privileged users or system administrators, but is not part 684 of the functionality included in this document. 686 +---------------+------------+------------+------------+------------+ 687 | Operation | Retrieve | Create | Update | Delete | 688 | ------------- | | | | | 689 | Request Type | | | | | 690 +---------------+------------+------------+------------+------------+ 691 | blueprints | Get list | N/A | N/A | N/A | 692 | Request | of | | | | 693 | | blueprints | | | | 694 | ------------- | ---------- | ---------- | ---------- | ---------- | 695 | blueprint | Get | N/A* | N/A* | N/A* | 696 | Request | blueprint | | | | 697 | ------------- | ---------- | ---------- | ---------- | ---------- | 698 | confsRequest | Get list | N/A | N/A | N/A | 699 | | of confs | | | | 700 | ------------- | ---------- | ---------- | ---------- | ---------- | 701 | confRequest | Gets | Creates | Changes | Deletes | 702 | | conference | conference | conference | conference | 703 | | object | object | object | object | 704 | ------------- | ---------- | ---------- | ---------- | ---------- | 705 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 706 | | | | | | 707 | ------------- | ---------- | ---------- | ---------- | ---------- | 708 | userRequest | Gets | Adds a | Changes | Deletes | 709 | | specified | to | specified | specified | 710 | | | a conf | | | 711 | | | (***) | | | 712 | ------------- | ---------- | ---------- | ---------- | ---------- | 713 | sidebarsByVal | Gets | N/A | N/A | N/A | 714 | Request | | | | | 716 | ------------- | ---------- | ---------- | ---------- | ---------- | 717 | sidebarsByRef | Gets | N/A | N/A | N/A | 718 | Request | | | | | 720 | ------------- | ---------- | ---------- | ---------- | ---------- | 721 | sidebarByVal | Gets | Creates | Changes | Deletes | 722 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 723 | | by-val | by-val | by-val | by-val | 724 | ------------- | ---------- | ---------- | ---------- | ---------- | 725 | sidebarByRef | Gets | Creates | Changes | Deletes | 726 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 727 | | by-ref | by-ref | by-ref | by-ref | 728 +---------------+------------+------------+------------+------------+ 730 Table 1: Request Type Operation Specific Processing 732 (**): These operations are not allowed for a usersRequest message, 733 since the section, which is the target element of such a 734 request, is created and removed in conjuntcion with, respectively, 735 the creation and deletion of the associated conference document. 736 Thus, "update" and "retrieve" are the only semantically correct 737 operations for such message. 739 (***): This operation can involve the creation of an XCON-USERID, if 740 the sender does not add it in the "confUserID" parameter, and/or if 741 the "entity" field of the "userInfo" parameter is void. 743 Additional parameters included in the specialized CCMP request/ 744 response messages are detailed in the subsequent sections. 746 5.3.1. blueprintsRequest and blueprintsResponse 748 A "blueprintsRequest" (Figure 4) message is sent to request the list 749 of XCON-URIs associated with the available blueprints from the 750 conference server. Such URIs can be subsequently used by the client 751 to access detailed information about a specified blueprint with a 752 specific blueprintRequest message per Section 5.3.3. The 753 "confUserID" parameter MUST be included in every blueprintsRequest/ 754 Response message and reflect the XCON-USERID of the conferencing 755 client issuing the request. A blueprintsRequest message REQUIRES no 756 "confObjID" and "operation" parameters, since it is not targetted to 757 a specific conference instance and it is conceived as a "retrieve- 758 only" request. In order to obtain a specific subset of the available 759 blueprints, a client may specify a selection filter providing an 760 appropriate xpath query in the optional "xpathFilter" parameter of 761 the request. For example, to select blueprints having both audio and 762 video stream support, a possible xpathFilter value could be: "/ 763 conference-info[conference-description/available-media/entry/ 764 type='audio' and conference-description/available-media/entry/ 765 type='video']". 767 The associated "blueprintsResponse" message SHOULD contain, as shown 768 in Figure 4, a "blueprintsInfo" parameter containing the above 769 mentioned XCON-URI list. 771 773 774 775 776 777 778 779 781 782 784 786 788 789 790 791 793 794 795 797 799 800 801 802 803 804 805 806 807 809 811 813 814 815 817 819 820 821 823 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 824 messages 826 5.3.2. confsRequest and confsResponse 828 A "confsRequest" message is used to retrieve, from the server, the 829 list of XCON-URIs associated with active and registered conferences 830 currently handled by the conferencing system. The "confUserID" 831 parameter MUST be included in every confsRequest/Response message and 832 reflect the XCON-USERID of the conferencing client issuing the 833 request. The "confObjID" parameter MUST NOT be included in the 834 confsRequest message. The "confsRequest" message is of a "retrieve- 835 only" type, since the sole purpose is to collect information 836 available at the conference server. Thus, an "operation" parameter 837 MUST NOT be included in a "confsRequest" message. In order to 838 retrieve a specific subset of the available conferences, a client may 839 specify a selection filter providing an appropriate xpath query in 840 the optional "xpathFilter" parameter of the request. For example, to 841 select only the registered conferences, a possible xpathFilter value 842 could be: "/conference-info[conference-description/conference-state/ 843 active='false']". The associated "confsResponse" message SHOULD 844 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 845 upon receipt of the response message, can interact with the available 846 conference objects through further CCMP messages. 848 850 851 852 853 854 855 856 857 858 860 862 864 865 866 867 869 870 871 872 874 875 876 877 878 879 880 881 882 884 886 888 889 890 892 894 895 896 898 Figure 5: Structure of the confsRequest and confsResponse messages 900 5.3.3. blueprintRequest and blueprintResponse 902 Through a "blueprintRequest", a client can manipulate the conference 903 object associated with a specified blueprint. Further than the 904 "confUserID" parameter, the request MUST include the "confObjID" and 905 the "operation" one. Again, the "confUserID" parameter MUST be 906 included in every blueprintRequest/Response message and reflect the 907 XCON-USERID of the conferencing client issuing the request. The 908 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 909 which might have been previously retrieved through a 910 "blueprintsRequest" message. 912 The blueprintRequest message SHOULD NOT contain an "operation" 913 parameter other than "retrieve". The "create", "update" and "delete" 914 operations SHOULD NOT be included in a "blueprintRequest" message 915 except in the case of privileged users (e.g. the conference server 916 administration staff), who might authenticate themselves by the mean 917 of the "subject" request parameter. 919 A blueprintRequest/retrieve carrying a "confObjID" which is not 920 associated with one of the available system's blueprints will 921 generate, on the server's side, a blueprintResponse message 922 containing a "404" error code. This holds also for the case in which 923 the mentioned "confObjID" is related to an existing conference 924 document stored at the server, but associated with an actual 925 conference (be it active or registered) or with a sidebar rather than 926 a blueprint. 928 In the case of "response-code" of "200" for a "retrieve" operation, 929 the "blueprintInfo" parameter MUST be included in the 930 "blueprintResponse" message. The "blueprintInfo" parameter contains 931 the conference document associated with the blueprint as identified 932 by the "confObjID" parameter specified in the blueprintRequest. 934 936 937 938 939 940 941 942 943 944 946 948 950 951 952 954 956 957 958 960 962 963 964 965 966 967 968 969 970 972 974 976 977 978 980 982 983 984 986 Figure 6: Structure of the blueprintRequest and blueprintResponse 987 messages 989 5.3.4. confRequest and confResponse 991 With a "confRequest" message, CCMP clients can manipulate conference 992 objects associated with either active or registered conferences. The 993 "confUserID" parameter MUST be included in every confRequest/Response 994 message and reflect the XCON-USERID of the conferencing client 995 issuing the request. ConfRequest and confResponse messages MUST also 996 include an "operation" parameter. ConfResponse messages MUST return 997 to the requestor a "response-code" and MAY contain a "response- 998 string" explaining it. Depending upon the type of "operation", a 999 "confObjID" and "confInfo" parameter MAY be included in the 1000 confRequest and response. The requirements for inclusion of 1001 "confObjID" and "confInfo" parameter in the confRequest/confResponse 1002 messages and are detailed below for each "operation" case. 1004 The creation case deserves care. To create a new conference through 1005 a "confRequest" message, two approaches can be considered: 1007 1. Creation through explicit cloning: the "confObjID" parameter MUST 1008 contain the XCON-URI of the blueprint or of the conference to be 1009 cloned, while the "confInfo" parameter MUST NOT be included in 1010 the confRequest; 1012 2. Creation through implicit cloning (also known as "direct 1013 creation"): the "confObjID" parameter MUST NOT be included in the 1014 request and the CCMP client can describe the desired conference 1015 to be created using the "confInfo" parameter. If no "confInfo" 1016 parameter is provided in the request, the new conference will be 1017 created as a clone of the system default blueprint. 1019 In both creation cases, the confResponse, for a successful completion 1020 of a "create" operation, contains a response-code of "200" and MUST 1021 contain the XCON-URI of the newly created conference in the 1022 "confObjID" parameter, in order to allow the conferencing client to 1023 manipulate that conference through following CCMP requests. In 1024 addition, the "confInfo" parameter transporting the created 1025 conference document MAY be included, at the discretion of the 1026 conferencing system implementation, along with an optional version 1027 parameter initialized at "1", since at creation time the conference 1028 object is at its first version. 1030 In the case of a confRequest with a "retrieve" operation, the 1031 "confObjID" representing the XCON-URI of the target conference MUST 1032 be included and the "confInfo" parameter MUST NOT be included in the 1033 request. The conferencing server MUST ignore any "confInfo" 1034 parameter that is received in a confRequest/retrieve. If the 1035 confResponse for the "retrieve" operation contains a "response-code" 1036 of "200", the "confInfo" parameter MUST be included in the response. 1037 The "confInfo" parameter MUST contain the entire conference document 1038 describing the target conference object in its current state. The 1039 current state of the retrieved conference object MUST also be 1040 reported in the proper "version" response parameter. 1042 In case of a confRequest with an "update" operation, the "confInfo" 1043 and "confObjID" MUST be included in the request. The "confInfo" 1044 represents an object of type "conference-type" containing all the 1045 changes to be applied to the conference whose identifier is 1046 "confObjID". Note that, in such a case, though the confInfo 1047 parameter has indeed to follow the rules indicated in the XCON data 1048 model, it does not represent the entire updated version of the target 1049 conference, since it rather conveys just the modifications to apply 1050 to that conference. For example, in order to change the conference 1051 title, the confInfo parameter will be of the form: 1053 1054 1055 *** NEW CONFERENCE TITLE *** 1056 1057 1058 Figure 7: Updating a conference object: modifying the title of a 1059 conference 1061 Similarly, to remove the title of an existing conference, a 1062 confRequest/update carrying the following "confInfo" parameter would 1063 do the job.: 1065 1066 1067 1068 1069 1071 Figure 8: Updating a conference object: removing the title of a 1072 conference 1074 In the case of a confResponse/update with a response-code of "200", 1075 no additional information is required in the response message, which 1076 means the return of confInfo parameter is not mandatory. A following 1077 confRequest/retrieve transaction might provide the CCMP client with 1078 the current aspect of the conference upon the modification, or the 1079 Notification Protocol might address that task as well. A "200" 1080 response-code indicates that the referenced conference document has 1081 been changed accordingly to the request by the conferencing server. 1082 The "version" parameter MUST be enclosed in the confResponse/update 1083 message, in order to let the client understand what is the actual 1084 current conference-object version, upon the applied modifications. 1085 An "409" response-code indicates that the changes reflected in the 1086 request "confInfo" are not feasible. This could be due to policies, 1087 requestor roles, specific privileges, unacceptable values etc., with 1088 the reason specific to a conferencing system and its configuration. 1089 Together with the "409" response-code, the "version" parameter MUST 1090 be attached in the confResponse/update, by this way allowing the 1091 client to eventually retrieve the current version of the target 1092 conference if the one she attempted to modify was not the most up-to- 1093 date. 1095 In the case of a confRequest with a "delete" operation, the 1096 "confObjID" representing the XCON-URI of the target conference MUST 1097 be included while the "confInfo" MUST NOT be included in the request. 1098 The conferencing server MUST ignore any "confInfo" parameter that is 1099 received within such a request. The confResponse MUST contain the 1100 same "confObjID" that was included in the confRequest. If the 1101 confResponse/delete operation contains a "200" response-code, the 1102 conference indicated in the "confObjID" has been successfully 1103 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1104 parameter. The "version" parameter SHOULD NOT be returned in any 1105 confResponse/delete. If the conferencing server cannot delete the 1106 conference referenced by the "confObjID" received in the confRequest 1107 because it is the parent of another conference object that is in use, 1108 the conferencing server MUST return a response-code of "425". 1110 A confRequest with an "operation" of "retrieve", "update" or "delete" 1111 carrying a "confObjID" which is not associated with one of the 1112 conferences (active or registered) the system is holding will 1113 generate, on the server's side, a confResponse message containing a 1114 "404" error code. This holds also for the case in which the 1115 mentioned "confObjID" is related to an existing conference object 1116 stored at the server, but associated with a blueprint or with a 1117 sidebar rather than an actual conference. 1119 The schema for the confRequest/confResponse pair is shown in 1120 Figure 9. 1122 1124 1125 1126 1127 1128 1129 1130 1131 1132 1134 1136 1138 1139 1140 1142 1144 1145 1146 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1159 1161 1163 1164 1165 1167 1169 1170 1171 1173 Figure 9: Structure of the confRequest and confResponse messages 1175 5.3.5. usersRequest and usersResponse 1177 Through a "usersRequest" message the CCMP client manipulates the XML 1178 element of the conference document associated with the 1179 conference identified by the "confObjID" parameter complusory 1180 included in the request. Inside the element, along with the 1181 list of elements associated with conference participants, 1182 there is information that the client may be interested in 1183 controlling, such the list of the users to which access to the 1184 conference is allowed/denied, conference participation policies, 1185 etc.; for this reason, a customized message has been designed to 1186 allow for the manipulation of this specific part of a conference 1187 document. 1189 A "usersInfo" parameter MAY be included in a usersRequest message 1190 depending upon the operation. If the "usersInfo" parameter is 1191 included in the usersRequest message, the parameter MUST be compliant 1192 with the field of the XCON data model. 1194 Two operations are allowed for a "usersRequest" message: 1196 1. "retrieve": In this case the request MUST NOT include a 1197 "usersInfo" parameter, while the successful response MUST contain 1198 the desired element in the "usersInfo" parameter. The 1199 conference server MUST ignore a "usersInfo" parameter if it is 1200 received in a request with a "retrieve" operation. 1201 2. update: In this case, the "usersInfo" parameter MUST contain the 1202 modifications to be applied to the referred element. If 1203 the "response-code" is "200", then the "usersInfo" parameter 1204 SHOULD NOT be returned. Any "usersInfo" parameter that is 1205 returned SHOULD be ignored. A "response-code" of "426" indicates 1206 that the conferencing client is not allowed to make the changes 1207 reflected in the "usersInfo" contained in the usersRequest 1208 message. This could be due to policies, roles, specific 1209 privileges, etc., with the reason specific to a conferencing 1210 system and its configuration. 1212 Operations of "create" and "delete" are not applicable to a 1213 usersRequest message and MUST NOT be considered by the server, which 1214 means that a "response-code" of "403" MUST be included in the 1215 usersResponse message. 1217 1219 1220 1221 1222 1223 1224 1225 1226 1227 1229 1231 1233 1234 1235 1237 1239 1240 1242 1244 1246 1247 1248 1249 1250 1251 1252 1253 1254 1256 1258 1260 1261 1262 1264 1266 1267 1268 1270 Figure 10: Structure of the usersRequest and usersResponse messages 1272 5.3.6. userRequest and userResponse 1274 A "userRequest" message is used to manipulate elements inside 1275 a conference document associated with a conference identified by the 1276 "confObjID" parameter. Besides retrieving information about a 1277 specific conference user, the message is used to request that the 1278 conference server either create, modify, or delete information about 1279 a user. A "userRequest" message MUST include the "confObjID", the 1280 "operation" parameter, and MAY include a "userInfo" parameter 1281 containing the detailed user's information depending upon the 1282 operation and whether the "userInfo" has already been populated for a 1283 specific user. Note that a user may not necessarily be a 1284 conferencing control client (i.e., some participants in a conference 1285 are not "XCON aware"). 1287 An XCON-USERID SHOULD be assigned to each and every user subscribed 1288 to the system. In such a way, a user who is not a conference 1289 participant can make requests (provided she has successfully passed 1290 AAA checks), like creating a conference, retrieving conference 1291 information, etc.. 1293 Conference users can be created in a number of different ways. In 1294 each of these cases the operation MUST be set to "create" in the 1295 userRequest message. Each of the userResponse messages for these 1296 cases MUST include the "confObjID", "confUserID", "operation" and 1297 "response-code" parameters. In the case of a response code of "200", 1298 the userResponse message MAY include the "userInfo" parameter 1299 depending upon the manner in which the user was created: 1301 o Conferencing client with an XCON-USERID adds itself to the 1302 conference: In this case, the "userInfo" parameter MAY be included 1303 in the userRequest. The "userInfo" parameter MUST contain a 1304 element (compliant with the XCON data model) and the 1305 "entity" attribute MUST be set to a value which represents the 1306 XCON-USERID of the user initiating the request. No additional 1307 parameters beyond those previously described are required in the 1308 userResponse message, in the case of a "response-code" of "200". 1309 o Conferencing client acts on behalf of a third user whose XCON- 1310 USERID is known: in this case, the "userInfo" parameter MUST be 1311 included in the userRequest. The "userInfo" parameter MUST 1312 contain a element and the "entity" attribute value MUST be 1313 set to the XCON-USERID of the third user in question. No 1314 additional parameters beyond those previously described are 1315 required in the userResponse message, in the case of a "response- 1316 code" of "200". 1317 o A conferencing client who has no XCON-USERID and who wants to 1318 enter, via CCMP, a conference whose identifier is known. In such 1319 case, a side-effect of the request is that the user is provided 1320 with a new XCON-USERID (created by the server) carried inside the 1321 "confUserID" parameter of the response. This is the only case in 1322 which a CCMP request can be valid though carrying a void 1323 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1324 in the request, providing at least a contact URI of the joining 1325 client, in order to let the focus instigate the signaling phase 1326 needed to add her to the conference. The mandatory "entity" 1327 attribute of the "userInfo" parameter in the request is filled 1328 with a dummy value recognizable on the server side, so to conform 1329 to the rules contained in the XCON data model XML schema. The 1330 involved messages (userRequest and userResponse) in such case 1331 should look like the following: 1333 Request fields: 1335 confUserID=null; 1336 confObjID=confXYZ; 1337 operation=create; 1338 userInfo= 1340 1341 1342 ... 1344 Response fields (in case of success): 1346 confUserID=user345; 1347 confObjID=confXYZ; 1348 operation=create; 1349 response-code=200; 1350 userInfo=null; //or the entire userInfo object 1352 Figure 11: userRequest and userResponse in the absence of an xcon- 1353 userid 1355 o Conferencing client is unaware of the XCON-USERID of a third user: 1356 In this case, the XCON-USERID in the request "confUserID" is the 1357 sender's one and the "entity" attribute of the attached userInfo 1358 is filled with the pre-defined fake value 1359 "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the 1360 third user MUST be returned to the client issuing the request in 1361 the "entity" attribute of the response "userInfo" parameter, if 1362 the "response-code" is "200". [RP] This scenario is intended to 1363 support both the case where a brand new conferencing system user 1364 is added to a conference by a third party (i.e. a user who is not 1365 yet provided with an XCON-USERID) and the case where the CCMP 1366 client issuing the request does not know the to-be-added user's 1367 XCON-USERID (which means such an identifier could already exist on 1368 the server's side for that user). In this last case, the 1369 conferencing server is in charge of avoiding XCON-URI duplicates 1370 for the same conferencing client, looking at key fields in the 1371 request provided "userInfo" parameter, such as the signalling URI: 1372 if the joining user is a brand new one, then the generation of a 1373 new XCON identifier is needed; otherwise, if that user is an 1374 existing one, the server must recover the corresponding XCON 1375 identifier. 1377 In the case of a userRequest with a "retrieve" operation, the 1378 "confObjID" representing the XCON-URI of the target conference MUST 1379 be included. The "confUserID", containing the CCMP client's xcon- 1380 userid, MUST also be included in the userRequest message. If the 1381 client wants to retrieve information about her profile in the 1382 specified conference, no "userInfo" parameter is needed in the 1383 retrieve request. On the other hand, if the client wants to obtain 1384 someone else's info within the given conference, she MUST include in 1385 the userRequest/retrieve a "userInfo" parameter whose "entity" 1386 attribute conveys the desired user's xcon-userid. If the 1387 userResponse for the "retrieve" operation contains a "response-code" 1388 of "200", the "userInfo" parameter MUST be included in the response. 1390 In case of a userRequest with an "update" operation, the "confObjID", 1391 "confUserID" and "userInfo" MUST be included in the request. The 1392 "userInfo" is of type "user-type" and contains all the changes to be 1393 applied to a specific element in the conference object 1394 identified by the "confObjID" in the userRequest message. The user 1395 to be modified is identified through the "entity" attribute of the 1396 "userInfo" parameter included in the request. In the case of a 1397 userResponse with a "response-code" of "200", no additional 1398 information is required in the "userResponse" message. A "response- 1399 code" of "200" indicates that the referenced user element has been 1400 updated by the conference server. A "response-code" of "426" 1401 indicates that the conferencing client is not allowed to make the 1402 changes reflected in the "userInfo" in the initial request. This 1403 could be due to policies, roles, specific privileges, etc., with the 1404 reason specific to a conferencing system and its configuration. 1406 In the case of a userRequest with a "delete" operation, the 1407 "confObjID" representing the XCON-URI of the target conference MUST 1408 be included. The "confUserID", containing the CCMP client's xcon- 1409 userid, MUST be included in the userRequest message. If the client 1410 wants to exit the specified conference, no "userInfo" parameter is 1411 needed in the delete request. On the other hand, if the client wants 1412 to remove another participant from the given conference, she MUST 1413 include in the userRequest/delete a "userInfo" parameter whose 1414 "entity" attribute conveys the xcon-userid of that participant. The 1415 userResponse MUST contain the same "confObjID" that was included in 1416 the userRequest. The userResponse MUST contain a "response-code" of 1417 "200" if the target element has been successfully deleted. If 1418 the userResponse for the "delete" operation contains a "response- 1419 code" of "200", the userResponse MUST NOT contain the "userInfo" 1420 parameter. 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1433 1435 1437 1438 1439 1441 1443 1444 1445 1447 1449 1450 1451 1452 1453 1454 1455 1456 1457 1459 1461 1463 1464 1465 1467 1469 1470 1472 1474 Figure 12: Structure of the userRequest and userResponse messages 1476 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1478 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1479 on the field of the conference object represented 1480 by the "confObjID". The "sidebarsByValRequest" message is of a 1481 "retrieve-only" type, so an "operation" parameter MUST NOT be 1482 included in a "sidebarsByValRequest" message. As with blueprints and 1483 conferences, also with sidebars, CCMP allows for the use of xpath 1484 filters whenever a selected subset of the sidebars available at the 1485 server's side has to be retrieved by the client. This applies both 1486 to sidebars by reference and to sidebars by value. A 1487 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1488 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1490 the client a "version" element related to the current version of the 1491 main conference object (i.e. the one whose identifier is contained in 1492 the "confObjId" field of the request) to which the sidebars in 1493 question are associated. The "sidebarsByValInfo" parameter contains 1494 the list of the conference objects associated with the sidebars by 1495 value derived from the main conference. The retrieved sidebars can 1496 then be updated or deleted using the "sidebarByValRequest" message, 1497 which is described in Section 5.3.8. 1499 1501 1502 1503 1504 1505 1506 1507 1508 1509 1511 1513 1516 1517 1518 1519 1521 1522 1523 1525 1527 1528 1529 1530 1531 1532 1533 1534 1535 1537 1539 1542 1543 1544 1546 1548 1549 1550 1552 Figure 13: Structure of the sidebarsByValRequest and 1553 sidebarsByValResponse messages 1555 5.3.8. sidebarByValRequest and sidebarByValResponse 1557 A sidebarByValRequest message MUST contain the "operation" parameter 1558 which discriminates among retrieval, creation, modification and 1559 deletion of a specific sidebar. The other required parameters depend 1560 upon the type of operation. 1562 In the case of a "create" operation, the "confObjID" parameter MUST 1563 be included in the sidebyValRequest message. In this case, the 1564 "confObjID" parameter contains the XCON-URI of the main conference in 1565 which the sidebar has to be created. If no "sidebarByValInfo" 1566 parameter is included, as envisaged in the XCON framework 1567 ([RFC5239]), the sidebar is created by cloning the main conference, 1568 following the implementation specific cloning rules. Otherwise, 1569 similarly to the case of direct creation, the sidebar conference 1570 object is built on the basis of the "sidebarByValInfo" parameter 1571 provided by the requestor. As a consequence of a sidebar-by-val 1572 creation, the conference server MUST update the main conference 1573 object reflected by the "confObjID" parameter in the 1574 sidebarbyValRequest/create message introducing the new sidebar object 1575 as a new new in the proper section . The 1576 newly created sidebar conference object MAY be included in the 1577 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1578 "response-code" is "200". The XCON-URI of the newly created sidebar 1579 MUST appear in the "confObjID" parameter of the response. The 1580 conference server can notify any conferencing clients that have 1581 subscribed to the conference event package, and are authorized to 1582 receive the notifications, of the addition of the sidebar to the 1583 conference. 1585 In the case of a "sidebarByVal" request with an operation of 1586 "retrieve", the URI for the conference object created for the sidebar 1587 (received in the response to a "create" operation or in a 1588 sidebarsByValResponse message) MUST be included in the "confObjID" 1589 parameter in the request. This "retrieve" operation is handled by 1590 the conference server in the same manner as a "retrieve" operation 1591 included in a confRequest message as detailed in Section 5.3.4. 1593 In the case of a "sidebarByVal" request with an operation of 1594 "update", the "sidebarByValInfo" MUST also be included in the 1595 request. The "confObjID" parameter contained in the request message 1596 identifies the specific sidebar instance to be updated. An "update" 1597 operation on the "sidebarByValInfo" is handled by the conference 1598 server in the same manner as an "update" operation on the confInfo 1599 included in a confRequest message as detailed in Section 5.3.4. A 1600 "sidebarByValResponse" message MUST carry back to the client a 1601 "version" element related to the current version of the sidebar whose 1602 identifier is contained in the "confObjId" field of the request. 1604 If an "operation" of "delete" is included in the sidebarByVal 1605 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1606 request. Any "sidebarByValInfo" included in the request MUST be 1607 ignored by the conference server. The URI for the conference object 1608 associated with the sidebar MUST be included in the "confObjID" 1609 parameter in the request. If the specific conferencing user as 1610 reflected by the "confUserID" in the request is authorized to delete 1611 the conference, the conference server deletes the conference object 1612 reflected by the "confObjID" parameter and updates the data in the 1613 conference object from which the sidebar was cloned. The conference 1614 server can notify any conferencing clients that have subscribed to 1615 the conference event package, and are authorized to receive the 1616 notifications, of the deletion of the sidebar to the conference. 1618 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1619 or "delete" carries a "confObjID" which is not associated with any 1620 existing sidebar-by-val, a confResponse message containing a "404" 1621 error code will be generated on the server's side. This holds also 1622 for the case in which the mentioned "confObjID" is related to an 1623 existing conference object stored at the server, but associated with 1624 a blueprint or with an actual conference or with a sidebar-by-ref 1625 rather than a sidebar-by-val. 1627 1629 1630 1631 1632 1633 1634 1635 1636 1637 1639 1641 1644 1645 1646 1648 1650 1651 1652 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1665 1667 1670 1671 1672 1674 1676 1677 1678 1680 Figure 14: Structure of the sidebarByValRequest and 1681 sidebarByValResponse messages 1683 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1685 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1686 invoked to retrieve the element of the conference 1687 object identified by the "confObjID" parameter. The 1688 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1689 "operation" parameter MUST NOT be included in a 1690 "sidebarsByRefRequest" message. In the case of a "response-code" of 1691 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1693 response. The element represents the set of URIs 1694 of the sidebars associated with the main conference, whose 1695 description (in the form of a standard XCON conference document) is 1696 external to the main conference itself. Through the retrieved URIs, 1697 it is then possible to access single sidebars using the 1698 "sidebarByRef" request message, described in Section 5.3.10. A 1699 "sidebarsByRefResponse" message MUST carry back to the client a 1700 "version" element related to the current version of the main 1701 conference object (i.e. the one whose identifier is contained in the 1702 "confObjId" field of the request) to which the sidebars in question 1703 are associated. 1705 1707 1708 1709 1710 1711 1712 1713 1714 1715 1717 1719 1722 1723 1724 1725 1727 1728 1729 1731 1733 1734 1735 1736 1737 1738 1739 1740 1741 1743 1745 1748 1749 1750 1752 1754 1755 1756 1758 Figure 15: Structure of the sidebarsByRefRequest and 1759 sidebarsByRefResponse messages 1761 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1763 A sidebarByRefRequest message MUST contain the "operation" parameter 1764 which discriminates among retrieval, creation, modification and 1765 deletion of a specific sidebar. The other required parameters depend 1766 upon the type of operation. 1768 In the case of a "create" operation, the "confObjID" parameter MUST 1769 be included in the sidebyRefRequest message. In this case, the 1770 "confObjID" parameter contains the XCON-URI of the main conference in 1771 which the sidebar has to be created. If no "sidebarByRefInfo" 1772 parameter is included, as envisaged in the XCON framework 1773 ([RFC5239]), the sidebar is created by cloning the main conference, 1774 following the implementation specific cloning rules. Otherwise, 1775 similarly to the case of direct creation, the sidebar conference 1776 object is built on the basis of the "sidebarByRefInfo" parameter 1777 provided by the requestor. If the creation of the sidebar is 1778 successful, the conference server MUST update the "sidebars-by-ref" 1779 element in the conference object from which the sidebar was created 1780 (i.e., as identified by the "confObjID" in the original sidebarByRef 1781 request), with the URI of the newly created sidebar. The newly 1782 created conference object MAY be included in the response in the 1783 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1784 URI for the conference object associated with the newly created 1785 sidebar object MUST appear in the "confObjID" parameter of the 1786 response. The conference server can notify any conferencing clients 1787 that have subscribed to the conference event package, and are 1788 authorized to receive the notifications, of the addition of the 1789 sidebar to the conference. 1791 In the case of a "sidebarByRef" request with an operation of 1792 "retrieve", the URI for the conference object created for the sidebar 1793 MUST be included in the "confObjID" parameter in the request. A 1794 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1795 conference server in the same manner as a "retrieve" operation on the 1796 confInfo included in a confRequest message as detailed in 1797 Section 5.3.4. 1799 In the case of a "sidebarByRef" request with an operation of 1800 "update", the URI for the conference object created for the sidebar 1801 MUST be included in the "confObjID" parameter in the request. The 1802 "sidebarByRefInfo" MUST also be included in the request in the case 1803 of an "operation" of "update". An "update" operation on the 1804 "sidebarByRefInfo" is handled by the conference server in the same 1805 manner as an "update" operation on the confInfo included in a 1806 confRequest message as detailed in Section 5.3.4. A 1807 "sidebarByRefResponse" message MUST carry back to the client a 1808 "version" element related to the current version of the sidebar whose 1809 identifier is contained in the "confObjId" field of the request. 1811 If an "operation" of "delete" is included in the sidebarByRef 1812 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1813 request. Any "sidebarByRefInfo" included in the request MUST be 1814 ignored by the conference server. The URI for the conference object 1815 for the sidebar MUST be included in the "confObjID" parameter in the 1816 request. If the specific conferencing user as reflected by the 1817 "confUserID" in the request is authorized to delete the conference, 1818 the conference server SHOULD delete the conference object reflected 1819 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1820 element in the conference object from which the sidebar was 1821 originally cloned. The conference server can notify any conferencing 1822 clients that have subscribed to the conference event package, and are 1823 authorized to receive the notifications, of the deletion of the 1824 sidebar. 1826 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1827 or "delete" carries a "confObjID" which is not associated with any 1828 existing sidebar-by-ref, a confResponse message containing a "404" 1829 error code will be generated on the server's side. This holds also 1830 for the case in which the mentioned "confObjID" is related to an 1831 existing conference object stored at the server, but associated with 1832 a blueprint or with an actual conference or with a sidebar-by-val 1833 rather than a sidebar-by-ref. 1835 1837 1838 1839 1840 1841 1842 1843 1844 1845 1847 1849 1852 1853 1854 1856 1858 1859 1860 1862 1864 1865 1866 1867 1868 1869 1870 1871 1872 1874 1876 1879 1880 1881 1883 1885 1886 1887 1888 Figure 16: Structure of the sidebarByRefRequest and 1889 sidebarByRefResponse messages 1891 5.3.11. extendedRequest and extendedResponse 1893 In order to facilitate the possibility of specifying new request/ 1894 response pairs for conference control, CCMP makes available the 1895 "extendedRequest" and "extendedResponse" messages. Such messages 1896 constitute a CCMP skeleton in which implementors can transport the 1897 information needed to realize conference control mechanisms not 1898 explicitly envisioned in the CCMP specification; these mechanisms are 1899 called, in this context, "extensions". Each extension is assumed to 1900 be characterized by an appropriate name that MUST be carried in the 1901 extendedRequest/extendedResponse pair in the provided 1902 field. Extension-specific information can be transported in the form 1903 of schema-defined XML elements inside the element present in 1904 both extendedRequest and extendedResponse. 1906 The conferencing client SHOULD be able to be informed about the 1907 extensions supported by a CCMP server and to recover the XML Schema 1908 defining the related specific elements by means of an optionsRequest/ 1909 optionsResponse CCMP transaction (see Section 5.3.12). 1911 The meaning of the common CCMP parameters inherited by the 1912 extendedRequest and extendedResponse from the basic CCMP request and 1913 response messages SHOULD be preserved and exploited appropriately 1914 while defining an extension. 1916 1918 1919 1920 1921 1922 1923 1924 1925 1926 1928 1930 1932 1933 1934 1935 1937 1938 1940 1942 1943 1944 1945 1946 1947 1948 1949 1950 1952 1954 1956 1957 1958 1959 1961 1962 1963 Figure 17: Structure of the extendedRequest and extendedResponse 1964 messages 1966 5.3.12. optionsRequest and optionsResponse 1968 An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. 1969 it does not represent a specialization of the general CCMP request. 1970 It allows a CCMP client to become aware of CCMP server capabilities 1971 in terms of CCMP supported messages. 1973 Indeed, the "optionsResponse" returns, in the appropriate 1974 field, information about both standard (i.e. IETF-defined) CCMP 1975 messages and extension messages the server is able to handle. 1976 Supported messages are listed into two separate groups, namely 1977 and . Such groups are 1978 represented, respectively, by a entry (for 1979 standard messages) and an entry (for extensions). 1980 In both cases, for each message the following information is 1981 provided: 1982 o (mandatory): in case of standard messages, it can be one of 1983 the ten standard message names defined in this document (i.e. 1984 "blueprintsRequest", "confsRequest", etc.). In case of 1985 extensions, this element MUST carry the same value of the 1986 inserted in the corresponding extendedRequest/ 1987 extendedResponse message pair 1988 o (optional): this field is a list of 1989 entries, each representing the CRUD operation supported by the 1990 server for the message. If this optional element is absent, the 1991 client SHOULD assume the server is able to handle the entire set 1992 of CRUD operations or, in case of standard messages, all the 1993 operations envisioned for that message in this document. 1994 o (optional): since all CCMP messages can potentially 1995 contain XML elements not envisioned in the CCMP schema (due to the 1996 presence of elements and attributes), a reference to a 1997 proper schema definition specifying such new elements/attributes 1998 can also be sent back to the clients by means of such field. If 1999 this element is absent, no new elements are introduced in the 2000 messages further than those explicitly defined in the CCMP 2001 specification. 2002 o (optional): human readable information about the 2003 related message 2005 The only parameter needed in the optionsRequest is the sender 2006 confUserID, which is mirrored in the homologous parameter of the 2007 corresponding optionsResponse. 2009 The MUST appear in the optionsResponse and 2010 MUST not be void, since a CCMP server MUST be able to handle at least 2011 one of the standard messages in at least one of the envisioned 2012 operations, i.e. the aforementioned list MUST carry at least one 2013 containing at least one element. 2015 2017 2018 2019 2020 2021 2023 2025 2026 2027 2028 2029 2030 2031 2032 2033 2035 2037 2040 2041 2042 2044 2046 2047 2048 2050 2052 2053 2054 2057 2059 2061 2062 2063 2065 2067 2068 2069 2070 2072 2073 2074 2076 2078 2079 2080 2081 2082 2083 2084 2086 2087 2088 2090 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2106 2108 2110 2111 2112 2114 2115 2116 2118 Figure 18: Structure of the optionsRequest and optionsResponse 2119 messages 2121 5.4. CCMP Response Codes 2123 All CCMP response messages MUST include a ""response-code"". The 2124 following summarizes the CCMP response codes: 2126 200 Success: Successful completion of the requested operation. 2127 400 Bad Request: Syntactically malformed request. 2128 401 Unauthorized: User not allowed to perform the required 2129 operation. 2130 403 Forbidden: Operation not allowed (e.g., cancellation of a 2131 blueprint). 2132 404 Object Not Found: Target conference object missing at the server 2133 (it refers to the "confObjID" parameter in the generic request 2134 message) 2135 409 Conflict: A generic error associated with all those situations 2136 in which a requested client operation cannot be successfully 2137 completed by the server. An example of such situation is when the 2138 modification of an object cannot be applied due to conflicts 2139 arising at the server's side, e.g. because the client version of 2140 the object is an obsolete one and the requested modifications 2141 collide with the up-to-date state of the object stored at the 2142 server. Such code would also be used if a client attempts to 2143 create an object (conference or user) with an entity that already 2144 exists. 2145 420 User Not Found: Target user missing at the server (it is related 2146 to the XCON-USERID in the "entity" attribute of the "userInfo" 2147 parameter when it is included in userRequests) 2148 421 Invalid confUserID: User missing at the server (this code is 2149 returned in the case of requests in which the "confUserID" of the 2150 sender is invalid). 2152 422 Invalid Conference Password: Target conference object's password 2153 contained in the request is wrong. 2154 423 Conference Password Required: "conference-password" missing in a 2155 request to access a password-protected conference object. 2156 424 Authentication Required: User's authentication information is 2157 missing or invalid. 2158 425 Forbidden Delete Parent: Cancel operation failed since the 2159 target object is a parent of child objects which depend on it, or 2160 because it effects, based on the "parent-enforceable" mechanism, 2161 the corresponding element in a child object. 2162 426 Forbidden Change Protected: Update refused by the server because 2163 the target element cannot be modified due to its implicit 2164 dependence on the value of a parent object ("parent-enforceable" 2165 mechanism). 2166 500 Server Internal Error: The server cannot complete the required 2167 service due to a system internal error. 2168 501 Not Implemented: Operation envisaged in the protocol, but not 2169 implemented in the contacted server. 2170 510 Request Timeout: The time required to serve the request has 2171 exceeded the envisaged service threshold. 2172 511 Resources Not Available: This code is used when the CCMP server 2173 cannot execute a command because of resource issues, e.g. it 2174 cannot create a sub conference because the system has reached its 2175 limits on the number of sub conferences, or if a request for 2176 adding a new user fails because the max number of users has been 2177 reached for the conference or the max number of users has been 2178 reached for the conferencing system. 2180 The handling of a "response-code" of "404", "409", "420", "421", 2181 "425" and "426" are only applicable to specific operations for 2182 specialized message responses and the details are provided in 2183 Section 5.3. The following table summarizes these response codes and 2184 the specialized message and operation to which they are applicable: 2186 +---------------+------------+------------+------------+------------+ 2187 | Response code | Create | Retrieve | Update | Delete | 2188 +---------------+------------+------------+------------+------------+ 2189 | 404 | userReques | All | All update | All delete | 2190 | | t, | retrieve | requests | requests | 2191 | | sidebarBy | requests, | | | 2192 | | ValRequest | EXCEPT: | | | 2193 | | sidebars | blueprints | | | 2194 | | ByRefReque | Request, | | | 2195 | | st | confsRequ | | | 2196 | | | est | | | 2197 | ------------- | ---------- | ---------- | ---------- | ---------- | 2198 | 409 | N/A | N/A | All update | N/A | 2199 | | | | requests | | 2200 | ------------- | ---------- | ---------- | ---------- | ---------- | 2201 | 420 | userReques | userReques | userReques | userReques | 2202 | | t(3rd part | t | t | t | 2203 | | yinvite | | | | 2204 | | with thir | | | | 2205 | | duser | | | | 2206 | | entity) | | | | 2207 | | (*) | | | | 2208 | ------------- | ---------- | ---------- | ---------- | ---------- | 2209 | 421 | All create | All | All update | All delete | 2210 | | requests, | retrieve | requests | requests | 2211 | | EXCEPT: | requests | | | 2212 | | userReques | | | | 2213 | | twith no | | | | 2214 | | confUserI | | | | 2215 | | D(**) | | | | 2216 | ------------- | ---------- | ---------- | ---------- | ---------- | 2217 | 425 | N/A | N/A | N/A | All delete | 2218 | | | | | request | 2219 | ------------- | ---------- | ---------- | ---------- | ---------- | 2220 | 426 | N/A | N/A | All update | N/A | 2221 | | | | requests | | 2222 +---------------+------------+------------+------------+------------+ 2224 Table 2: Response codes and associated operations 2226 (*) "420" in answer to a "userRequest/create" operation: in the case 2227 of a third-party invite, this code can be returned if the 2228 "confUserID" (contained in the "entity" attribute of the "userInfo" 2229 parameter) of the user to be added is unknown. In the case above, if 2230 instead it is the "confUserID" of the sender of the request that is 2231 invalid, a "421" error code is returned to the client. 2233 (**) "421" is not sent in answers to "userRequest/create" messages 2234 having a "null" confUserID, since this case is associated with a user 2235 who is unaware of his own XCON-USERID, but wants to enter a known 2236 conference. 2238 In the case of a response code of "510", a conferencing client MAY 2239 re-attempt the request within a period of time that would be specific 2240 to a conference control client or conference control server. 2242 A response code of "400" indicates that the conference control client 2243 sent a malformed request, which is indicative of an error in the 2244 conference control client or in the conference control server. The 2245 handling is specific to the conference control client implementation 2246 (e.g., generate a log, display an error message, etc.). It is NOT 2247 RECOMMENDED that the client re-attempt the request in this case. 2249 Response codes such as "401" and "403" indicate the client does not 2250 have the appropriate permissions, or there is an error in the 2251 permissions: re-attempting the request would likely not succeed and 2252 thus it is NOT RECOMMENDED. 2254 Any unexpected or unknown "response-code" SHOULD be treated by the 2255 client in the same manner as a "500" "response-code", the handling of 2256 which is specific to the conference control client implementation. 2258 6. A complete example of the CCMP in action 2260 In this section a typical, not normative, scenario in which the CCMP 2261 comes into play is described, by showing the actual composition of 2262 the various CCMP messages. In the call flows of the example, the 2263 Conference Control Client is a CCMP-enabled client, whereas the 2264 Conference Control Server is a CCMP-enabled server. The "confUserID" 2265 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2266 in all requests. The sequence of operations is as follows: 2268 1. Alice retrieves from the server the list of available blueprints 2269 (Section 6.1); 2270 2. Alice asks for detailed information about a specific blueprint 2271 (Section 6.2); 2272 3. Alice decides to create a new conference by cloning the retrieved 2273 blueprint (Section 6.3); 2274 4. Alice modifies information (e.g. XCON-URI, name, description) 2275 associated with the newly created blueprint (Section 6.4); 2276 5. Alice specifies a list of users to be contacted when the 2277 conference is activated (Section 6.5); 2278 6. Alice joins the conference (Section 6.6); 2279 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2280 "xcon-userid:Ciccio@example.com") join the conference 2281 (Section 6.7). 2282 8. Alice asks for the CCMP server capabilities (Section 6.8); 2283 9. Alice exploits an extension of the CCMP server (Section 6.9). 2285 Note, the examples do not include any details beyond the basic 2286 operation. 2288 In the following sections we deal with each of the above mentioned 2289 actions separately. 2291 6.1. Alice retrieves the available blueprints 2293 This section illustrates the transaction associated with retrieval of 2294 the blueprints, together with a dump of the two messages exchanged 2295 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2296 the figure, the "blueprintsResponse" message contains, in the 2297 "blueprintsInfo" parameter, information about the available 2298 blueprints, in the form of the standard XCON-URI of the blueprint, 2299 plus additional (and optional) information, like its display-text and 2300 purpose. 2302 Alice retrieves from the server the list of available blueprints: 2304 CCMP Client CCMP Server 2305 | | 2306 | CCMP blueprintsRequest message | 2307 | - confUserID: Alice | 2308 | - confObjID: (null) | 2309 |------------------------------------------------------>| 2310 | | 2311 | CMP blueprintsResponse message | 2312 | - confUserID: Alice | 2313 | - confObjID: (null) | 2314 | - response-code: 200 | 2315 | - blueprintsInfo: bp123,bp124,.. | 2316 |<------------------------------------------------------| 2317 | | 2318 . . 2319 . . 2321 1. blueprintsRequest message: 2323 2324 2327 2329 xcon-userid:Alice@example.com 2330 2331 2333 2. blueprintsResponse message form the server: 2335 2336 2340 2343 xcon-userid:Alice@example.com 2344 200 2345 2346 2347 2348 xcon:AudioRoom@example.com 2349 AudioRoom 2350 Simple Room: 2351 conference room with public access, 2352 where only audio is available, more users 2353 can talk at the same time 2354 and the requests for the AudioFloor 2355 are automatically accepted. 2356 2357 2358 2359 xcon:VideoRoom@example.com 2360 VideoRoom 2361 Video Room: 2362 conference room with public access, 2363 where both audio and video are available, 2364 8 users can talk and be seen at the same time, 2365 and the floor requests are automatically accepted. 2366 2367 2368 2369 xcon:AudioConference1@example.com 2370 AudioConference1 2371 Public Audio Conference: 2373 conference with public access, 2374 where only audio is available, 2375 only one user can talk at the same time, 2376 and the requests for the AudioFloor MUST 2377 be accepted by a Chair. 2378 2379 2380 2381 xcon:VideoConference1@example.com 2382 VideoConference1 2383 Public Video Conference: conference 2384 where both audio and video are available, 2385 only one user can talk 2386 2387 2388 2389 xcon:AudioConference2@example.com 2390 AudioConference2 2391 Basic Audio Conference: 2392 conference with private access, 2393 where only audio is available, 2394 only one user can talk at the same time, 2395 and the requests for the AudioFloor MUST 2396 be accepted by a Chair. 2397 2398 2399 2400 2401 2402 2404 Figure 19: Getting blueprints from the server 2406 6.2. Alice gets detailed information about a specific blueprint 2408 This section illustrates the second transaction in the overall flow. 2409 In this case, Alice, who now knows the XCON-URIs of the blueprints 2410 available at the server, makes a drill-down query, in the form of a 2411 CCMP "blueprintRequest" message, to get detailed information about 2412 one of them (the one called with XCON-URI 2413 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2414 Notice that the response contains, in the "blueprintInfo" parameter, 2415 a document compliant with the standard XCON data model. 2417 Alice retrieves detailed information about a specified blueprint: 2419 CCMP Client CCMP Server 2420 | | 2421 | CCMP blueprintRequest message | 2422 | - confUserID: Alice | 2423 | - confObjID: bp123 | 2424 | - operation: retrieve | 2425 | - blueprintInfo: (null) | 2426 |------------------------------------------------------>| 2427 | | 2428 | CCMP blueprintResponse message | 2429 | - confUserID: Alice | 2430 | - confObjID: bp123 | 2431 | - operation: retrieve | 2432 | - response-code: 200 | 2433 | - blueprintInfo: bp123Info | 2434 |<------------------------------------------------------| 2435 | | 2436 . . 2437 . . 2439 1. blueprintRequest message: 2441 2442 2446 2448 xcon-userid:Alice@example.com 2449 xcon:AudioRoom@example.com 2450 retrieve 2451 2452 2453 2455 2. blueprintResponse message form the server: 2457 2458 2462 2464 xcon-userid:Alice@example.com 2465 xcon:AudioRoom@example.com 2466 retrieve 2467 200 2468 2469 2470 2471 AudioRoom 2472 2 2473 2474 2475 audio 2476 2477 2478 2479 2480 allow 2481 2482 2483 confirm 2484 2485 2486 2487 2488 2489 2490 2491 2492 2494 Figure 20: Getting info about a specific blueprint 2496 6.3. Alice creates a new conference through a cloning operation 2498 This section illustrates the third transaction in the overall flow. 2499 Alice decides to create a new conference by cloning the blueprint 2500 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2501 retrieved detailed information through the "blueprintRequest" 2502 message. This is achieved by sending a "confRequest/create" message 2503 having the blueprint's URI in the "confObjID" parameter. The picture 2504 shows such transaction. Notice that the response contains, in the 2505 "confInfo" parameter, the document associated with the newly created 2506 conference, which is compliant with the standard XCON data model. 2507 The "confObjID" in the response is set to the XCON-URI of the new 2508 conference (in this case, "xcon:8977794@example.com"). We also 2509 notice that this value is equal to the value of the "entity" 2510 attribute of the element of the document 2511 representing the newly created conference object. 2513 Alice creates a new conference by cloning the 2514 "xcon:AudioRoom@example.com" blueprint: 2516 CCMP Client CCMP Server 2517 | | 2518 | CCMP confRequest message | 2519 | - confUserID: Alice | 2520 | - confObjID: AudioRoom | 2521 | - operation: create | 2522 | - confInfo: (null) | 2523 |------------------------------------------------------>| 2524 | | 2525 | CCMP confResponse message | 2526 | - confUserID: Alice | 2527 | - confObjID: newConfId | 2528 | - operation: create | 2529 | - response-code: 200 | 2530 | - version: 1 | 2531 | - confInfo: newConfInfo | 2532 |<------------------------------------------------------| 2533 | | 2534 . . 2535 . . 2537 1. confRequest message: 2539 2540 2544 2547 xcon-userid:Alice@example.com 2548 xcon:AudioRoom@example.com 2549 create 2550 2551 2552 2554 2. confResponse message from the server: 2556 2557 2561 2564 xcon-userid:Alice@example.com 2565 xcon:8977794@example.com 2566 create 2567 200 2568 1 2569 2570 2571 2572 2573 New conference by Alice cloned from AudioRoom 2574 2575 2576 2577 2578 xcon:8977794@example.com 2579 2580 2581 conference xcon-uri 2582 2583 2584 2585 10 2586 2587 2588 audio 2589 2590 2591 2592 2593 allow 2594 2595 2596 2597 confirm 2598 2599 2600 2601 2602 2603 2604 2606 2608 Figure 21: Creating a new conference by cloning a blueprint 2610 6.4. Alice updates conference information 2612 This section illustrates the fourth transaction in the overall flow. 2613 Alice decides to modify some of the details associated with the 2614 conference she just created. More precisely, she changes the 2615 element under the element of 2616 the document representing the conference. This is achieved through a 2617 "confRequest/update" message carrying the fragment of the conference 2618 document to which the required changes have to be applied. As shown 2619 in the picture, the response contains a code of "200", which 2620 acknowledges the modifications requested by the client, while also 2621 updating the conference version number from 1 to 2, as reflected in 2622 the "version" parameter. 2624 Alice updates information about the conference she just created: 2626 CCMP Client CCMP Server 2627 | | 2628 | CCMP confRequest message | 2629 | - confUserID: Alice | 2630 | - confObjID: 8977794 | 2631 | - operation: update | 2632 | - confInfo: confUpdates | 2633 |------------------------------------------------------>| 2634 | | 2635 | CCMP confResponse message | 2636 | - confUserID: Alice | 2637 | - confObjID: 8977794 | 2638 | - operation: update | 2639 | - response-code: 200 | 2640 | - version: 2 | 2641 | - confInfo: (null) | 2642 |<------------------------------------------------------| 2643 | | 2644 . . 2645 . . 2647 1. confRequest message: 2649 2650 2654 2657 xcon-userid:Alice@example.com 2658 xcon:8977794@example.com 2659 update 2660 2661 2662 2663 2664 Alice's conference 2665 2666 2667 2668 2669 2670 2672 2. confResponse message form the server: 2674 2675 2679 2681 xcon-userid:Alice@example.com 2682 xcon:8977794@example.com 2683 update 2684 200 2685 2 2686 2687 2688 2690 Figure 22: Updating conference information 2692 6.5. Alice inserts a list of users in the conference object 2694 This section illustrates the fifth transaction in the overall flow. 2695 Alice modifies the under the element in 2696 the document associated with the conference she created. To the 2697 purpose, she exploits the "usersRequest" message provided by the 2698 CCMP. The picture below shows the transaction. 2700 Alice updates information about the list of users to whom access to 2701 the conference is permitted: 2703 CCMP Client CCMP Server 2704 | | 2705 | CCMP usersRequest message | 2706 | - confUserID: Alice | 2707 | - confObjID: 8977794 | 2708 | - operation: update | 2709 | - usersInfo: usersUpdates | 2710 |------------------------------------------------------>| 2711 | | 2712 | CCMP usersResponse message | 2713 | - confUserID: Alice | 2714 | - confObjID: 8977794 | 2715 | - operation: update | 2716 | - response-code: 200 | 2717 | - version: 3 | 2718 | - usersInfo: (null) | 2719 |<------------------------------------------------------| 2720 | | 2721 . . 2722 . . 2724 1. usersRequest message: 2726 2727 2731 2733 xcon-userid:Alice@example.com 2734 xcon:8977794@example.com 2735 update 2736 2737 2738 2739 2741 2743 2745 2746 2747 2748 2749 2751 2. usersResponse message form the server: 2753 2754 2758 2760 xcon-userid:Alice@example.com 2761 xcon:8977794@example.com 2762 update 2763 200 2764 3 2765 2766 2767 2769 Figure 23: Updating the list of allowed users for the conference 2770 'xcon:8977794@example.com' 2772 6.6. Alice joins the conference 2774 This section illustrates the sixth transaction in the overall flow. 2775 Alice uses the CCMP to add herself to the newly created conference. 2776 This is achieved through a "userRequest/create" message containing, 2777 in the "userInfo" parameter, a element compliant with the XCON 2778 data model representation. Notice that such element includes 2779 information about the user's Address of Records, as well as her 2780 current end-point. The picture below shows the transaction. Notice 2781 how the "confUserID" parameter is equal to the "entity" attribute of 2782 the element, which indicates that the request issued by 2783 the client is a first-party one. 2785 Alice joins the conference by issuing a "userRequest/create" message 2786 with her own id to the server: 2788 CCMP Client CCMP Server 2789 | | 2790 | CCMP userRequest message | 2791 | - confUserID: Alice | 2792 | - confObjID: 8977794 | 2793 | - operation: create | 2794 | - userInfo: AliceUserInfo | 2795 |------------------------------------------------------>| 2796 | | 2797 | CCMP userResponse message | 2798 | - confUserID: Alice | 2799 | - confObjID: 8977794 | 2800 | - operation: create | 2801 | - response-code: 200 | 2802 | - version: 4 | 2803 | - userInfo: (null) | 2804 |<------------------------------------------------------| 2805 | | 2806 . . 2807 . . 2809 1. userRequest message: 2811 2812 2816 2818 xcon-userid:Alice@example.com 2819 xcon:8977794@example.com 2820 create 2821 2822 2823 2824 2825 2826 mailto:Alice83@example.com 2827 2828 email 2830 2831 2832 2833 2834 2835 2836 2838 2. userResponse message form the server: 2840 2841 2845 2847 xcon-userid:Alice@example.com 2848 xcon:8977794@example.com 2849 create 2850 200 2851 4 2852 2853 2854 2856 Figure 24: Alice joins the conference through the CCMP 2858 6.7. Alice adds a new user to the conference 2860 This section illustrates the seventh and last transaction in the 2861 overall flow. Alice uses the CCMP to add a new conferencing system 2862 user, Ciccio, to the conference. This "third-party" request is 2863 realized through a "userRequest/create" message containing, in the 2864 "userInfo" parameter, a element compliant with the XCON data 2865 model representation. Notice that such element includes information 2866 about Ciccio's Address of Records, as well as his current end-point, 2867 but has a fake "entity" attribute, since it is unknown to Alice, in 2868 this example. Thus, the server is in charge of generating a new 2869 XCON-USERID for the user Alice indicates, and returning it in the 2870 "entity" attribute of the "userInfo" parameter carried in the 2871 response, as well as adding the user to the conference. The picture 2872 below shows the transaction. 2874 Alice adds user "Ciccio" to the conference by issuing a third-party 2875 "userRequest/create" message to the server: 2877 CCMP Client CCMP Server 2878 | | 2879 | CCMP userRequest message | 2880 | - confUserID: Alice | 2881 | - confObjID: 8977794 | 2882 | - operation: create | 2883 | - userInfo: CiccioUserInfo(with dummy "entity") | 2884 |------------------------------------------------------>| 2885 | | 2886 | CCMP optionsResponse message | 2887 | - confUserID: Alice | 2888 | - confObjID: 8977794 | 2889 | - operation: create | 2890 | - response-code: 200 | 2891 | - version: 5 | 2892 | - userInfo: CiccioUserInfo | 2893 | (with actual "entity") | 2894 |<------------------------------------------------------| 2895 | | 2896 . . 2897 . . 2899 1. "third party" userRequest message from Alice: 2901 2902 2906 2908 xcon-userid:Alice@example.com 2909 xcon:8977794@example.com 2910 create 2911 2912 2913 2914 2915 2916 mailto:Ciccio@example.com 2917 2918 email 2919 2920 2921 2922 2923 2924 2925 2927 2. "third party" userResponse message from the server: 2929 2930 2934 2936 xcon-userid:Alice@example.com 2937 xcon:8977794@example.com 2938 create 2939 200 2940 5 2941 2942 2943 2944 2945 2946 mailto:Ciccio@example.com 2947 2948 email 2949 2950 2951 2952 2953 2954 2955 2957 Figure 25: Alice adds a new user to the conference through the CCMP 2959 6.8. Alice asks for the CCMP server capabilities 2961 This section illustrates how Alice can discover which standard CCMP 2962 messages and what extensions are supported by the CCMP server she 2963 interacts with through an optionsRequest/optionsResponse transaction. 2965 To prepare the optionsRequest, Alice just puts her XCON-USERID in the 2966 confUserID parameter. Looking at the element in the 2967 received optionsResponse, Alice infers the following server 2968 capabilities as regards standard CCMP messages: 2969 o the server doesn't support neither sidebarsByValRequest nor 2970 sidebarByValRequest messages, since they do not appear in the 2971 ; 2972 o the only implemented operation for the blueprintRequest message is 2973 "retrieve", since no other entries are included in the 2974 related field. 2976 Besides, by analyzing the , Alice discovers 2977 the server implements an extension named "confSummaryRequest" 2978 allowing conferencing clients to recover via CCMP a brief description 2979 of a specific conference; the XML elements involved in this extended 2980 conference control transaction are available at the URL indicated in 2981 the element and the only operation envisioned for this 2982 extension is "retrieve". To better understand how Alice can exploit 2983 the "confSummaryRequest" extension via CCMP, see Section 6.9. 2985 The picture below shows the optionsRequest/optionsResponse message 2986 exchanging between Alice and the CCMP server. 2988 CCMP Client CCMP Server 2989 | | 2990 | CCMP optionsRequest message | 2991 | - confUserID: Alice | 2992 |------------------------------------------------------>| 2993 | | 2994 | CCMP userResponse message | 2995 | - confUserID: Alice | 2996 | - response-code: 200 | 2997 | - options (list of both | 2998 | standard and extended | 2999 | supported messages) | 3000 |<------------------------------------------------------| 3001 | | 3002 . . 3003 . . 3005 1. optionsRequest (Alice asks for CCMP server capabilities) 3007 3008 3012 3014 xcon-userid:Alice@example.com 3015 3016 3018 2. optionsResponse (the server returns the list of its conference 3019 control capabilities) 3021 3022 3025 3027 xcon-userid:Alice@example.com 3028 200 3029 success 3030 3031 3032 3033 3034 blueprintsRequest 3035 3036 3037 blueprintRequest 3038 3039 retrieve 3040 3041 3042 3043 confsRequest 3044 3045 confRequest 3046 3047 3048 usersRequest 3049 3050 3051 userRequest 3052 3053 3054 sidebarsByRefRequest 3055 3056 3057 sidebarByRefRequest 3058 3060 3061 3062 3063 confSummaryRequest 3064 3065 request 3066 3067 3068 http://example.com/ccmp-extension-schema.xsd 3069 3070 3071 confSummaryRequest is intented 3072 to allow the requestor to retrieve 3073 a brief description 3074 of the conference indicated in the 3075 confObjID request parameter 3076 3077 3078 3079 3080 3081 3082 3084 Figure 26: Alice asks for the server control capabilities 3086 6.9. Alice exploits a CCMP server extension 3088 In this section, a very simple example of CCMP extension support is 3089 provided. Alice can recover information about this and other server- 3090 supported extensions by issuing an optionsRequest (see Section 6.8). 3092 The extension in question is named "confSummaryRequest" and is 3093 conceived to allow a CCMP client to obtain from the CCMP server 3094 synthetic information about a specific conference. The conference 3095 summary is carried in the form of an XML element, , 3096 defined by the following XML schema: 3098 3099 3101 3103 3104 3105 3106 3107 3108 3109 3110 3112 element 3118 contains conference information related to: 3120 o title 3121 o status (active or registered) 3122 o participation modality (if everyone is allowed to participate, the 3123 boolean element is set to "true") 3124 o involved media 3126 In order to retrieve a conference summary related to the conference 3127 she participates in, Alice then sends to the CCMP server an 3128 extendedRequest with a "confSummaryRequest" , 3129 specifying the conference xcon-uri in the confObjID request 3130 parameter, as depicted in the figure below. 3132 CCMP Client CCMP Server 3133 | | 3134 | CCMP extendedRequest message | 3135 | - confUserID: Alice | 3136 | - confObjID: 8977794 | 3137 | - operation: retrieve | 3138 | - extensionName: confSummaryRequest | 3139 |------------------------------------------------------>| 3140 | | 3141 | CCMP extendedResponse message | 3142 | - confUserID: Alice | 3143 | - confObjID: 8977794 | 3144 | - operation: retrieve | 3145 | - response-code: 200 | 3146 | - extensionName: | 3147 | confSummaryRequest | 3148 | - confSummary | 3149 |<------------------------------------------------------| 3150 | | 3151 . . 3152 . . 3154 1. extendedRequest (Alice makes use of the "confSummaryRequest") 3156 3157 3161 3163 xcon-userid:Alice@example.com 3164 xcon:8977794@example.com 3165 retrieve 3166 3167 confRequestSummary 3168 3169 3170 3172 2. extendedResponse (the server provides Alice with a brief description 3173 of the desired conference) 3175 3176 3180 3182 xcon-userid:Alice@example.com 3183 xcon:8977794@example.com 3184 retrieve 3185 200 3186 success 3187 3188 confSummaryRequest 3189 3190 Alice's conference 3191 active 3192 true 3193 audio 3194 3195 3196 3197 3199 Figure 28: Alice exploits the 'confSummaryRequest' extension 3201 7. Locating a Conference Control Server 3203 If a conference control client is not pre-configured to use a 3204 specific conference control server for the requests, the client MUST 3205 first discover the conference control server before it can send any 3206 requests. The result of the discovery process, is the address of the 3207 server supporting conferencing. In this document, the result is an 3208 http: or https: URI, which identifies a conference server. 3210 This document proposes the use of DNS to locate the conferencing 3211 server. U-NAPTR resolution for conferencing takes a domain name as 3212 input and produces a URI that identifies the conferencing server. 3213 This process also requires an Application Service tag and an 3214 Application Protocol tag, which differentiate conferencing-related 3215 NAPTR records from other records for that domain. 3217 Section 12.4.1 defines an Application Service tag of "XCON", which is 3218 used to identify the centralized conferencing (XCON) server for a 3219 particular domain. The Application Protocol tag "CCMP", defined in 3220 Section 12.4.2, is used to identify an XCON server that understands 3221 the CCMP protocol. 3223 The NAPTR records in the following example Figure 29 demonstrate the 3224 use of the Application Service and Protocol tags. Iterative NAPTR 3225 resolution is used to delegate responsibility for the conferencing 3226 service from "zonea.example.com." and "zoneb.example.com." to 3227 "outsource.example.com.". 3229 zonea.example.com. 3230 ;; order pref flags 3231 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3232 "" ; regex 3233 outsource.example.com. ; replacement 3234 ) 3235 zoneb.example.com. 3236 ;; order pref flags 3237 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 3238 "" ; regex 3239 outsource.example.com. ; replacement 3240 ) 3241 outsource.example.com. 3242 ;; order pref flags 3243 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 3244 "!*.!https://confs.example.com/!" ; regex 3245 . ; replacement 3246 ) 3248 Figure 29: Sample XCON:CCMP Service NAPTR Records 3250 Details for the "XCON" Application Service tag and the "CCMP" 3251 Application Protocol tag are included in Section 12.4. 3253 8. Managing Notifications 3255 As per [RFC5239], the CCMP is one of the following four protocols 3256 which have been formally identified within the XCON framework: 3257 Conference Control Protocol: between Conference and Media Control 3258 Client and Conference Server. Such protocol is the subject of the 3259 present document. 3260 Binary floor Control Protocol: between the Floor Control Client and 3261 the Floor Control Server. Such protocol is the BFCP, specified in 3262 [RFC4582]. 3263 Call Signaling Protocol: between the Call Signaling Client and the 3264 Focus. Such protocol can be either SIP or any other call 3265 signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating 3266 a conferencing session. 3267 Notification Protocol: between the Notification Client and the XCON 3268 Notification Service. Such protocol has not been identified as 3269 yet. 3271 The CCMP protocol specified in this document is a pro-active one and 3272 is used by a conferencing client to send requests to a conferencing 3273 server in order to retrieve information about the conference objects 3274 it stores and potentially manipulate them. Though, it stands clear 3275 that a complete conferencing solution cannot refrain from providing 3276 clients with a means for receiving asynchronous updates about the 3277 status of the objects available at the server. The notification 3278 protocol to be adopted in XCON, while conceptually independent of all 3279 the mentioned companion protocols, can nonetheless be chosen in a way 3280 that is consistent with the overall protocol architecture 3281 characterizing a specific deployment, as it is discussed in the 3282 following. 3284 When the conference control client uses SIP [RFC3261] as the 3285 signaling protocol to participate in the conference, SIP event 3286 notification can be used. In such a case, the conference control 3287 client MUST implement the Conference event package for XCON 3288 [I-D.ietf-xcon-event-package]. This is the default mechanism for 3289 conferencing clients as is SIP for signaling per the XCON Framework 3290 [RFC5239]. 3292 In the case where the interface to the conference server is entirely 3293 web based, there is a common mechanism for web-based systems that 3294 could be used - a "call back". With this mechanism, the conference 3295 client provides the conference server with an HTTP URL which is 3296 invoked when a change occurs. This is a common implementation 3297 mechanism for e-commerce. This works well in the scenarios whereby 3298 the conferencing client is a web server that provides the graphical 3299 HTML user interface and uses CCMP as the backend interface to the 3300 conference server. And, this model can co-exist with the SIP event 3301 notification model. PC-based clients behind NATs could provide a SIP 3302 event URI, whereas web-based clients using CCMP in the backend would 3303 probably find the HTTP call back approach much easier. The details 3304 of this approach are out of scope for the CCMP per se, thus the 3305 expectation is that a future specification will document this 3306 solution. 3308 9. HTTP Transport 3310 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 3311 [RFC2818] as transport mechanisms for the CCMP protocol, which a 3312 conforming conference Server and Conferencing client MUST support. 3314 Although CCMP uses HTTP as a transport, it uses a strict subset of 3315 HTTP features, and due to the restrictions of some features, a 3316 conferencing server may not be a fully compliant HTTP server. It is 3317 intended that a conference server can easily be built using an HTTP 3318 server with extensibility mechanisms, and that a conferencing client 3319 can trivially use existing HTTP libraries. This subset of 3320 requirements helps implementors avoid ambiguity with the many options 3321 the full HTTP protocol offers. 3323 A conferencing client that conforms to this specification is not 3324 required to support HTTP authentication [RFC2617] or cookies 3325 [RFC2965]. These mechanism are unnecessary because CCMP requests 3326 carry their own authentication information (in the "subject" field; 3327 see Section 5.1). 3329 A CCMP request is carried in the body of an HTTP POST request. The 3330 conferencing client MUST include a Host header in the request. 3332 The MIME type of CCMP request and response bodies is "application/ 3333 ccmp+xml". The conference server and conferencing client MUST 3334 provide this value in the HTTP Content-Type and Accept header fields. 3335 If the conference server does not receive the appropriate Content- 3336 Type and Accept header fields, the conference server SHOULD fail the 3337 request, returning a 406 (not acceptable) response. CCMP responses 3338 SHOULD include a Content-Length header. 3340 Conferencing clients MUST NOT use the "Expect" header or the "Range" 3341 header in CCMP requests. The conference server MAY return 501 (not 3342 implemented) errors if either of these HTTP features are used. In 3343 the case that the conference server receives a request from the 3344 conferencing client containing a If-* (conditional) header, the 3345 conference server SHOULD return a 412 (precondition failed) response. 3347 The POST method is the only method REQUIRED for CCMP. If a 3348 conference server chooses to support GET or HEAD, it SHOULD consider 3349 the kind of application doing the GET. Since a conferencing client 3350 only uses a POST method, the GET or HEAD MUST be either an escaped 3351 URL (e.g., somebody found a URL in protocol traces or log files and 3352 fed it into their browser) or somebody doing testing/ debugging. The 3353 conference server could provide information in the CCMP response 3354 indicating that the URL corresponds to a conference server and only 3355 responds to CCMP POST requests or the conference server could instead 3356 try to avoid any leak of information by returning a very generic HTTP 3357 error message such as 405 (method not allowed). 3359 The conference server populates the HTTP headers of responses so that 3360 they are consistent with the contents of the message. In particular, 3361 the "CacheControl" header SHOULD be set to disable caching of any 3362 conference information by HTTP intermediaries. Otherwise, there is 3363 the risk of stale information and/or the unauthorized disclosure of 3364 the information. The HTTP status code MUST indicate a 2xx series 3365 response for all CCMP Response and Error messages. 3367 The conference server MAY redirect a CCMP request. A conferencing 3368 client MUST handle redirects, by using the Location header provided 3369 by the server in a 3xx response. When redirecting, the conferencing 3370 client MUST observe the delay indicated by the Retry-After header. 3372 The conferencing client MUST authenticate the server that returns the 3373 redirect response before following the redirect. A conferencing 3374 client SHOULD authenticate the conference server indicated in a 3375 redirect. 3377 The conference server SHOULD support persistent connections and 3378 request pipelining. If pipelining is not supported, the conference 3379 server MUST NOT allow persistent connections. The conference server 3380 MUST support termination of a response by the closing of a 3381 connection. 3383 Implementations of CCMP that implement HTTP transport MUST implement 3384 transport over TLS [RFC2818]. TLS provides message integrity and 3385 confidentiality between the conference control client and the 3386 conference control server. The conferencing client MUST implement 3387 the server authentication method described in HTTPS [RFC2818]. The 3388 device uses the URI obtained during conference server discovery to 3389 authenticate the server. The details of this authentication method 3390 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 3391 the conferencing client SHOULD fail a request if server 3392 authentication fails. 3394 10. Security Considerations 3396 As identified in the XCON framework [RFC5239], there are a wide 3397 variety of potential attacks related to conferencing, due to the 3398 natural involvement of multiple endpoints and the capability to 3399 manipulate the data on the conference server using CCMP. Examples of 3400 attacks include the following: an endpoint attempting to listen to 3401 conferences in which it is not authorized to participate, an endpoint 3402 attempting to disconnect or mute other users, and theft of service by 3403 an endpoint in attempting to create conferences it is not allowed to 3404 create. 3406 The following summarizes the security considerations for CCMP: 3407 1. The client MUST determine the proper conference server. The 3408 conference server discovery is described in Section 7. 3409 2. The client MUST connect to the proper conference server. The 3410 mechanisms for addressing this security consideration are 3411 described in Section 10.1. 3412 3. The protocol MUST support a confidentiality and integrity 3413 mechanism. As described in Section 9, implementations of CCMP 3414 MUST implement the HTTP transport over TLS [RFC2818]. 3415 4. There are security issues associated with the authorization to 3416 perform actions on the conferencing system to invoke specific 3417 capabilities. A conference server SHOULD ensure that only 3418 authorized entities can manipulate the conference data. The 3419 mechanisms for addressing this security consideration are 3420 described in Section 10.2. 3421 5. The privacy and security of the identity of a user in the 3422 conference MUST be assured. The mechanisms to ensure the 3423 security and privacy of identity are discussed in Section 10.3. 3424 6. A final issue is related to Denial of Service (DoS) attacks on 3425 the conferencing server itself. In order to minimize the 3426 potential for DoS attacks, it is RECOMMENDED that conferencing 3427 systems require user authentication and authorization for any 3428 client participating in a conference. This can be accomplished 3429 through the use of the mechanisms described in Section 10.2, as 3430 well as by using the security mechanisms associated with the 3431 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 3433 10.1. Assuring that the Proper Conferencing Server has been contacted 3435 When the CCMP transaction is conducted using TLS [RFC5246], the 3436 conference server can authenticate its identity, either as a domain 3437 name or as an IP address, to the conference client by presenting a 3438 certificate containing that identifier as a subjectAltName (i.e., as 3439 an iPAddress or dNSName, respectively). With the use of HTTP as a 3440 transport for CCMP, this is exactly the authentication described by 3441 TLS [RFC2818]. If the client has external information as to the 3442 expected identity or credentials of the proper conference server 3443 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 3444 implementation of CCMP MUST be capable of being transacted over TLS 3445 so that the client can request the above authentication, and a 3446 conference server implementation MUST include this feature. Note 3447 that in order for the presented certificate to be valid at the 3448 client, the client must be able to validate the certificate. In 3449 particular, the validation path of the certificate must end in one of 3450 the client's trust anchors, even if that trust anchor is the 3451 conference server certificate itself. 3453 10.2. User Authentication and Authorization 3455 Many policy authorization decisions are based on the identity of the 3456 user or the role that a user may have. The conferencing server MUST 3457 implement mechanisms for authentication of users to validate their 3458 identity. There are several ways that a user might authenticate its 3459 identity to the system. For users joining a conference using one of 3460 the call signaling protocols, the user authentication mechanisms for 3461 the specific protocol can be used. For the case of users joining the 3462 conference using the CCMP, TLS is RECOMMENDED. 3464 The XCON Framework [RFC5239] provides an overview of other 3465 authorization mechanisms. In the cases where a user is authorized 3466 via multiple mechanisms, it is RECOMMENDED that the conference server 3467 correlate the authorization of the CCMP interface with other 3468 authorization mechanisms - e.g., PSTN users that join with a PIN and 3469 control the conference using CCMP. When a conference server presents 3470 the identity of authorized users, it MAY provide information about 3471 the way the identity was proven or verified by the system. A 3472 conference server can also allow a completely unauthenticated user 3473 into the system - this information SHOULD also be communicated to 3474 interested parties. 3476 Once a user is authenticated and authorized through the various 3477 mechanisms available on the conference server, the conference server 3478 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 3479 associate the XCON-USERID with any signaling specific user 3480 identifiers that were used for authentication and authorization. 3481 This XCON-USERID can be provided to a specific user through the 3482 conference notification interface and MUST be provided to users that 3483 interact with the conferencing system using the CCMP (i.e., in the 3484 appropriate CCMP response messages). This conference user identifier 3485 is REQUIRED for any subsequent operations on the conference object. 3487 We herein remark that the definition of a complete solution for 3488 policy-based management of an XCON-compliant conference system is out 3489 of the scope of this document, as well as of the XCON WG. We believe 3490 that the specification of such a framework is orthogonal to the 3491 overall XCON architecture, especially if a Role Based Access Control 3492 (RBAC) approach is embraced. In RBAC, the following elements are 3493 identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; 3494 (v) Permissions. For all of the above elements a direct mapping 3495 exists onto the main XCON entities. As an example, RBAC objects map 3496 onto XCON data model objects and RBAC operations map onto CCMP 3497 operations. 3499 Future documents might work on the definition of an RBAC framework 3500 for XCON, by first focusing on the definition of roles and eventually 3501 arriving at the specification of the needed permission policy sets 3502 and role policy sets (used to associate policy permission sets with 3503 specific roles). With these policies in place, access to a 3504 conference object compliant with the XCON data model can be 3505 appropriately controlled. Finally, coming to the issue of assigning 3506 users to roles, this can be done through so-called role-assignment 3507 policies. Such assignment should be under the responsibility of an 3508 ad-hoc dedicated Role Assignment entity. 3510 10.3. Security and Privacy of Identity 3512 An overview of the required privacy and anonymity for users of a 3513 conferencing system are provided in the XCON Framework [RFC5239]. 3514 The security of the identity in the form of the XCON-USERID is 3515 provided in the CCMP protocol through the use of TLS. 3517 The conference server SHOULD provide mechanisms to ensure the privacy 3518 of the XCON-USERID. This is accomplished by the conference client 3519 manipulation of the "provide-anonymity" element defined in the XCON 3520 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 3521 anonymity" element controls the degree to which a user reveals their 3522 identity. The conference client MUST set the "provide-anonymity" 3523 element to "hidden" if the user does not want other participants to 3524 even be aware that there is an additional participant in the 3525 conference. The conference client MUST set the "provide-anonymity" 3526 field to "private" if the user wants to be entirely "anonymous" 3527 (i.e., other participants are aware that there is another 3528 participant, but have no information as to their identity). The 3529 conference client MUST set the "provide-anonymity" field to "semi- 3530 private" if their identity is only to be revealed to other 3531 participants or users that have a higher level authorization (e.g., a 3532 conferencing system can be configured such that an administrator can 3533 see all users). To provide the required privacy, the conference 3534 client SHOULD include the "provide-anonymity" element in the 3535 "confInfo" parameter in a CCMP confRequest message with an "update" 3536 or "create" operation or in the "userInfo" parameter in a CCMP 3537 userRequest message with an "update" or "create" operation, to ensure 3538 the user is provided the appropriate level of privacy. If the 3539 "provide-anonymity" element is not included in the conference object, 3540 then other users can see the participant's identity. 3542 11. XML Schema 3544 This section provides the XML schema definition of the "application/ 3545 ccmp+xml" format. 3547 3549 3558 3561 3564 3565 3567 3569 3570 3571 3573 3574 3576 3578 3580 3581 3583 3585 3587 3589 3591 3593 3594 3595 3597 3599 3600 3601 3603 3604 3606 3608 3609 3610 3612 3614 3616 3618 3620 3622 3624 3625 3626 3628 3630 3632 3633 3634 3635 3636 3637 3638 3639 3640 3642 3644 3646 3647 3648 3650 3652 3653 3654 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3667 3669 3671 3672 3673 3675 3677 3678 3679 3681 3683 3684 3685 3686 3687 3688 3689 3690 3691 3693 3695 3697 3698 3699 3701 3703 3704 3706 3708 3710 3711 3712 3713 3714 3715 3716 3717 3718 3720 3722 3724 3725 3726 3728 3730 3731 3732 3734 3736 3737 3738 3739 3740 3741 3742 3743 3744 3746 3748 3750 3751 3752 3755 3757 3758 3759 3761 3763 3764 3765 3766 3767 3768 3769 3770 3771 3773 3775 3777 3778 3779 3781 3783 3784 3785 3787 3789 3790 3791 3792 3793 3794 3795 3796 3797 3799 3801 3804 3805 3806 3808 3810 3811 3812 3814 3816 3817 3818 3819 3820 3821 3822 3823 3824 3826 3828 3831 3832 3833 3835 3837 3838 3839 3841 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3854 3857 3858 3859 3861 3863 3864 3865 3867 3869 3870 3871 3872 3873 3874 3875 3876 3877 3879 3881 3884 3885 3886 3888 3890 3891 3892 3894 3896 3897 3898 3899 3900 3901 3902 3903 3904 3906 3908 3910 3911 3912 3913 3915 3916 3918 3920 3921 3922 3923 3924 3925 3927 3929 3931 3932 3933 3934 3935 3936 3937 3938 3939 3941 3943 3945 3946 3947 3949 3951 3952 3953 3955 3957 3958 3959 3960 3961 3962 3963 3964 3965 3967 3969 3971 3972 3973 3975 3977 3978 3979 3981 3983 3984 3985 3986 3987 3988 3989 3990 3991 3993 3994 3996 3997 3998 4000 4002 4003 4004 4006 4008 4009 4010 4011 4012 4013 4014 4015 4016 4018 4020 4022 4023 4024 4026 4028 4029 4030 4032 4034 4035 4036 4037 4038 4039 4040 4041 4043 4045 4047 4049 4050 4051 4053 4055 4056 4057 4059 4061 4062 4063 4064 4065 4066 4067 4068 4069 4071 4073 4075 4076 4077 4079 4081 4082 4083 4085 4087 4088 4089 4090 4091 4092 4093 4094 4095 4097 4099 4102 4103 4104 4106 4108 4109 4110 4112 4114 4115 4116 4117 4118 4119 4120 4121 4122 4124 4126 4129 4130 4131 4133 4135 4136 4137 4138 4140 4141 4142 4143 4144 4145 4146 4147 4148 4150 4152 4155 4156 4157 4159 4161 4162 4163 4165 4167 4168 4169 4170 4171 4172 4173 4174 4175 4177 4179 4182 4183 4184 4187 4189 4190 4191 4193 4195 4196 4197 4198 4199 4200 4201 4202 4203 4205 4207 4209 4210 4211 4212 4214 4215 4217 4219 4220 4221 4222 4223 4224 4225 4226 4227 4229 4231 4234 4235 4236 4238 4240 4241 4242 4244 4246 4248 4250 4251 4252 4253 4254 4256 4258 4259 4260 4261 4262 4263 4264 4265 4267 4269 4270 4271 4273 4275 4277 4278 4279 4281 4282 4283 4284 4285 4286 4288 4289 4290 4292 4294 4295 4296 4297 4299 4300 4301 4303 4305 4306 4307 4308 4309 4310 4311 4313 4314 4315 4317 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4334 4336 4337 4338 4340 4341 4342 4344 4346 4347 4348 4349 4351 4352 4353 4355 4357 4358 4359 4360 4361 4362 4363 4365 4366 4367 4369 4371 Figure 30 4373 12. IANA Considerations 4375 This document registers a new XML namespace, a new XML schema, and 4376 the MIME type for the schema. This document also registers the 4377 "XCON" Application Service tag and the "CCMP" Application Protocol 4378 tag. This document also defines registries for the CCMP operation 4379 types and response codes. 4381 12.1. URN Sub-Namespace Registration 4383 This section registers a new XML namespace, 4384 ""urn:ietf:params:xml:ns:xcon:ccmp"". 4386 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 4387 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 4388 Mary Barnes (mary.barnes@nortel.com). 4389 XML: 4391 BEGIN 4392 4393 4395 4396 4397 CCMP Messages 4398 4399 4400

Namespace for CCMP Messages

4401

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

4402 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 4403 with the RFC number for this specification.]] 4404

See RFCXXXX.

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