idnits 2.17.1 draft-ietf-xcon-ccmp-07.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 2 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2010) is 5111 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 1348, but not defined == Missing Reference: '0-9' is mentioned on line 3622, but not defined == Unused Reference: 'RFC3966' is defined on line 4059, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-xcon-examples' is defined on line 4069, 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-18 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-10) exists of draft-ietf-xcon-examples-04 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Standards Track C. Boulton 5 Expires: October 28, 2010 NS-Technologies 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 April 26, 2010 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-07 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 October 28, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 3. XCON Conference Control System Architecture . . . . . . . . . 5 64 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . . 7 66 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 68 4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11 69 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 71 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . . 14 72 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 73 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . . 18 74 5.3.2. confsRequest and confsResponse . . . . . . . . . . . . 20 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 . . . . 34 80 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . . 36 81 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . . 39 82 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . . 40 83 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 43 84 6. A complete example of the CCMP in action . . . . . . . . . . . 46 85 6.1. Alice retrieves the available blueprints . . . . . . . . . 47 86 6.2. Alice gets detailed information about a specific 87 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 49 88 6.3. Alice creates a new conference through a cloning 89 operation . . . . . . . . . . . . . . . . . . . . . . . . 51 90 6.4. Alice updates conference information . . . . . . . . . . . 54 91 6.5. Alice inserts a list of users in the conference object . . 56 92 6.6. Alice joins the conference . . . . . . . . . . . . . . . . 57 93 6.7. Alice adds a new user to the conference . . . . . . . . . 59 94 7. Locating a Conference Control Server . . . . . . . . . . . . . 61 95 8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 63 96 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 63 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 98 10.1. Assuring that the Proper Conferencing Server has been 99 contacted . . . . . . . . . . . . . . . . . . . . . . . . 66 100 10.2. User Authentication and Authorization . . . . . . . . . . 66 101 10.3. Security and Privacy of Identity . . . . . . . . . . . . . 67 102 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68 103 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 104 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 82 105 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 83 106 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 83 107 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 84 108 12.4.1. Registration of a Conference Control Server 109 Application Service Tag . . . . . . . . . . . . . . . 84 110 12.4.2. Registration of a Conference Control Server 111 Application Protocol Tag for CCMP . . . . . . . . . . 84 112 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 85 113 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 85 114 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 86 115 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 116 14. Changes since last Version . . . . . . . . . . . . . . . . . . 87 117 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 118 15.1. Normative References . . . . . . . . . . . . . . . . . . . 89 119 15.2. Informative References . . . . . . . . . . . . . . . . . . 90 120 Appendix A. Appendix A: Other protocol models and transports 121 considered for CCMP . . . . . . . . . . . . . . . . . 91 122 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 91 123 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 92 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 126 1. Introduction 128 The Framework for Centralized Conferencing [RFC5239] (XCON Framework) 129 defines a signaling-agnostic framework, naming conventions and 130 logical entities required for building advanced conferencing systems. 131 The XCON Framework introduces the conference object as a logical 132 representation of a conference instance, representing the current 133 state and capabilities of a conference. 135 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 136 this document allows authenticated and authorized users to create, 137 manipulate and delete conference objects. Operations on conferences 138 include adding and removing participants, changing their roles, as 139 well as adding and removing media streams and associated end points. 141 The CCMP implements the client-server model within the XCON 142 Framework, with the Conference Control Client and Conference Control 143 Server acting as client and server, respectively. The CCMP uses HTTP 144 [RFC2616] as the protocol to transfer requests and responses, which 145 contain the domain-specific XML-encoded data objects defined in 146 [I-D.ietf-xcon-common-data-model] Conference Information Data Model 147 for Centralized Conferencing (XCON Data Model). 149 Section 2 clarifies the conventions and terminology used in the 150 document. Section 3 provides an overview of the Conference Control 151 functionality of the XCON framework, together with a description of 152 the main targets CCMP deals with, namely conference objects and 153 conference users. A general description of the operations associated 154 with protocol messages is given in Section 4 together with 155 implementation details. Section 5 delves into the details of the 156 specific CCMP messages. A complete, not normative, example of the 157 operation of the CCMP, describing a typical call flow associated with 158 conference creation and manipulation, is provided in Section 6. A 159 survey of the methods that can be used to locate a Conference Control 160 Server is provided in Section 7, whereas Section 8 discusses 161 potential approaches to notifications management. CCMP transport 162 over HTTP is highlighted in Section 9. Security considerations are 163 presented in Section 10. Finally, Section 11 provides the XML 164 schema. 166 2. Conventions and Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 In additon to the terms defined in the Framework for Centralized 173 Conferencing [RFC5239], this document uses the following terms and 174 acronyms: 176 XCON aware client: An XCON conferencing system client which is able 177 to issue CCMP requests. 179 3. XCON Conference Control System Architecture 181 CCMP supports the XCON framework . Figure 1 depicts a subset of the 182 "Conferencing System Logical Decomposition" architecture from the 183 XCON framework document. It illustrates the role that CCMP assumes 184 within the overall centralized architecture. 186 ........................................................ 187 . Conferencing System . 188 . . 189 . +---------------------------------------+ . 190 . | C O N F E R E N C E O B J E C T | . 191 . +-+-------------------------------------+ | . 192 . | C O N F E R E N C E O B J E C T | | . 193 . +-+-------------------------------------+ | | . 194 . | C O N F E R E N C E O B J E C T | | | . 195 . | | |-+ . 196 . | |-+ . 197 . +---------------------------------------+ . 198 . ^ . 199 . | . 200 . v . 201 . +-------------------+ . 202 . | Conference Control| . 203 . | Server | . 204 . +-------------------+ . 205 . ^ . 206 .........................|.............................. 207 | 208 |Centralized 209 |Conferencing 210 |Manipulation 211 |Protocol 212 | 213 .........................|.............................. 214 . V . 215 . +----------------+ . 216 . | Conference | . 217 . | Control | . 218 . | Client | . 219 . +----------------+ . 220 . . 221 . Conferencing Client . 222 ........................................................ 224 Figure 1: Conference Client Interaction 226 CCMP serves as the Conference Control Protocol, allowing the 227 conference control client to interface with the conference object 228 maintained by the conferencing system, as represented in Figure 1. 229 Conference Control is one part of functionality for advanced 230 conferencing supported by a conferencing client. Other functions are 231 discussed in the XCON framework and related documents. 233 Conference object and conference users do represent key elements 234 involved in Conference Control Protocol operations. Their 235 identifiers, respectively the conference XCON-URI and the 236 conferencing client XCON-USERID, and their XML representations 237 compliant with the XML Schema defined in the XCON data model are 238 widely used for creating the CCMP requests and responses. The main 239 conference objects and users features envisioned by the XCON 240 framework are briefly described in the following subsections. 242 3.1. Conference Objects 244 Conference objects feature a simple dynamic inheritance-and-override 245 mechanism. Conference objects are linked into a tree known as 246 "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree 247 node inherits attributes from its parent node. The roots of these 248 inheritance trees are conference templates also known as 249 "blueprints". Nodes in the inheritance tree can be active 250 conferences or simply descriptions that do not currently have any 251 resources associated with them (conference reservations). An object 252 can mark certain of its properties as unalterable, so that they 253 cannot be overridden. It is envisaged by the framework that a client 254 may specify a parent object (a conference or blueprint) from which 255 the conference to be created has to inherit values by the mean of the 256 Conference Control Protocol. 258 Conference objects are uniquely identified by the XCON-URI within the 259 scope of the conferencing system. Such identifier is introduced in 260 the XCON framework and defined in the XCON common data model. 262 Conference objects are comprehensively represented through XML 263 documents compliant with the XML Schema defined in the XCON data 264 model [I-D.ietf-xcon-common-data-model]. The root element of such 265 documents, called "", is of type "conference-type". 266 It encompasses other XML elements describing different conference 267 features and users as well. By the mean of CCMP, conferencing 268 clients can use such XML structures to express their preferences in 269 creation or update. A conferencing server can convey conference 270 information of such a form back to the clients. 272 3.2. Conference Users 274 Each conference can have zero or more users. All conference 275 participants are users, but some users may have only administrative 276 functions and do not contribute or receive media. Users are added 277 one user at a time to simplify error reporting. When a conference is 278 cloned from a parent object, users are inherited as well, so that it 279 is easy to set up a conference that has the same set of participants 280 or a common administrator. The Conference Control Server creates 281 individual users, assigning them a unique Conference User Identifier 282 (XCON-USERID). The XCON-USERID as identifier of each conferencing 283 system client is introduced in the XCON framework and defined in the 284 XCON common data model. Each CCMP request, with an exception pointed 285 out in Section 5.3.6 representing the case of a user at his first 286 entrance in the system as a conference participant, must carry the 287 XCON-USERID of the requestor in the proper "confUserID" parameter. 289 The XCON-USERID acts as a pointer to the user's profile as a 290 conference actor, e.g. her signalling URI and other XCON protocol 291 URIs in general, her role (moderator, participant, observer, etc.), 292 her display text, her joining information and so on. A variety of 293 elements defined in the common element as specified 294 in the XCON data model are used to describe the users related to a 295 conference, in the first place the element, as well as each 296 element included in it. For example, it is possible to 297 determine how a specific user expects and is allowed to join a 298 conference by looking at the in : each 299 element involved in such a list represents a user and shows 300 a "method" attribute defining how the user is expected to join the 301 conference, i.e. "dial-in" for users that are allowed to dial, "dial- 302 out" for users that the conference focus will be trying to reach 303 (with "dial-in" being the default mode). If the conference is 304 currently active, dial-out users are contacted immediately; 305 otherwise, they are contacted at the start of the conference. The 306 CCMP, acting as the Conference Control Protocol, provides a means to 307 manipulate these and other kinds of user-related features. 309 As a consequence of an explicit user registration to a specific XCON 310 conferencing system, conferencing clients are usually provided 311 (besides the XCON-USERID) with log-in credentials (i.e. username and 312 password). Such credentials can be used to authenticate the XCON 313 aware client issuing CCMP requests. To this purpose, both username 314 and password should be carried in a CCMP request as part of the 315 "subject" parameter whenever a registered conferencing client wishes 316 to contact a CCMP server. The CCMP does not look after users 317 subscriptions at the conference server; hence, it does not provide 318 any specific mechanism allowing clients to register their 319 conferencing accounts. The "subject" parameter is just used for 320 carrying authentication data associated with pre-registered clients. 322 4. Protocol Overview 324 CCMP is a client-server, XML-based protocol, which has been 325 specifically conceived to provide users with the necessary means for 326 the creation, retrieval, modification and deletion of conference 327 objects. CCMP is also state-less, which means implementations can 328 safely handle transactions independently from each other. 329 Conference-related information is encapsulated into CCMP messages in 330 the form of XML documents or XML document fragments compliant with 331 the XCON data model representation. 333 Section 4.1 specifies the basic operations that can create, retrieve, 334 modify and delete conference-related information in a centralized 335 conference. The core set of objects manipulated in the CCMP protocol 336 includes conference blueprints, the conference object, users, and 337 sidebars. 339 CCMP has been conceived as completely independent from underlying 340 protocols, which means that there can be different ways to carry CCMP 341 messages across the network, from a conferencing client to a 342 conferencing server. Nevertheless, it is recommended to use HTTP as 343 a transport solution, including CCMP requests in HTTP POST messages 344 and CCMP responses in HTTP 200 OK replies. Implementation details 345 are presented in Section 4.2 347 4.1. Protocol Operations 349 The main operations provided by CCMP belong in four general 350 categories: 352 create: for the creation of a conference, a conference user, a 353 sidebar, or a blueprint. 354 retrieve: to get information about the current state of either a 355 conference object (be it an actual conference or a blueprint, or a 356 sidebar) or a conference user. A retrieve operation can also be 357 used to obtain the XCON-URIs of the current conferences (active or 358 registered) handled by the conferencing server and/or the 359 available blueprints. 360 update: to modify the current features of a specified conference or 361 conference user. 362 delete: to remove from the system a conference object or a 363 conference user. 365 Thus, the main targets of CCMP operations are: 367 o conference objects associated with either active or registered 368 conferences, 369 o conference objects associated with blueprints, 370 o conference objects associated with sidebars, both embedded in the 371 main conference (i.e. elements in ) and 372 external to it (i.e. whose xcon-uris are included in the 373 elements of ), 375 o elements associated with conference users, 376 o the list of XCON-URIs related to conferences and blueprints 377 available at the server, for which only retrieval operations are 378 allowed. 380 Each operation in the protocol model is atomic and either succeeds or 381 fails as a whole. The conference server must ensure that the 382 operations are atomic in that the operation invoked by a specific 383 conference client completes prior to another client's operation on 384 the same conference object. The details for this data locking 385 functionality are out of scope for the CCMP protocol specification 386 and are implementation specific for a conference server. Thus, the 387 conference server first checks all the parameters, before making any 388 changes to the internal representation of the conference object. For 389 example, it would be undesirable to change the of the 390 conference, but then detect an invalid URI in one of the and abort the remaining updates. Also, since multiple clients 392 can modify the same conference objects, conference clients should 393 first obtain the current object from the conference server and then 394 update the relevant data elements in the conference object prior to 395 invoking a specific operation on the conference server. In order to 396 effectively manage modifications to conference data, a versioning 397 approach is exploited in the CCMP. More precisely, each conference 398 object is associated with a version number indicating the most up to 399 date view of the conference at the server's side. Such version 400 number is reported to the clients when answering their requests. A 401 client willing to make modifications to a conference object has to 402 send an update message to the server. In case the modifications are 403 all successfully applied, the server sends back to the client a "200" 404 response which also carries information about the current server-side 405 version of the modified object. With such approach, a client which 406 is working on version "X" of a conference object and finds inside a 407 "200" response a version number which is "X+1" can be sure that the 408 version it was aware of was the most up to date. On the other hand, 409 if the "200" response carries back a version which is at least "X+2", 410 the client can detect that the object that has been modified at the 411 server's side was more up to date than the one it was working upon. 412 This is clearly due to the effect of concurrent modification requests 413 issued by independent clients. Hence, for the sake of having 414 available the latest version of the modified object, the client can 415 send to the conference server a further "retrieve" request. In no 416 case a copy of the conference object available at the server is 417 returned to the client as part of the update response message. Such 418 a copy can always be obtained through an ad-hoc "retrieve" message. 420 Based on the above considerations, all CCMP response messages 421 carrying in their body a conference document (or a fragment of it) 422 must contain a "version" parameter. This does not hold for request 423 messages, for which the "version" parameter is not at all required, 424 since it represents useless information for the server: as long as 425 the required modifications can be applied to the target conference 426 object with no conflicts, the server does not care whether or not the 427 client had an up to date view of the information stored at its side. 428 This said, it stands clear that a client which has subscribed at the 429 server, through the XCON event package [I-D.ietf-xcon-event-package], 430 to notifications about conference object modifications, will always 431 have the most up to date version of that object available at his 432 side. 434 A final consideration concerns the relation between the CCMP and the 435 main entities it manages, i.e. conference objects. Such objects have 436 to be compliant with the XCON data-model, which identifies some 437 elements/attributes as mandatory. From the CCMP standpoint this can 438 become a problem in cases of client-initiated operations, like the 439 creation/update of conference objects. In such cases, not all of the 440 mandatory data can be known in advance to the client issuing a CCMP 441 request. As an example, a client has no means to know, at the time 442 it issues a conference creation request, the XCON-URI that the server 443 will assign to the yet-to-be-created conference and hence it is not 444 able to appropriately fill with that value the mandatory "entity" 445 attribute of the conference document contained in the request. To 446 solve this kind of issues, the CCMP will fill all mandatory data 447 model fields, for which no value is available at the client at the 448 time the request is constructed, with fake values in the form of 449 wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental 450 index initialized to a value of 1). Upon reception of the mentioned 451 kinds of requests, the server will: (i) generate the proper 452 identifier(s); (ii) produce a response in which the received fake 453 identifier(s) carried in the request has (have) been replaced by the 454 newly created one(s). With this approach we maintain compatibility 455 with the data model requirements, at the same time allowing for 456 client-initiated manipulation of conference objects at the server's 457 side (which is, by the way, one of the main goals for which the CCMP 458 protocol has been conceived at the outset). 460 4.2. Implementation Approach 462 There have been a number of different proposals as to the most 463 suitable implementation solution for the CCMP. A non-exhaustive 464 summary of the most interesting ones is provided in Appendix A. The 465 solution for the CCMP defined in this document is viewed as a good 466 compromise amongst the most notable past candidates and is referred 467 to as "HTTP single-verb transport plus CCMP body". With this 468 approach, CCMP is able to take advantage of existing HTTP 469 functionality. As with SOAP, the CCMP uses a "single HTTP verb" for 470 transport (i.e. a single transaction type for each request/response 471 pair); this allows decoupling CCMP messages from HTTP messages. 472 Similarly, as with any RESTful approach, CCMP messages are inserted 473 directly in the body of HTTP messages, thus avoiding any unnecessary 474 processing and communication burden associated with further 475 intermediaries. With this approach, no modification to the CCMP 476 messages/operations is required to use a different transport 477 protocol. 479 The remainder of this document focuses on the selected approach. The 480 CCMP protocol inserts XML-based CCMP requests into the body of HTTP 481 POST operations and retrieves responses from the body of HTTP "200 482 OK" messages. CCMP messages have a MIME-type of "application/ 483 ccmp+xml", which appears inside the "Content-Type" and "Accept" 484 fields of HTTP requests and responses. Section 9 provides the 485 complete requirements for an HTTP implementation to support the CCMP. 487 5. CCMP messages 489 CCMP messages are either requests or responses. The general CCMP 490 request message is defined in Section 5.1. The general CCMP response 491 message is defined in Section 5.2. The details of the specific 492 message type which is carried in the CCMP request and response 493 messages are described in Section 5.3. CCMP response codes are 494 listed in Section 5.4 496 5.1. CCMP Request Message Type 498 A CCMP request message is comprised of the following parameters: 500 subject: An optional parameter containing username and password of 501 the client registered at the conferencing system. Each user who 502 subscribes to the conferencing system is assumed to be equipped 503 with those credentials and SHOULD enclose them in each CCMP 504 request she issues. These fields can be used to control that the 505 user sending the CCMP request has the authority to perform the 506 entailed operation. The same fields can also be exploited to 507 carry out other Authorization, Authentication and Accounting (AAA) 508 procedures. 509 confUserID: An optional parameter containing the XCON-USERID of the 510 client. The XCON-USERID is used to identify any conferencing 511 client within the context of the conferencing system and it is 512 assinged by the conferencing server at each conferencing client 513 who interacts with it. The "confUserID" parameter is REQUIRED in 514 the CCMP request and response messages with the exception of the 515 case of a user who has no XCON-USERID and who wants to enter, via 516 CCMP, a conference whose identifier is known. In such case, a 517 side-effect of the request is that the user is provided with an 518 appropriate XCON-USERID. An example of the above mentioned case 519 will be provided in Section 5.3.6. 520 confObjID: An optional parameter containing the XCON-URI of the 521 target conference object. 522 operation: An optional parameter refining the type of specialized 523 request message. The "operation" parameter is REQUIRED in all 524 requests except for the "blueprintsRequest" and "confsRequest" 525 specialized messages. 526 conference-password: An optional parameter that MUST be inserted in 527 all requests whose target conference object is password-protected 528 (as per the element in 529 [I-D.ietf-xcon-common-data-model]). 530 specialized request message: This is specialization of the generic 531 request message (e.g., blueprintsRequest), containing parameters 532 that are dependent on the specific request sent to the server. A 533 specialized request message MUST be included in the CCMP request 534 message. The details for the specialized messages and associated 535 parameters are provided in Section 5.3. 537 539 541 543 544 545 547 548 550 552 554 555 557 559 561 563 565 567 568 569 571 Figure 2: Structure of CCMP Request messages 573 5.2. CCMP Response Message Type 575 A CCMP response message is comprised of the following parameters: 577 confUserID: A mandatory parameter in CCMP response messages 578 containing the XCON-USERID of the conferencing client who issued 579 the CCMP request message. 581 confObjID: An optional parameter containing the XCON-URI of the 582 target conference object. 583 operation: An optional parameter for CCMP response messages. This 584 parameter is REQUIRED in all responses except for the 585 "blueprintsResponse" and "confsResponse" specialized messages. 586 response-code: A mandatory parameter containing the response code 587 associated with the request. The response code MUST be chosen 588 from the codes listed in Section 5.4. 589 response-string: An optional reason string associated with the 590 response. In case of an error, in particular, such string can be 591 used to provide the client with detailed information about the 592 error itself. 593 version: An optional parameter reflecting the current version number 594 of the conference object referred by the confObjID. This number 595 is contained in the "version" attribute of the 596 element related to that conference. 597 specialized response message: This is specialization of the generic 598 response message, containing parameters that are dependent on the 599 specific request sent to the server (e.g., blueprintsResponse). A 600 specialized response message SHOULD be included in the CCMP 601 response message, except in an error situation where the CCMP 602 request message did not contain a valid specialized message. In 603 this case, the conference server MUST return a "response-code" of 604 "400". The details for the specialized messages and associated 605 parameters are provided in Section 5.3. 607 609 611 613 614 615 617 618 620 622 624 625 627 629 631 633 635 637 639 640 641 643 Figure 3: Structure of CCMP Response message 645 5.3. Detailed messages 647 Based on the request and response message structures described in 648 Section 5.1 and Section 5.2, the following summarizes the specialized 649 CCMP request/response types described in this document: 651 1. blueprintsRequest/blueprintsResponse 652 2. confsRequest/confsResponse 653 3. blueprintRequest/blueprintResponse 654 4. confRequest/confResponse 655 5. usersRequest/usersResponse 656 6. userRequest/userResponse 657 7. sidebarsByValRequest/sidebarsByValResponse 658 8. sidebarsByRefRequest/sidebarsByRefResponse 659 9. sidebarByValRequest/sidebarByValResponse 660 10. sidebarByRefRequest/sidebarByRefResponse 662 These CCMP request/response pairs use the fundamental CCMP operations 663 as defined in Section 4.1 to manipulate the conference data. Table 1 664 summarizes the CCMP operations and corresponding actions that are 665 valid for a specific CCMP request type, noting that neither the 666 blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse 667 require an "operation" parameter. The corresponding response MUST 668 contain the same operation. Note that some entries are labeled "N/A" 669 indicating the operation is invalid for that request type. In the 670 case of an "N/A*", the operation MAY be allowed for specific 671 privileged users or system administrators, but is not part of the 672 functionality included in this document. 674 +---------------+------------+------------+------------+------------+ 675 | Operation | Retrieve | Create | Update | Delete | 676 | ------------- | | | | | 677 | Request Type | | | | | 678 +---------------+------------+------------+------------+------------+ 679 | blueprints | Get list | N/A | N/A | N/A | 680 | Request | of | | | | 681 | | blueprints | | | | 682 | ------------- | ---------- | ---------- | ---------- | ---------- | 683 | blueprint | Get | N/A* | N/A* | N/A* | 684 | Request | blueprint | | | | 685 | ------------- | ---------- | ---------- | ---------- | ---------- | 686 | confsRequest | Get list | N/A | N/A | N/A | 687 | | of confs | | | | 688 | ------------- | ---------- | ---------- | ---------- | ---------- | 689 | confRequest | Gets | Creates | Changes | Deletes | 690 | | conference | conference | conference | conference | 691 | | object | object | object | object | 692 | ------------- | ---------- | ---------- | ---------- | ---------- | 693 | usersRequest | Gets | N/A(**) | Changes | N/A(**) | 694 | | | | | | 695 | ------------- | ---------- | ---------- | ---------- | ---------- | 696 | userRequest | Gets | Adds a | Changes | Deletes | 697 | | specified | to | specified | specified | 698 | | | a conf | | | 699 | | | (***) | | | 700 | ------------- | ---------- | ---------- | ---------- | ---------- | 701 | sidebarsByVal | Gets | N/A | N/A | N/A | 702 | Request | | | | | 704 | ------------- | ---------- | ---------- | ---------- | ---------- | 705 | sidebarsByRef | Gets | N/A | N/A | N/A | 706 | Request | | | | | 708 | ------------- | ---------- | ---------- | ---------- | ---------- | 709 | sidebarByVal | Gets | Creates | Changes | Deletes | 710 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 711 | | by-val | by-val | by-val | by-val | 712 | ------------- | ---------- | ---------- | ---------- | ---------- | 713 | sidebarByRef | Gets | Creates | Changes | Deletes | 714 | Request | sidebar- | sidebar- | sidebar- | sidebar- | 715 | | by-ref | by-ref | by-ref | by-ref | 716 +---------------+------------+------------+------------+------------+ 718 Table 1: Request Type Operation Specific Processing 720 (**): These operations are not allowed for a usersRequest message, 721 since the section, which is the target element of such a 722 request, is created and removed in conjuntcion with, respectively, 723 the creation and deletion of the associated conference document. 724 Thus, "update" and "retrieve" are the only semantically correct 725 operations for such message. 727 (***): This operation can involve the creation of an XCON-USERID, if 728 the sender does not add it in the "confUserID" parameter, and/or if 729 the "entity" field of the "userInfo" parameter is void. 731 Additional parameters included in the specialized CCMP request/ 732 response messages are detailed in the subsequent sections. 734 5.3.1. blueprintsRequest and blueprintsResponse 736 A "blueprintsRequest" (Figure 4) message is sent to request the list 737 of XCON-URIs associated with the available blueprints from the 738 conference server. Such URIs can be subsequently used by the client 739 to access detailed information about a specified blueprint with a 740 specific blueprintRequest message per Section 5.3.3. The 741 "confUserID" parameter MUST be included in every blueprintsRequest/ 742 Response message and reflect the XCON-USERID of the conferencing 743 client issuing the request. A blueprintsRequest message REQUIRES no 744 "confObjID" and "operation" parameters, since it is not targetted to 745 a specific conference instance and it is conceived as a "retrieve- 746 only" request. In order to obtain a specific subset of the available 747 blueprints, a client may specify a selection filter providing an 748 appropriate xpath query in the optional "xpathFilter" parameter of 749 the request. For example, to select blueprints having both audio and 750 video stream support, a possible xpathFilter value could be: "/ 751 conference-info[conference-description/available-media/entry/ 752 type='audio' and conference-description/available-media/entry/ 753 type='video']". 755 The associated "blueprintsResponse" message SHOULD contain, as shown 756 in Figure 4, a "blueprintsInfo" parameter containing the above 757 mentioned XCON-URI list. 759 761 762 763 764 765 766 767 768 769 771 773 775 776 777 778 780 781 782 784 786 787 788 789 790 791 792 793 795 797 799 801 802 803 805 807 808 809 811 Figure 4: Structure of the blueprintsRequest and blueprintsResponse 812 messages 814 5.3.2. confsRequest and confsResponse 816 A "confsRequest" message is used to retrieve, from the server, the 817 list of XCON-URIs associated with active and registered conferences 818 currently handled by the conferencing system. The "confUserID" 819 parameter MUST be included in every confsRequest/Response message and 820 reflect the XCON-USERID of the conferencing client issuing the 821 request. The "confObjID" parameter MUST NOT be included in the 822 confsRequest message. The "confsRequest" message is of a "retrieve- 823 only" type, since the sole purpose is to collect information 824 available at the conference server. Thus, an "operation" parameter 825 MUST NOT be included in a "confsRequest" message. In order to 826 retrieve a specific subset of the available conferences, a client may 827 specify a selection filter providing an appropriate xpath query in 828 the optional "xpathFilter" parameter of the request. For example, to 829 select only the registered conferences, a possible xpathFilter value 830 could be: "/conference-info[conference-description/conference-state/ 831 active='false']". The associated "confsResponse" message SHOULD 832 contain the list of XCON-URIs in the "confsInfo" parameter. A user, 833 upon receipt of the response message, can interact with the available 834 conference objects through further CCMP messages. 836 838 839 840 841 842 843 844 845 846 848 850 852 853 854 855 857 858 859 861 863 864 865 866 867 868 869 870 871 873 875 877 878 879 881 883 884 885 887 Figure 5: Structure of the confsRequest and confsResponse messages 889 5.3.3. blueprintRequest and blueprintResponse 891 Through a "blueprintRequest", a client can manipulate the conference 892 object associated with a specified blueprint. Further than the 893 "confUserID" parameter, the request MUST include the "confObjID" and 894 the "operation" one. Again, the "confUserID" parameter MUST be 895 included in every blueprintRequest/Response message and reflect the 896 XCON-USERID of the conferencing client issuing the request. The 897 "confObjID" parameter MUST contain the XCON-URI of the blueprint, 898 which might have been previously retrieved through a 899 "blueprintsRequest" message. 901 The blueprintRequest message SHOULD NOT contain an "operation" 902 parameter other than "retrieve". The "create", "update" and "delete" 903 operations SHOULD NOT be included in a "blueprintRequest" message 904 except in the case of privileged users (e.g. the conference server 905 administration staff), who might authenticate themselves by the mean 906 of the "subject" request parameter. 908 A blueprintRequest/retrieve carrying a "confObjID" which is not 909 associated with one of the available system's blueprints will 910 generate, on the server's side, a blueprintResponse message 911 containing a "404" error code. This holds also for the case in which 912 the mentioned "confObjID" is related to an existing conference 913 document stored at the server, but associated with an actual 914 conference (be it active or registered) or with a sidebar rather than 915 a blueprint. 917 In the case of "response-code" of "200" for a "retrieve" operation, 918 the "blueprintInfo" parameter MUST be included in the 919 "blueprintResponse" message. The "blueprintInfo" parameter contains 920 the conference document associated with the blueprint as identified 921 by the "confObjID" parameter specified in the blueprintRequest. 923 925 926 927 928 929 930 931 932 933 934 936 938 939 940 942 944 945 946 948 950 951 952 953 954 955 956 957 958 960 962 964 965 966 968 970 971 972 974 Figure 6: Structure of the blueprintRequest and blueprintResponse 975 messages 977 5.3.4. confRequest and confResponse 979 With a "confRequest" message, CCMP clients can manipulate conference 980 objects associated with either active or registered conferences. The 981 "confUserID" parameter MUST be included in every confRequest/Response 982 message and reflect the XCON-USERID of the conferencing client 983 issuing the request. ConfRequest and confResponse messages MUST also 984 include an "operation" parameter. ConfResponse messages MUST return 985 to the requestor a "response-code" and MAY contain a "response- 986 string" explaining it. Depending upon the type of "operation", a 987 "confObjID" and "confInfo" parameter MAY be included in the 988 confRequest and response. The requirements for inclusion of 989 "confObjID" and "confInfo" parameter in the confRequest/confResponse 990 messages and are detailed below for each "operation" case. 992 The creation case deserves care. To create a new conference through 993 a "confRequest" message, two approaches can be considered: 995 1. Creation through explicit cloning: the "confObjID" parameter MUST 996 contain the XCON-URI of the blueprint or of the conference to be 997 cloned, while the "confInfo" parameter MUST NOT be included in 998 the confRequest; 999 2. Creation through implicit cloning (also known as "direct 1000 creation"): the "confObjID" parameter MUST NOT be included in the 1001 request and the CCMP client can describe the desired conference 1002 to be created using the "confInfo" parameter. If no "confInfo" 1003 parameter is provided in the request, the new conference will be 1004 created as a clone of the system default blueprint. 1006 In both creation cases, the confResponse, for a successful completion 1007 of a "create" operation, contains a response-code of "200" and MUST 1008 contain the XCON-URI of the newly created conference in the 1009 "confObjID" parameter, in order to allow the conferencing client to 1010 manipulate that conference through following CCMP requests. In 1011 addition, the "confInfo" parameter transporting the created 1012 conference document MAY be included, at the discretion of the 1013 conferencing system implementation, along with an optional version 1014 parameter initialized at "1", since at creation time the conference 1015 object is at its first version. 1017 In the case of a confRequest with a "retrieve" operation, the 1018 "confObjID" representing the XCON-URI of the target conference MUST 1019 be included and the "confInfo" parameter MUST NOT be included in the 1020 request. The conferencing server MUST ignore any "confInfo" 1021 parameter that is received in a confRequest/retrieve. If the 1022 confResponse for the "retrieve" operation contains a "response-code" 1023 of "200", the "confInfo" parameter MUST be included in the response. 1024 The "confInfo" parameter MUST contain the entire conference document 1025 describing the target conference object in its current state. The 1026 current state of the retrieved conference object MUST also be 1027 reported in the proper "version" response parameter. 1029 In case of a confRequest with an "update" operation, the "confInfo" 1030 and "confObjID" MUST be included in the request. The "confInfo" 1031 represents an object of type "conference-type" containing all the 1032 changes to be applied to the conference whose identifier is 1033 "confObjID". Note that, in such a case, though the confInfo 1034 parameter has indeed to follow the rules indicated in the XCON data 1035 model, it does not represent the entire updated version of the target 1036 conference, since it rather conveys just the modifications to apply 1037 to that conference. For example, in order to change the conference 1038 title, the confInfo parameter will be of the form: 1040 1041 1042 *** NEW CONFERENCE TITLE *** 1043 1044 1046 Figure 7: Updating a conference object: modifying the title of a 1047 conference 1049 Similarly, to remove the title of an existing conference, a 1050 confRequest/update carrying the following "confInfo" parameter would 1051 do the job.: 1053 1054 1055 1056 1057 1059 Figure 8: Updating a conference object: removing the title of a 1060 conference 1062 In the case of a confResponse/update with a response-code of "200", 1063 no additional information is required in the response message, which 1064 means the return of confInfo parameter is not mandatory. A following 1065 confRequest/retrieve transaction might provide the CCMP client with 1066 the current aspect of the conference upon the modification, or the 1067 Notification Protocol might address that task as well. A "200" 1068 response-code indicates that the referenced conference document has 1069 been changed accordingly to the request by the conferencing server. 1070 The "version" parameter MUST be enclosed in the confResponse/update 1071 message, in order to let the client understand what is the actual 1072 current conference-object version, upon the applied modifications. 1073 An "409" response-code indicates that the changes reflected in the 1074 request "confInfo" are not feasible. This could be due to policies, 1075 requestor roles, specific privileges, unacceptable values etc., with 1076 the reason specific to a conferencing system and its configuration. 1077 Together with the "409" response-code, the "version" parameter MUST 1078 be attached in the confResponse/update, by this way allowing the 1079 client to eventually retrieve the current version of the target 1080 conference if the one she attempted to modify was not the most up-to- 1081 date. 1083 In the case of a confRequest with a "delete" operation, the 1084 "confObjID" representing the XCON-URI of the target conference MUST 1085 be included while the "confInfo" MUST NOT be included in the request. 1086 The conferencing server MUST ignore any "confInfo" parameter that is 1087 received within such a request. The confResponse MUST contain the 1088 same "confObjID" that was included in the confRequest. If the 1089 confResponse/delete operation contains a "200" response-code, the 1090 conference indicated in the "confObjID" has been successfully 1091 deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" 1092 parameter. The "version" parameter SHOULD NOT be returned in any 1093 confResponse/delete. If the conferencing server cannot delete the 1094 conference referenced by the "confObjID" received in the confRequest 1095 because it is the parent of another conference object that is in use, 1096 the conferencing server MUST return a response-code of "425". 1098 A confRequest with an "operation" of "retrieve", "update" or "delete" 1099 carrying a "confObjID" which is not associated with one of the 1100 conferences (active or registered) the system is holding will 1101 generate, on the server's side, a confResponse message containing a 1102 "404" error code. This holds also for the case in which the 1103 mentioned "confObjID" is related to an existing conference object 1104 stored at the server, but associated with a blueprint or with a 1105 sidebar rather than an actual conference. 1107 The schema for the confRequest/confResponse pair is shown in 1108 Figure 9. 1110 1112 1113 1114 1115 1116 1117 1118 1119 1120 1122 1124 1126 1127 1128 1130 1132 1133 1134 1136 1138 1139 1140 1141 1142 1143 1144 1145 1146 1148 1150 1152 1153 1154 1156 1158 1159 1160 1161 Figure 9: Structure of the confRequest and confResponse messages 1163 5.3.5. usersRequest and usersResponse 1165 Through a "usersRequest" message the CCMP client manipulates the XML 1166 element of the conference document associated with the 1167 conference identified by the "confObjID" parameter complusory 1168 included in the request. Inside the element, along with the 1169 list of elements associated with conference participants, 1170 there is information that the client may be interested in 1171 controlling, such the list of the users to which access to the 1172 conference is allowed/denied, conference participation policies, 1173 etc.; for this reason, a customized message has been designed to 1174 allow for the manipulation of this specific part of a conference 1175 document. 1177 A "usersInfo" parameter MAY be included in a usersRequest message 1178 depending upon the operation. If the "usersInfo" parameter is 1179 included in the usersRequest message, the parameter MUST be compliant 1180 with the field of the XCON data model. 1182 Two operations are allowed for a "usersRequest" message: 1183 1. "retrieve": In this case the request MUST NOT include a 1184 "usersInfo" parameter, while the successful response MUST contain 1185 the desired element in the "usersInfo" parameter. The 1186 conference server MUST ignore a "usersInfo" parameter if it is 1187 received in a request with a "retrieve" operation. 1188 2. update: In this case, the "usersInfo" parameter MUST contain the 1189 modifications to be applied to the referred element. If 1190 the "response-code" is "200", then the "usersInfo" parameter 1191 SHOULD NOT be returned. Any "usersInfo" parameter that is 1192 returned SHOULD be ignored. A "response-code" of "426" indicates 1193 that the conferencing client is not allowed to make the changes 1194 reflected in the "usersInfo" contained in the usersRequest 1195 message. This could be due to policies, roles, specific 1196 privileges, etc., with the reason specific to a conferencing 1197 system and its configuration. 1199 Operations of "create" and "delete" are not applicable to a 1200 usersRequest message and MUST NOT be considered by the server, which 1201 means that a "response-code" of "403" MUST be included in the 1202 usersResponse message. 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1215 1217 1219 1220 1221 1223 1225 1226 1227 1229 1231 1232 1233 1234 1235 1236 1237 1238 1239 1241 1243 1245 1246 1247 1249 1251 1252 1254 1256 Figure 10: Structure of the usersRequest and usersResponse messages 1258 5.3.6. userRequest and userResponse 1260 A "userRequest" message is used to manipulate elements inside 1261 a conference document associated with a conference identified by the 1262 "confObjID" parameter. Besides retrieving information about a 1263 specific conference user, the message is used to request that the 1264 conference server either create, modify, or delete information about 1265 a user. A "userRequest" message MUST include the "confObjID", the 1266 "operation" parameter, and MAY include a "userInfo" parameter 1267 containing the detailed user's information depending upon the 1268 operation and whether the "userInfo" has already been populated for a 1269 specific user. Note that a user may not necessarily be a 1270 conferencing control client (i.e., some participants in a conference 1271 are not "XCON aware"). 1273 An XCON-USERID SHOULD be assigned to each and every user subscribed 1274 to the system. In such a way, a user who is not a conference 1275 participant can make requests (provided she has successfully passed 1276 AAA checks), like creating a conference, retrieving conference 1277 information, etc.. 1279 Conference users can be created in a number of different ways. In 1280 each of these cases the operation MUST be set to "create" in the 1281 userRequest message. Each of the userResponse messages for these 1282 cases MUST include the "confObjID", "confUserID", "operation" and 1283 "response-code" parameters. In the case of a response code of "200", 1284 the userResponse message MAY include the "userInfo" parameter 1285 depending upon the manner in which the user was created: 1287 o Conferencing client with an XCON-USERID adds itself to the 1288 conference: In this case, the "userInfo" parameter MAY be included 1289 in the userRequest. The "userInfo" parameter MUST contain a 1290 element (compliant with the XCON data model) and the 1291 "entity" attribute MUST be set to a value which represents the 1292 XCON-USERID of the user initiating the request. No additional 1293 parameters beyond those previously described are required in the 1294 userResponse message, in the case of a "response-code" of "200". 1295 o Conferencing client acts on behalf of a third user whose XCON- 1296 USERID is known: in this case, the "userInfo" parameter MUST be 1297 included in the userRequest. The "userInfo" parameter MUST 1298 contain a element and the "entity" attribute value MUST be 1299 set to the XCON-USERID of the third user in question. No 1300 additional parameters beyond those previously described are 1301 required in the userResponse message, in the case of a "response- 1302 code" of "200". 1303 o A conferencing client who has no XCON-USERID and who wants to 1304 enter, via CCMP, a conference whose identifier is known. In such 1305 case, a side-effect of the request is that the user is provided 1306 with a new XCON-USERID (created by the server) carried inside the 1307 "confUserID" parameter of the response. This is the only case in 1308 which a CCMP request can be valid though carrying a void 1309 "confUserID" parameter. A "userInfo" parameter MUST be enclosed 1310 in the request, providing at least a contact URI of the joining 1311 client, in order to let the focus instigate the signaling phase 1312 needed to add her to the conference. The mandatory "entity" 1313 attribute of the "userInfo" parameter in the request is filled 1314 with a dummy value recognizable on the server side, so to conform 1315 to the rules contained in the XCON data model XML schema. The 1316 involved messages (userRequest and userResponse) in such case 1317 should look like the following: 1319 Request fields: 1321 confUserID=null; 1322 confObjID=confXYZ; 1323 operation=create; 1324 userInfo= 1326 1327 1328 ... 1330 Response fields (in case of success): 1332 confUserID=user345; 1333 confObjID=confXYZ; 1334 operation=create; 1335 response-code=200; 1336 userInfo=null; //or the entire userInfo object 1338 Figure 11: userRequest and userResponse in the absence of an xcon- 1339 userid 1341 o Conferencing client is unaware of the XCON-USERID of a third user: 1342 In this case, the XCON-USERID in the request "confUserID" is the 1343 sender's one and the "entity" attribute of the attached userInfo 1344 is filled with the pre-defined fake value 1345 "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the 1346 third user MUST be returned to the client issuing the request in 1347 the "entity" attribute of the response "userInfo" parameter, if 1348 the "response-code" is "200". [RP] This scenario is intended to 1349 support both the case where a brand new conferencing system user 1350 is added to a conference by a third party (i.e. a user who is not 1351 yet provided with an XCON-USERID) and the case where the CCMP 1352 client issuing the request does not know the to-be-added user's 1353 XCON-USERID (which means such an identifier could already exist on 1354 the server's side for that user). In this last case, the 1355 conferencing server is in charge of avoiding XCON-URI duplicates 1356 for the same conferencing client, looking at key fields in the 1357 request provided "userInfo" parameter, such as the signalling URI: 1358 if the joining user is a brand new one, then the generation of a 1359 new XCON identifier is needed; otherwise, if that user is an 1360 existing one, the server must recover the corresponding XCON 1361 identifier. 1363 In the case of a userRequest with a "retrieve" operation, the 1364 "confObjID" representing the XCON-URI of the target conference MUST 1365 be included. The "confUserID", containing the CCMP client's xcon- 1366 userid, MUST also be included in the userRequest message. If the 1367 client wants to retrieve information about her profile in the 1368 specified conference, no "userInfo" parameter is needed in the 1369 retrieve request. On the other hand, if the client wants to obtain 1370 someone else's info within the given conference, she MUST include in 1371 the userRequest/retrieve a "userInfo" parameter whose "entity" 1372 attribute conveys the desired user's xcon-userid. If the 1373 userResponse for the "retrieve" operation contains a "response-code" 1374 of "200", the "userInfo" parameter MUST be included in the response. 1376 In case of a userRequest with an "update" operation, the "confObjID", 1377 "confUserID" and "userInfo" MUST be included in the request. The 1378 "userInfo" is of type "user-type" and contains all the changes to be 1379 applied to a specific element in the conference object 1380 identified by the "confObjID" in the userRequest message. The user 1381 to be modified is identified through the "entity" attribute of the 1382 "userInfo" parameter included in the request. In the case of a 1383 userResponse with a "response-code" of "200", no additional 1384 information is required in the "userResponse" message. A "response- 1385 code" of "200" indicates that the referenced user element has been 1386 updated by the conference server. A "response-code" of "426" 1387 indicates that the conferencing client is not allowed to make the 1388 changes reflected in the "userInfo" in the initial request. This 1389 could be due to policies, roles, specific privileges, etc., with the 1390 reason specific to a conferencing system and its configuration. 1392 In the case of a userRequest with a "delete" operation, the 1393 "confObjID" representing the XCON-URI of the target conference MUST 1394 be included. The "confUserID", containing the CCMP client's xcon- 1395 userid, MUST be included in the userRequest message. If the client 1396 wants to exit the specified conference, no "userInfo" parameter is 1397 needed in the delete request. On the other hand, if the client wants 1398 to remove another participant from the given conference, she MUST 1399 include in the userRequest/delete a "userInfo" parameter whose 1400 "entity" attribute conveys the xcon-userid of that participant. The 1401 userResponse MUST contain the same "confObjID" that was included in 1402 the userRequest. The userResponse MUST contain a "response-code" of 1403 "200" if the target element has been successfully deleted. If 1404 the userResponse for the "delete" operation contains a "response- 1405 code" of "200", the userResponse MUST NOT contain the "userInfo" 1406 parameter. 1408 1410 1411 1412 1413 1414 1415 1416 1417 1418 1420 1422 1424 1425 1426 1428 1430 1431 1432 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1445 1447 1449 1450 1451 1453 1455 1456 1457 1459 Figure 12: Structure of the userRequest and userResponse messages 1461 5.3.7. sidebarsByValRequest and sidebarsByValResponse 1463 A "sidebarsByValRequest" is used to execute a retrieve-only operation 1464 on the field of the conference object represented 1465 by the "confObjID". The "sidebarsByValRequest" message is of a 1466 "retrieve-only" type, so an "operation" parameter MUST NOT be 1467 included in a "sidebarsByValRequest" message. As with blueprints and 1468 conferences, also with sidebars, CCMP allows for the use of xpath 1469 filters whenever a selected subset of the sidebars available at the 1470 server's side has to be retrieved by the client. This applies both 1471 to sidebars by reference and to sidebars by value. A 1472 "sidebarsByValResponse" with a "response-code" of "200" MUST contain 1473 a "sidebarsByValInfo" parameter containing the desired element. A "sidebarsByValResponse" message MUST carry back to 1475 the client a "version" element related to the current version of the 1476 main conference object (i.e. the one whose identifier is contained in 1477 the "confObjId" field of the request) to which the sidebars in 1478 question are associated. The "sidebarsByValInfo" parameter contains 1479 the list of the conference objects associated with the sidebars by 1480 value derived from the main conference. The retrieved sidebars can 1481 then be updated or deleted using the "sidebarByValRequest" message, 1482 which is described in Section 5.3.8. 1484 1486 1487 1488 1489 1490 1491 1492 1493 1494 1496 1498 1501 1502 1503 1504 1506 1507 1508 1510 1512 1513 1514 1515 1516 1517 1518 1519 1520 1522 1524 1527 1528 1529 1531 1533 1534 1535 1537 Figure 13: Structure of the sidebarsByValRequest and 1538 sidebarsByValResponse messages 1540 5.3.8. sidebarByValRequest and sidebarByValResponse 1542 A sidebarByValRequest message MUST contain the "operation" parameter 1543 which discriminates among retrieval, creation, modification and 1544 deletion of a specific sidebar. The other required parameters depend 1545 upon the type of operation. 1547 In the case of a "create" operation, the "confObjID" parameter MUST 1548 be included in the sidebyValRequest message. In this case, the 1549 "confObjID" parameter contains the XCON-URI of the main conference in 1550 which the sidebar has to be created. If no "sidebarByValInfo" 1551 parameter is included, as envisaged in the XCON framework 1552 ([RFC5239]), the sidebar is created by cloning the main conference, 1553 following the implementation specific cloning rules. Otherwise, 1554 similarly to the case of direct creation, the sidebar conference 1555 object is built on the basis of the "sidebarByValInfo" parameter 1556 provided by the requestor. As a consequence of a sidebar-by-val 1557 creation, the conference server MUST update the main conference 1558 object reflected by the "confObjID" parameter in the 1559 sidebarbyValRequest/create message introducing the new sidebar object 1560 as a new new in the proper section . The 1561 newly created sidebar conference object MAY be included in the 1562 sidebarByValResponse in the "sidebarByValInfo" parameter, if the 1563 "response-code" is "200". The XCON-URI of the newly created sidebar 1564 MUST appear in the "confObjID" parameter of the response. The 1565 conference server can notify any conferencing clients that have 1566 subscribed to the conference event package, and are authorized to 1567 receive the notifications, of the addition of the sidebar to the 1568 conference. 1570 In the case of a "sidebarByVal" request with an operation of 1571 "retrieve", the URI for the conference object created for the sidebar 1572 (received in the response to a "create" operation or in a 1573 sidebarsByValResponse message) MUST be included in the "confObjID" 1574 parameter in the request. This "retrieve" operation is handled by 1575 the conference server in the same manner as a "retrieve" operation 1576 included in a confRequest message as detailed in Section 5.3.4. 1578 In the case of a "sidebarByVal" request with an operation of 1579 "update", the "sidebarByValInfo" MUST also be included in the 1580 request. The "confObjID" parameter contained in the request message 1581 identifies the specific sidebar instance to be updated. An "update" 1582 operation on the "sidebarByValInfo" is handled by the conference 1583 server in the same manner as an "update" operation on the confInfo 1584 included in a confRequest message as detailed in Section 5.3.4. A 1585 "sidebarByValResponse" message MUST carry back to the client a 1586 "version" element related to the current version of the sidebar whose 1587 identifier is contained in the "confObjId" field of the request. 1589 If an "operation" of "delete" is included in the sidebarByVal 1590 request, the "sidebarByValInfo" parameter MUST NOT be included in the 1591 request. Any "sidebarByValInfo" included in the request MUST be 1592 ignored by the conference server. The URI for the conference object 1593 associated with the sidebar MUST be included in the "confObjID" 1594 parameter in the request. If the specific conferencing user as 1595 reflected by the "confUserID" in the request is authorized to delete 1596 the conference, the conference server deletes the conference object 1597 reflected by the "confObjID" parameter and updates the data in the 1598 conference object from which the sidebar was cloned. The conference 1599 server can notify any conferencing clients that have subscribed to 1600 the conference event package, and are authorized to receive the 1601 notifications, of the deletion of the sidebar to the conference. 1603 If a sidebarByValRequest with an "operation" of "retrieve", "update" 1604 or "delete" carries a "confObjID" which is not associated with any 1605 existing sidebar-by-val, a confResponse message containing a "404" 1606 error code will be generated on the server's side. This holds also 1607 for the case in which the mentioned "confObjID" is related to an 1608 existing conference object stored at the server, but associated with 1609 a blueprint or with an actual conference or with a sidebar-by-ref 1610 rather than a sidebar-by-val. 1612 1614 1615 1616 1617 1618 1619 1621 1622 1623 1625 1627 1630 1631 1632 1634 1636 1637 1638 1640 1642 1643 1644 1645 1646 1647 1648 1649 1650 1652 1654 1657 1658 1659 1661 1663 1664 1665 1666 Figure 14: Structure of the sidebarByValRequest and 1667 sidebarByValResponse messages 1669 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse 1671 Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be 1672 invoked to retrieve the element of the conference 1673 object identified by the "confObjID" parameter. The 1674 "sidebarsByRefRequest" message is of a "retrieve-only" type, so an 1675 "operation" parameter MUST NOT be included in a 1676 "sidebarsByRefRequest" message. In the case of a "response-code" of 1677 "200", the "sidebarsByRefInfo" parameter, containing the element of the conference object, MUST be included in the 1679 response. The element represents the set of URIs 1680 of the sidebars associated with the main conference, whose 1681 description (in the form of a standard XCON conference document) is 1682 external to the main conference itself. Through the retrieved URIs, 1683 it is then possible to access single sidebars using the 1684 "sidebarByRef" request message, described in Section 5.3.10. A 1685 "sidebarsByRefResponse" message MUST carry back to the client a 1686 "version" element related to the current version of the main 1687 conference object (i.e. the one whose identifier is contained in the 1688 "confObjId" field of the request) to which the sidebars in question 1689 are associated. 1691 1693 1694 1695 1696 1697 1698 1699 1700 1701 1703 1705 1708 1709 1710 1711 1713 1714 1715 1717 1719 1720 1721 1722 1723 1724 1725 1726 1727 1729 1731 1734 1735 1736 1738 1740 1741 1742 1744 Figure 15: Structure of the sidebarsByRefRequest and 1745 sidebarsByRefResponse messages 1747 5.3.10. sidebarByRefRequest and sidebarByRefResponse 1749 A sidebarByRefRequest message MUST contain the "operation" parameter 1750 which discriminates among retrieval, creation, modification and 1751 deletion of a specific sidebar. The other required parameters depend 1752 upon the type of operation. 1754 In the case of a "create" operation, the "confObjID" parameter MUST 1755 be included in the sidebyRefRequest message. In this case, the 1756 "confObjID" parameter contains the XCON-URI of the main conference in 1757 which the sidebar has to be created. If no "sidebarByRefInfo" 1758 parameter is included, as envisaged in the XCON framework 1759 ([RFC5239]), the sidebar is created by cloning the main conference, 1760 following the implementation specific cloning rules. Otherwise, 1761 similarly to the case of direct creation, the sidebar conference 1762 object is built on the basis of the "sidebarByRefInfo" parameter 1763 provided by the requestor. If the creation of the sidebar is 1764 successful, the conference server MUST update the "sidebars-by-ref" 1765 element in the conference object from which the sidebar was created 1766 (i.e., as identified by the "confObjID" in the original sidebarByRef 1767 request), with the URI of the newly created sidebar. The newly 1768 created conference object MAY be included in the response in the 1769 "sidebarByRefInfo" parameter with a "response-code" of "200". The 1770 URI for the conference object associated with the newly created 1771 sidebar object MUST appear in the "confObjID" parameter of the 1772 response. The conference server can notify any conferencing clients 1773 that have subscribed to the conference event package, and are 1774 authorized to receive the notifications, of the addition of the 1775 sidebar to the conference. 1777 In the case of a "sidebarByRef" request with an operation of 1778 "retrieve", the URI for the conference object created for the sidebar 1779 MUST be included in the "confObjID" parameter in the request. A 1780 "retrieve" operation on the "sidebarByRefInfo" is handled by the 1781 conference server in the same manner as a "retrieve" operation on the 1782 confInfo included in a confRequest message as detailed in 1783 Section 5.3.4. 1785 In the case of a "sidebarByRef" request with an operation of 1786 "update", the URI for the conference object created for the sidebar 1787 MUST be included in the "confObjID" parameter in the request. The 1788 "sidebarByRefInfo" MUST also be included in the request in the case 1789 of an "operation" of "update". An "update" operation on the 1790 "sidebarByRefInfo" is handled by the conference server in the same 1791 manner as an "update" operation on the confInfo included in a 1792 confRequest message as detailed in Section 5.3.4. A 1793 "sidebarByRefResponse" message MUST carry back to the client a 1794 "version" element related to the current version of the sidebar whose 1795 identifier is contained in the "confObjId" field of the request. 1797 If an "operation" of "delete" is included in the sidebarByRef 1798 request, the "sidebarByRefInfo" parameter MUST NOT be included in the 1799 request. Any "sidebarByRefInfo" included in the request MUST be 1800 ignored by the conference server. The URI for the conference object 1801 for the sidebar MUST be included in the "confObjID" parameter in the 1802 request. If the specific conferencing user as reflected by the 1803 "confUserID" in the request is authorized to delete the conference, 1804 the conference server SHOULD delete the conference object reflected 1805 by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" 1806 element in the conference object from which the sidebar was 1807 originally cloned. The conference server can notify any conferencing 1808 clients that have subscribed to the conference event package, and are 1809 authorized to receive the notifications, of the deletion of the 1810 sidebar. 1812 If a sidebarByRefRequest with an "operation" of "retrieve", "update" 1813 or "delete" carries a "confObjID" which is not associated with any 1814 existing sidebar-by-ref, a confResponse message containing a "404" 1815 error code will be generated on the server's side. This holds also 1816 for the case in which the mentioned "confObjID" is related to an 1817 existing conference object stored at the server, but associated with 1818 a blueprint or with an actual conference or with a sidebar-by-val 1819 rather than a sidebar-by-ref. 1821 1823 1824 1825 1826 1827 1828 1829 1830 1831 1833 1835 1838 1839 1840 1842 1844 1845 1846 1848 1850 1851 1852 1853 1854 1855 1856 1857 1858 1860 1862 1865 1866 1867 1869 1871 1872 1873 1875 Figure 16: Structure of the sidebarByRefRequest and 1876 sidebarByRefResponse messages 1878 5.4. CCMP Response Codes 1880 All CCMP response messages MUST include a ""response-code"". The 1881 following summarizes the CCMP response codes: 1883 200 Success: Successful completion of the requested operation. 1884 400 Bad Request: Syntactically malformed request. 1885 401 Unauthorized: User not allowed to perform the required 1886 operation. 1887 403 Forbidden: Operation not allowed (e.g., cancellation of a 1888 blueprint). 1889 404 Object Not Found: Target conference object missing at the server 1890 (it refers to the "confObjID" parameter in the generic request 1891 message) 1892 409 Conflict: A generic error associated with all those situations 1893 in which a requested client operation cannot be successfully 1894 completed by the server. An example of such situation is when the 1895 modification of an object cannot be applied due to conflicts 1896 arising at the server's side, e.g. because the client version of 1897 the object is an obsolete one and the requested modifications 1898 collide with the up-to-date state of the object stored at the 1899 server. Such code would also be used if a client attempts to 1900 create an object (conference or user) with an entity that already 1901 exists. 1902 420 User Not Found: Target user missing at the server (it is related 1903 to the XCON-USERID in the "entity" attribute of the "userInfo" 1904 parameter when it is included in userRequests) 1905 421 Invalid confUserID: User missing at the server (this code is 1906 returned in the case of requests in which the "confUserID" of the 1907 sender is invalid). 1908 422 Invalid Conference Password: Target conference object's password 1909 contained in the request is wrong. 1910 423 Conference Password Required: "conference-password" missing in a 1911 request to access a password-protected conference object. 1912 424 Authentication Required: User's authentication information 1913 missing in a request to perform the requested operation. "subject" 1914 parameter needed in the request. 1915 425 Forbidden Delete Parent: Cancel operation failed since the 1916 target object is a parent of child objects which depend on it, or 1917 because it effects, based on the "parent-enforceable" mechanism, 1918 the corresponding element in a child object. 1919 426 Forbidden Change Protected: Update refused by the server because 1920 the target element cannot be modified due to its implicit 1921 dependence on the value of a parent object ("parent-enforceable" 1922 mechanism). 1923 500 Server Internal Error: The server cannot complete the required 1924 service due to a system internal error. 1925 501 Not Implemented: Operation envisaged in the protocol, but not 1926 implemented in the contacted server. 1927 510 Request Timeout: The time required to serve the request has 1928 exceeded the envisaged service threshold. 1929 511 Resources Not Available: This code is used when the CCMP server 1930 cannot execute a command because of resource issues, e.g. it 1931 cannot create a sub conference because the system has reached its 1932 limits on the number of sub conferences, or if a request for 1933 adding a new user fails because the max number of users has been 1934 reached for the conference or the max number of users has been 1935 reached for the conferencing system. 1937 The handling of a "response-code" of "404", "409", "420", "421", 1938 "425" and "426" are only applicable to specific operations for 1939 specialized message responses and the details are provided in 1940 Section 5.3. The following table summarizes these response codes and 1941 the specialized message and operation to which they are applicable: 1943 +---------------+------------+------------+------------+------------+ 1944 | Response code | Create | Retrieve | Update | Delete | 1945 +---------------+------------+------------+------------+------------+ 1946 | 404 | userReques | All | All update | All delete | 1947 | | t, | retrieve | requests | requests | 1948 | | sidebarBy | requests, | | | 1949 | | ValRequest | EXCEPT: | | | 1950 | | sidebars | blueprints | | | 1951 | | ByRefReque | Request, | | | 1952 | | st | confsRequ | | | 1953 | | | est | | | 1954 | ------------- | ---------- | ---------- | ---------- | ---------- | 1955 | 409 | N/A | N/A | All update | N/A | 1956 | | | | requests | | 1957 | ------------- | ---------- | ---------- | ---------- | ---------- | 1958 | 420 | userReques | userReques | userReques | userReques | 1959 | | t(3rd part | t | t | t | 1960 | | yinvite | | | | 1961 | | with thir | | | | 1962 | | duser | | | | 1963 | | entity) | | | | 1964 | | (*) | | | | 1965 | ------------- | ---------- | ---------- | ---------- | ---------- | 1966 | 421 | All create | All | All update | All delete | 1967 | | requests, | retrieve | requests | requests | 1968 | | EXCEPT: | requests | | | 1969 | | userReques | | | | 1970 | | twith no | | | | 1971 | | confUserI | | | | 1972 | | D(**) | | | | 1973 | ------------- | ---------- | ---------- | ---------- | ---------- | 1974 | 425 | N/A | N/A | N/A | All delete | 1975 | | | | | request | 1976 | ------------- | ---------- | ---------- | ---------- | ---------- | 1977 | 426 | N/A | N/A | All update | N/A | 1978 | | | | requests | | 1979 +---------------+------------+------------+------------+------------+ 1981 Table 2: Response codes and associated operations 1983 (*) "420" in answer to a "userRequest/create" operation: in the case 1984 of a third-party invite, this code can be returned if the 1985 "confUserID" (contained in the "entity" attribute of the "userInfo" 1986 parameter) of the user to be added is unknown. In the case above, if 1987 instead it is the "confUserID" of the sender of the request that is 1988 invalid, a "421" error code is returned to the client. 1990 (**) "421" is not sent in answers to "userRequest/create" messages 1991 having a "null" confUserID, since this case is associated with a user 1992 who is unaware of his own XCON-USERID, but wants to enter a known 1993 conference. 1995 In the case of a response code of "510", a conferencing client MAY 1996 re-attempt the request within a period of time that would be specific 1997 to a conference control client or conference control server. 1999 A response code of "400" indicates that the conference control client 2000 sent a malformed request, which is indicative of an error in the 2001 conference control client or in the conference control server. The 2002 handling is specific to the conference control client implementation 2003 (e.g., generate a log, display an error message, etc.). It is NOT 2004 RECOMMENDED that the client re-attempt the request in this case. 2006 Response codes such as "401" and "403" indicate the client does not 2007 have the appropriate permissions, or there is an error in the 2008 permissions: re-attempting the request would likely not succeed and 2009 thus it is NOT RECOMMENDED. 2011 Any unexpected or unknown "response-code" SHOULD be treated by the 2012 client in the same manner as a "500" "response-code", the handling of 2013 which is specific to the conference control client implementation. 2015 6. A complete example of the CCMP in action 2017 In this section a typical, not normative, scenario in which the CCMP 2018 comes into play is described, by showing the actual composition of 2019 the various CCMP messages. In the call flows of the example, the 2020 Conference Control Client is a CCMP-enabled client, whereas the 2021 Conference Control Server is a CCMP-enabled server. The "confUserID" 2022 of the client, Alice, is "xcon-userid:Alice@example.com" and appears 2023 in all requests. The sequence of operations is as follows: 2025 1. Alice retrieves from the server the list of available blueprints 2026 (Section 6.1); 2027 2. Alice asks for detailed information about a specific blueprint 2028 (Section 6.2); 2029 3. Alice decides to create a new conference by cloning the retrieved 2030 blueprint (Section 6.3); 2031 4. Alice modifies information (e.g. XCON-URI, name, description) 2032 associated with the newly created blueprint (Section 6.4); 2033 5. Alice specifies a list of users to be contacted when the 2034 conference is activated (Section 6.5); 2035 6. Alice joins the conference (Section 6.6); 2036 7. Alice lets a new user, Ciccio, (whose "confUserID" is 2037 "xcon-userid:Ciccio@example.com") join the conference 2038 (Section 6.7). 2040 Note, the examples do not include any details beyond the basic 2041 operation. 2043 In the following sections we deal with each of the above mentioned 2044 actions separately. 2046 6.1. Alice retrieves the available blueprints 2048 This section illustrates the transaction associated with retrieval of 2049 the blueprints, together with a dump of the two messages exchanged 2050 ("blueprintsRequest" and "blueprintsResponse"). As it comes out from 2051 the figure, the "blueprintsResponse" message contains, in the 2052 "blueprintsInfo" parameter, information about the available 2053 blueprints, in the form of the standard XCON-URI of the blueprint, 2054 plus additional (and optional) information, like its display-text and 2055 purpose. 2057 Alice retrieves from the server the list of available blueprints: 2059 CCMP Client CCMP Server 2060 | | 2061 | CCMP blueprintsRequest message | 2062 | - confUserID: Alice | 2063 | - confObjID: (null) | 2064 |------------------------------------------------------>| 2065 | | 2066 | CMP blueprintsResponse message | 2067 | - confUserID: Alice | 2068 | - confObjID: (null) | 2069 | - response-code: 200 | 2070 | - blueprintsInfo: bp123,bp124,.. | 2071 |<------------------------------------------------------| 2072 | | 2073 . . 2074 . . 2076 1. blueprintsRequest message: 2078 2079 2082 2084 xcon-userid:Alice@example.com 2085 2086 2088 2. blueprintsResponse message form the server: 2090 2091 2095 2098 xcon-userid:Alice@example.com 2099 200 2100 2101 2102 2103 xcon:AudioRoom@example.com 2104 AudioRoom 2105 Simple Room: 2106 conference room with public access, 2107 where only audio is available, more users 2108 can talk at the same time 2109 and the requests for the AudioFloor 2110 are automatically accepted. 2111 2112 2113 2114 xcon:VideoRoom@example.com 2115 VideoRoom 2116 Video Room: 2117 conference room with public access, 2118 where both audio and video are available, 2119 8 users can talk and be seen at the same time, 2120 and the floor requests are automatically accepted. 2121 2122 2123 2124 xcon:AudioConference1@example.com 2125 AudioConference1 2126 Public Audio Conference: 2127 conference with public access, 2128 where only audio is available, 2129 only one user can talk at the same time, 2130 and the requests for the AudioFloor MUST 2131 be accepted by a Chair. 2132 2133 2134 2135 xcon:VideoConference1@example.com 2136 VideoConference1 2137 Public Video Conference: conference 2138 where both audio and video are available, 2139 only one user can talk 2140 2141 2142 2143 xcon:AudioConference2@example.com 2144 AudioConference2 2145 Basic Audio Conference: 2146 conference with private access, 2147 where only audio is available, 2148 only one user can talk at the same time, 2149 and the requests for the AudioFloor MUST 2150 be accepted by a Chair. 2151 2152 2153 2154 2155 2156 2158 Figure 17: Getting blueprints from the server 2160 6.2. Alice gets detailed information about a specific blueprint 2162 This section illustrates the second transaction in the overall flow. 2163 In this case, Alice, who now knows the XCON-URIs of the blueprints 2164 available at the server, makes a drill-down query, in the form of a 2165 CCMP "blueprintRequest" message, to get detailed information about 2166 one of them (the one called with XCON-URI 2167 "xcon:AudioRoom@example.com"). The picture shows such transaction. 2168 Notice that the response contains, in the "blueprintInfo" parameter, 2169 a document compliant with the standard XCON data model. 2171 Alice retrieves detailed information about a specified blueprint: 2173 CCMP Client CCMP Server 2174 | | 2175 | CCMP blueprintRequest message | 2176 | - confUserID: Alice | 2177 | - confObjID: bp123 | 2178 | - operation: retrieve | 2179 | - blueprintInfo: (null) | 2180 |------------------------------------------------------>| 2181 | | 2182 | CCMP blueprintResponse message | 2183 | - confUserID: Alice | 2184 | - confObjID: bp123 | 2185 | - operation: retrieve | 2186 | - response-code: 200 | 2187 | - blueprintInfo: bp123Info | 2188 |<------------------------------------------------------| 2189 | | 2190 . . 2191 . . 2193 1. blueprintRequest message: 2195 2196 2200 2202 xcon-userid:Alice@example.com 2203 xcon:AudioRoom@example.com 2204 retrieve 2205 2206 2207 2209 2. blueprintResponse message form the server: 2211 2212 2216 2218 xcon-userid:Alice@example.com 2219 xcon:AudioRoom@example.com 2220 retrieve 2221 200 2222 2223 2224 2225 AudioRoom 2226 2 2227 2228 2229 audio 2230 2231 2232 2233 2234 allow 2235 2236 2237 confirm 2238 2239 2240 2241 2242 2243 2244 2245 2246 2248 Figure 18: Getting info about a specific blueprint 2250 6.3. Alice creates a new conference through a cloning operation 2252 This section illustrates the third transaction in the overall flow. 2253 Alice decides to create a new conference by cloning the blueprint 2254 having XCON-URI "xcon:AudioRoom@example.com", for which she just 2255 retrieved detailed information through the "blueprintRequest" 2256 message. This is achieved by sending a "confRequest/create" message 2257 having the blueprint's URI in the "confObjID" parameter. The picture 2258 shows such transaction. Notice that the response contains, in the 2259 "confInfo" parameter, the document associated with the newly created 2260 conference, which is compliant with the standard XCON data model. 2261 The "confObjID" in the response is set to the XCON-URI of the new 2262 conference (in this case, "xcon:8977794@example.com"). We also 2263 notice that this value is equal to the value of the "entity" 2264 attribute of the element of the document 2265 representing the newly created conference object. 2267 Alice creates a new conference by cloning the 2268 "xcon:AudioRoom@example.com" blueprint: 2270 CCMP Client CCMP Server 2271 | | 2272 | CCMP confRequest message | 2273 | - confUserID: Alice | 2274 | - confObjID: AudioRoom | 2275 | - operation: create | 2276 | - confInfo: (null) | 2277 |------------------------------------------------------>| 2278 | | 2279 | CCMP confResponse message | 2280 | - confUserID: Alice | 2281 | - confObjID: newConfId | 2282 | - operation: create | 2283 | - response-code: 200 | 2284 | - version: 1 | 2285 | - confInfo: newConfInfo | 2286 |<------------------------------------------------------| 2287 | | 2288 . . 2289 . . 2291 1. confRequest message: 2293 2294 2298 2301 xcon-userid:Alice@example.com 2302 xcon:AudioRoom@example.com 2303 create 2304 2305 2306 2308 2. confResponse message from the server: 2310 2311 2315 2318 xcon-userid:Alice@example.com 2319 xcon:8977794@example.com 2320 create 2321 200 2322 1 2323 2324 2325 2326 2327 New conference by Alice cloned from AudioRoom 2328 2329 2330 2331 2332 xcon:8977794@example.com 2333 2334 2335 conference xcon-uri 2336 2337 2338 8601 2339 2340 2341 2342 10 2343 2344 2345 audio 2346 2347 2348 2349 2350 allow 2351 2352 2353 2354 confirm 2355 2356 2357 2358 2360 2361 2362 2363 2365 Figure 19: Creating a new conference by cloning a blueprint 2367 6.4. Alice updates conference information 2369 This section illustrates the fourth transaction in the overall flow. 2370 Alice decides to modify some of the details associated with the 2371 conference she just created. More precisely, she changes the 2372 element under the element of 2373 the document representing the conference. This is achieved through a 2374 "confRequest/update" message carrying the fragment of the conference 2375 document to which the required changes have to be applied. As shown 2376 in the picture, the response contains a code of "200", which 2377 acknowledges the modifications requested by the client, while also 2378 updating the conference version number from 1 to 2, as reflected in 2379 the "version" parameter. 2381 Alice updates information about the conference she just created: 2383 CCMP Client CCMP Server 2384 | | 2385 | CCMP confRequest message | 2386 | - confUserID: Alice | 2387 | - confObjID: 8977794 | 2388 | - operation: update | 2389 | - confInfo: confUpdates | 2390 |------------------------------------------------------>| 2391 | | 2392 | CCMP confResponse message | 2393 | - confUserID: Alice | 2394 | - confObjID: 8977794 | 2395 | - operation: update | 2396 | - response-code: 200 | 2397 | - version: 2 | 2398 | - confInfo: (null) | 2399 |<------------------------------------------------------| 2400 | | 2401 . . 2403 . . 2405 1. confRequest message: 2407 2408 2412 2415 xcon-userid:Alice@example.com 2416 xcon:8977794@example.com 2417 update 2418 2419 2420 2421 2422 Alice's conference 2423 2424 2425 2426 2427 2428 2430 2. confResponse message form the server: 2432 2433 2437 2439 xcon-userid:Alice@example.com 2440 xcon:8977794@example.com 2441 update 2442 200 2443 2 2444 2445 2446 2447 Figure 20: Updating conference information 2449 6.5. Alice inserts a list of users in the conference object 2451 This section illustrates the fifth transaction in the overall flow. 2452 Alice modifies the under the element in 2453 the document associated with the conference she created. To the 2454 purpose, she exploits the "usersRequest" message provided by the 2455 CCMP. The picture below shows the transaction. 2457 Alice updates information about the list of users to whom access to 2458 the conference is permitted: 2460 CCMP Client CCMP Server 2461 | | 2462 | CCMP usersRequest message | 2463 | - confUserID: Alice | 2464 | - confObjID: 8977794 | 2465 | - operation: update | 2466 | - usersInfo: usersUpdates | 2467 |------------------------------------------------------>| 2468 | | 2469 | CCMP usersResponse message | 2470 | - confUserID: Alice | 2471 | - confObjID: 8977794 | 2472 | - operation: update | 2473 | - response-code: 200 | 2474 | - version: 3 | 2475 | - usersInfo: (null) | 2476 |<------------------------------------------------------| 2477 | | 2478 . . 2479 . . 2481 1. usersRequest message: 2483 2484 2488 2490 xcon-userid:Alice@example.com 2491 xcon:8977794@example.com 2492 update 2493 2494 2495 2496 2498 2500 2502 2503 2504 2505 2506 2508 2. usersResponse message form the server: 2510 2511 2515 2517 xcon-userid:Alice@example.com 2518 xcon:8977794@example.com 2519 update 2520 200 2521 3 2522 2523 2524 2526 Figure 21: Updating the list of allowed users for the conference 2527 'xcon:8977794@example.com' 2529 6.6. Alice joins the conference 2531 This section illustrates the sixth transaction in the overall flow. 2532 Alice uses the CCMP to add herself to the newly created conference. 2533 This is achieved through a "userRequest/create" message containing, 2534 in the "userInfo" parameter, a element compliant with the XCON 2535 data model representation. Notice that such element includes 2536 information about the user's Address of Records, as well as her 2537 current end-point. The picture below shows the transaction. Notice 2538 how the "confUserID" parameter is equal to the "entity" attribute of 2539 the element, which indicates that the request issued by 2540 the client is a first-party one. 2542 Alice joins the conference by issuing a "userRequest/create" message 2543 with her own id to the server: 2545 CCMP Client CCMP Server 2546 | | 2547 | CCMP userRequest message | 2548 | - confUserID: Alice | 2549 | - confObjID: 8977794 | 2550 | - operation: create | 2551 | - userInfo: AliceUserInfo | 2552 |------------------------------------------------------>| 2553 | | 2554 | CCMP userResponse message | 2555 | - confUserID: Alice | 2556 | - confObjID: 8977794 | 2557 | - operation: create | 2558 | - response-code: 200 | 2559 | - version: 4 | 2560 | - userInfo: (null) | 2561 |<------------------------------------------------------| 2562 | | 2563 . . 2564 . . 2566 1. userRequest message: 2568 2569 2573 2575 xcon-userid:Alice@example.com 2576 xcon:8977794@example.com 2577 create 2578 2579 2580 2581 2582 2583 mailto:Alice83@example.com 2585 2586 email 2587 2588 2589 2590 2591 2592 2593 2595 2. userResponse message form the server: 2597 2598 2602 2604 xcon-userid:Alice@example.com 2605 xcon:8977794@example.com 2606 create 2607 200 2608 4 2609 2610 2611 2613 Figure 22: Alice joins the conference through the CCMP 2615 6.7. Alice adds a new user to the conference 2617 This section illustrates the seventh and last transaction in the 2618 overall flow. Alice uses the CCMP to add a new conferencing system 2619 user, Ciccio, to the conference. This "third-party" request is 2620 realized through a "userRequest/create" message containing, in the 2621 "userInfo" parameter, a element compliant with the XCON data 2622 model representation. Notice that such element includes information 2623 about Ciccio's Address of Records, as well as his current end-point, 2624 but has a fake "entity" attribute, since it is unknown to Alice, in 2625 this example. Thus, the server is in charge of generating a new 2626 XCON-USERID for the user Alice indicates, and returning it in the 2627 "entity" attribute of the "userInfo" parameter carried in the 2628 response, as well as adding the user to the conference. The picture 2629 below shows the transaction. 2631 Alice adds user "Ciccio" to the conference by issuing a third-party 2632 "userRequest/create" message to the server: 2634 CCMP Client CCMP Server 2635 | | 2636 | CCMP userRequest message | 2637 | - confUserID: Alice | 2638 | - confObjID: 8977794 | 2639 | - operation: create | 2640 | - userInfo: CiccioUserInfo(with dummy "entity") | 2641 |------------------------------------------------------>| 2642 | | 2643 | CCMP userResponse message | 2644 | - confUserID: Alice | 2645 | - confObjID: 8977794 | 2646 | - operation: create | 2647 | - response-code: 200 | 2648 | - version: 5 | 2649 | - userInfo: CiccioUserInfo | 2650 | (with actual "entity") | 2651 |<------------------------------------------------------| 2652 | | 2653 . . 2654 . . 2656 1. "third party" userRequest message from Alice: 2658 2659 2663 2665 xcon-userid:Alice@example.com 2666 xcon:8977794@example.com 2667 create 2668 2669 2670 2671 2672 2673 mailto:Ciccio@example.com 2674 2675 email 2676 2678 2679 2680 2681 2682 2683 2685 2. "third party" userResponse message form the server: 2687 2688 2692 2694 xcon-userid:Alice@example.com 2695 xcon:8977794@example.com 2696 create 2697 200 2698 5 2699 2700 2701 2702 2703 2704 mailto:Ciccio@example.com 2705 2706 email 2707 2708 2709 2710 2711 2712 2713 2715 Figure 23: Alice adds a new user to the conference through the CCMP 2717 7. Locating a Conference Control Server 2719 If a conference control client is not pre-configured to use a 2720 specific conference control server for the requests, the client MUST 2721 first discover the conference control server before it can send any 2722 requests. The result of the discovery process, is the address of the 2723 server supporting conferencing. In this document, the result is an 2724 http: or https: URI, which identifies a conference server. 2726 This document proposes the use of DNS to locate the conferencing 2727 server. U-NAPTR resolution for conferencing takes a domain name as 2728 input and produces a URI that identifies the conferencing server. 2729 This process also requires an Application Service tag and an 2730 Application Protocol tag, which differentiate conferencing-related 2731 NAPTR records from other records for that domain. 2733 Section 12.4.1 defines an Application Service tag of "XCON", which is 2734 used to identify the centralized conferencing (XCON) server for a 2735 particular domain. The Application Protocol tag "CCMP", defined in 2736 Section 12.4.2, is used to identify an XCON server that understands 2737 the CCMP protocol. 2739 The NAPTR records in the following example Figure 24 demonstrate the 2740 use of the Application Service and Protocol tags. Iterative NAPTR 2741 resolution is used to delegate responsibility for the conferencing 2742 service from "zonea.example.com." and "zoneb.example.com." to 2743 "outsource.example.com.". 2745 zonea.example.com. 2746 ;; order pref flags 2747 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2748 "" ; regex 2749 outsource.example.com. ; replacement 2750 ) 2751 zoneb.example.com. 2752 ;; order pref flags 2753 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 2754 "" ; regex 2755 outsource.example.com. ; replacement 2756 ) 2757 outsource.example.com. 2758 ;; order pref flags 2759 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 2760 "!*.!https://confs.example.com/!" ; regex 2761 . ; replacement 2762 ) 2764 Figure 24: Sample XCON:CCMP Service NAPTR Records 2766 Details for the "XCON" Application Service tag and the "CCMP" 2767 Application Protocol tag are included in Section 12.4. 2769 8. Managing Notifications 2771 When the conference control client uses SIP [RFC3261] as the 2772 signaling protocol to participate in the conference, SIP event 2773 notification can be used. In such a case, the conference control 2774 client MUST implement the Conference event package for XCON 2775 [I-D.ietf-xcon-event-package]. This is the default mechanism for 2776 conferencing clients as is SIP for signaling per the XCON Framework 2777 [RFC5239]. 2779 In the case where the interface to the conference server is entirely 2780 web based, there is a common mechanism for web-based systems that 2781 could be used - a "call back". With this mechanism, the conference 2782 client provides the conference server with an HTTP URL which is 2783 invoked when a change occurs. This is a common implementation 2784 mechanism for e-commerce. This works well in the scenarios whereby 2785 the conferencing client is a web server that provides the graphical 2786 HTML user interface and uses CCMP as the backend interface to the 2787 conference server. And, this model can co-exist with the SIP event 2788 notification model. PC-based clients behind NATs could provide a SIP 2789 event URI, whereas web-based clients using CCMP in the backend would 2790 probably find the HTTP call back approach much easier. The details 2791 of this approach are out of scope for the CCMP per se, thus the 2792 expectation is that a future specification will document this 2793 solution. 2795 9. HTTP Transport 2797 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 2798 [RFC2818] as transport mechanisms for the CCMP protocol, which a 2799 conforming conference Server and Conferencing client MUST support. 2801 Although CCMP uses HTTP as a transport, it uses a strict subset of 2802 HTTP features, and due to the restrictions of some features, a 2803 conferencing server may not be a fully compliant HTTP server. It is 2804 intended that a conference server can easily be built using an HTTP 2805 server with extensibility mechanisms, and that a conferencing client 2806 can trivially use existing HTTP libraries. This subset of 2807 requirements helps implementors avoid ambiguity with the many options 2808 the full HTTP protocol offers. 2810 A conferencing client that conforms to this specification is not 2811 required to support HTTP authentication [RFC2617] or cookies 2812 [RFC2965]. These mechanism are unnecessary because CCMP requests 2813 carry their own authentication information (in the "subject" field; 2814 see Section 5.1). 2816 A CCMP request is carried in the body of an HTTP POST request. The 2817 conferencing client MUST include a Host header in the request. 2819 The MIME type of CCMP request and response bodies is "application/ 2820 ccmp+xml". The conference server and conferencing client MUST 2821 provide this value in the HTTP Content-Type and Accept header fields. 2822 If the conference server does not receive the appropriate Content- 2823 Type and Accept header fields, the conference server SHOULD fail the 2824 request, returning a 406 (not acceptable) response. CCMP responses 2825 SHOULD include a Content-Length header. 2827 Conferencing clients MUST NOT use the "Expect" header or the "Range" 2828 header in CCMP requests. The conference server MAY return 501 (not 2829 implemented) errors if either of these HTTP features are used. In 2830 the case that the conference server receives a request from the 2831 conferencing client containing a If-* (conditional) header, the 2832 conference server SHOULD return a 412 (precondition failed) response. 2834 The POST method is the only method REQUIRED for CCMP. If a 2835 conference server chooses to support GET or HEAD, it SHOULD consider 2836 the kind of application doing the GET. Since a conferencing client 2837 only uses a POST method, the GET or HEAD MUST be either an escaped 2838 URL (e.g., somebody found a URL in protocol traces or log files and 2839 fed it into their browser) or somebody doing testing/ debugging. The 2840 conference server could provide information in the CCMP response 2841 indicating that the URL corresponds to a conference server and only 2842 responds to CCMP POST requests or the conference server could instead 2843 try to avoid any leak of information by returning a very generic HTTP 2844 error message such as 405 (method not allowed). 2846 The conference server populates the HTTP headers of responses so that 2847 they are consistent with the contents of the message. In particular, 2848 the "CacheControl" header SHOULD be set to disable caching of any 2849 conference information by HTTP intermediaries. Otherwise, there is 2850 the risk of stale information and/or the unauthorized disclosure of 2851 the information. The HTTP status code MUST indicate a 2xx series 2852 response for all CCMP Response and Error messages. 2854 The conference server MAY redirect a CCMP request. A conferencing 2855 client MUST handle redirects, by using the Location header provided 2856 by the server in a 3xx response. When redirecting, the conferencing 2857 client MUST observe the delay indicated by the Retry-After header. 2858 The conferencing client MUST authenticate the server that returns the 2859 redirect response before following the redirect. A conferencing 2860 client SHOULD authenticate the conference server indicated in a 2861 redirect. 2863 The conference server SHOULD support persistent connections and 2864 request pipelining. If pipelining is not supported, the conference 2865 server MUST NOT allow persistent connections. The conference server 2866 MUST support termination of a response by the closing of a 2867 connection. 2869 Implementations of CCMP that implement HTTP transport MUST implement 2870 transport over TLS [RFC2818]. TLS provides message integrity and 2871 confidentiality between the conference control client and the 2872 conference control server. The conferencing client MUST implement 2873 the server authentication method described in HTTPS [RFC2818]. The 2874 device uses the URI obtained during conference server discovery to 2875 authenticate the server. The details of this authentication method 2876 are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, 2877 the conferencing client SHOULD fail a request if server 2878 authentication fails. 2880 10. Security Considerations 2882 As identified in the XCON framework [RFC5239], there are a wide 2883 variety of potential attacks related to conferencing, due to the 2884 natural involvement of multiple endpoints and the capability to 2885 manipulate the data on the conference server using CCMP. Examples of 2886 attacks include the following: an endpoint attempting to listen to 2887 conferences in which it is not authorized to participate, an endpoint 2888 attempting to disconnect or mute other users, and theft of service by 2889 an endpoint in attempting to create conferences it is not allowed to 2890 create. 2892 The following summarizes the security considerations for CCMP: 2893 1. The client MUST determine the proper conference server. The 2894 conference server discovery is described in Section 7. 2895 2. The client MUST connect to the proper conference server. The 2896 mechanisms for addressing this security consideration are 2897 described in Section 10.1. 2898 3. The protocol MUST support a confidentiality and integrity 2899 mechanism. As described in Section 9, implementations of CCMP 2900 MUST implement the HTTP transport over TLS [RFC2818]. 2901 4. There are security issues associated with the authorization to 2902 perform actions on the conferencing system to invoke specific 2903 capabilities. A conference server SHOULD ensure that only 2904 authorized entities can manipulate the conference data. The 2905 mechanisms for addressing this security consideration are 2906 described in Section 10.2. 2908 5. The privacy and security of the identity of a user in the 2909 conference MUST be assured. The mechanisms to ensure the 2910 security and privacy of identity are discussed in Section 10.3. 2911 6. A final issue is related to Denial of Service (DoS) attacks on 2912 the conferencing server itself. In order to minimize the 2913 potential for DoS attacks, it is RECOMMENDED that conferencing 2914 systems require user authentication and authorization for any 2915 client participating in a conference. This can be accomplished 2916 through the use of the mechanisms described in Section 10.2, as 2917 well as by using the security mechanisms associated with the 2918 specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). 2920 10.1. Assuring that the Proper Conferencing Server has been contacted 2922 When the CCMP transaction is conducted using TLS [RFC5246], the 2923 conference server can authenticate its identity, either as a domain 2924 name or as an IP address, to the conference client by presenting a 2925 certificate containing that identifier as a subjectAltName (i.e., as 2926 an iPAddress or dNSName, respectively). With the use of HTTP as a 2927 transport for CCMP, this is exactly the authentication described by 2928 TLS [RFC2818]. If the client has external information as to the 2929 expected identity or credentials of the proper conference server 2930 (e.g., a certificate fingerprint), these checks MAY be omitted. Any 2931 implementation of CCMP MUST be capable of being transacted over TLS 2932 so that the client can request the above authentication, and a 2933 conference server implementation MUST include this feature. Note 2934 that in order for the presented certificate to be valid at the 2935 client, the client must be able to validate the certificate. In 2936 particular, the validation path of the certificate must end in one of 2937 the client's trust anchors, even if that trust anchor is the 2938 conference server certificate itself. 2940 10.2. User Authentication and Authorization 2942 Many policy authorization decisions are based on the identity of the 2943 user or the role that a user may have. The conferencing server MUST 2944 implement mechanisms for authentication of users to validate their 2945 identity. There are several ways that a user might authenticate its 2946 identity to the system. For users joining a conference using one of 2947 the call signaling protocols, the user authentication mechanisms for 2948 the specific protocol can be used. For the case of users joining the 2949 conference using the CCMP, TLS is RECOMMENDED. 2951 The XCON Framework [RFC5239] provides an overview of other 2952 authorization mechanisms. In the cases where a user is authorized 2953 via multiple mechanisms, it is RECOMMENDED that the conference server 2954 correlate the authorization of the CCMP interface with other 2955 authorization mechanisms - e.g., PSTN users that join with a PIN and 2956 control the conference using CCMP. When a conference server presents 2957 the identity of authorized users, it MAY provide information about 2958 the way the identity was proven or verified by the system. A 2959 conference server can also allow a completely unauthenticated user 2960 into the system - this information SHOULD also be communicated to 2961 interested parties. 2963 Once a user is authenticated and authorized through the various 2964 mechanisms available on the conference server, the conference server 2965 MUST allocate a conference user identifier (XCON-USERID) and SHOULD 2966 associate the XCON-USERID with any signaling specific user 2967 identifiers that were used for authentication and authorization. 2968 This XCON-USERID can be provided to a specific user through the 2969 conference notification interface and MUST be provided to users that 2970 interact with the conferencing system using the CCMP (i.e., in the 2971 appropriate CCMP response messages). This conference user identifier 2972 is REQUIRED for any subsequent operations on the conference object. 2974 10.3. Security and Privacy of Identity 2976 An overview of the required privacy and anonymity for users of a 2977 conferencing system are provided in the XCON Framework [RFC5239]. 2978 The security of the identity in the form of the XCON-USERID is 2979 provided in the CCMP protocol through the use of TLS. 2981 The conference server SHOULD provide mechanisms to ensure the privacy 2982 of the XCON-USERID. This is accomplished by the conference client 2983 manipulation of the "provide-anonymity" element defined in the XCON 2984 data model ([I-D.ietf-xcon-common-data-model]. The "provide- 2985 anonymity" element controls the degree to which a user reveals their 2986 identity. The conference client MUST set the "provide-anonymity" 2987 element to "hidden" if the user does not want other participants to 2988 even be aware that there is an additional participant in the 2989 conference. The conference client MUST set the "provide-anonymity" 2990 field to "private" if the user wants to be entirely "anonymous" 2991 (i.e., other participants are aware that there is another 2992 participant, but have no information as to their identity). The 2993 conference client MUST set the "provide-anonymity" field to "semi- 2994 private" if their identity is only to be revealed to other 2995 participants or users that have a higher level authorization (e.g., a 2996 conferencing system can be configured such that an administrator can 2997 see all users). To provide the required privacy, the conference 2998 client SHOULD include the "provide-anonymity" element in the 2999 "confInfo" parameter in a CCMP confRequest message with an "update" 3000 or "create" operation or in the "userInfo" parameter in a CCMP 3001 userRequest message with an "update" or "create" operation, to ensure 3002 the user is provided the appropriate level of privacy. If the 3003 "provide-anonymity" element is not included in the conference object, 3004 then other users can see the participant's identity. 3006 11. XML Schema 3008 This section provides the XML schema definition of the "application/ 3009 ccmp+xml" format. 3011 3012 3021 3023 3026 3027 3029 3031 3032 3033 3035 3036 3038 3040 3041 3042 3044 3045 3047 3048 3050 3051 3053 3055 3057 3059 3061 3063 3064 3065 3067 3069 3070 3071 3072 3073 3074 3075 3076 3077 3079 3081 3083 3084 3085 3087 3089 3090 3091 3093 3095 3096 3097 3098 3099 3100 3101 3102 3103 3105 3107 3109 3110 3111 3113 3115 3116 3117 3119 3121 3122 3123 3124 3125 3126 3127 3128 3129 3131 3133 3135 3136 3137 3139 3141 3142 3143 3144 3146 3147 3148 3149 3150 3151 3152 3153 3154 3156 3158 3160 3161 3162 3164 3166 3167 3168 3170 3172 3173 3174 3175 3176 3177 3178 3179 3180 3182 3184 3186 3187 3188 3190 3193 3194 3195 3197 3199 3200 3201 3202 3203 3204 3205 3206 3207 3209 3211 3213 3214 3215 3217 3219 3220 3221 3223 3225 3226 3227 3228 3229 3230 3231 3232 3233 3235 3237 3240 3241 3242 3244 3246 3247 3248 3250 3252 3253 3254 3255 3256 3257 3258 3259 3260 3262 3264 3267 3268 3269 3271 3273 3274 3275 3277 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3290 3293 3294 3295 3297 3299 3300 3301 3303 3305 3306 3307 3308 3309 3310 3311 3312 3313 3315 3317 3320 3321 3322 3324 3326 3327 3328 3330 3332 3333 3334 3337 3339 3341 3343 3345 3347 3349 3350 3351 3353 3355 3356 3357 3358 3359 3360 3361 3362 3363 3365 3367 3369 3370 3371 3373 3375 3376 3377 3379 3381 3382 3383 3384 3385 3386 3387 3388 3389 3391 3393 3395 3396 3397 3399 3401 3402 3403 3405 3407 3408 3409 3410 3411 3412 3413 3414 3415 3417 3419 3421 3422 3423 3425 3427 3428 3429 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3442 3444 3446 3447 3448 3450 3452 3453 3454 3456 3458 3459 3460 3461 3462 3463 3464 3465 3466 3468 3470 3472 3473 3474 3476 3478 3479 3481 3483 3485 3486 3487 3488 3489 3490 3491 3492 3493 3495 3497 3499 3500 3501 3503 3505 3506 3507 3509 3511 3512 3513 3514 3515 3516 3517 3518 3519 3521 3523 3526 3527 3528 3530 3532 3533 3534 3536 3538 3539 3540 3541 3542 3543 3544 3545 3546 3548 3550 3553 3554 3555 3557 3559 3560 3561 3563 3565 3566 3567 3568 3569 3570 3571 3572 3573 3575 3576 3579 3580 3581 3583 3585 3586 3587 3589 3591 3592 3593 3594 3595 3596 3597 3598 3599 3601 3603 3606 3607 3608 3610 3612 3613 3614 3616 3618 3620 3621 3622 3623 3625 3627 3629 3630 3631 3632 3633 3634 3635 3636 3638 3640 3641 3642 3644 3646 3648 3649 3650 3652 3653 3654 3655 3656 3657 3659 3660 3661 3662 3664 3665 3666 3667 3668 3669 3671 3672 3674 3675 3677 3679 Figure 25 3681 12. IANA Considerations 3683 This document registers a new XML namespace, a new XML schema, and 3684 the MIME type for the schema. This document also registers the 3685 "XCON" Application Service tag and the "CCMP" Application Protocol 3686 tag. This document also defines registries for the CCMP operation 3687 types and response codes. 3689 12.1. URN Sub-Namespace Registration 3691 This section registers a new XML namespace, 3692 ""urn:ietf:params:xml:ns:xcon:ccmp"". 3694 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 3695 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 3696 Mary Barnes (mary.barnes@nortel.com). 3697 XML: 3699 BEGIN 3700 3701 3703 3704 3705 CCMP Messages 3706 3707 3708

Namespace for CCMP Messages

3709

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

3710 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3711 with the RFC number for this specification.]] 3712

See RFCXXXX.

3713 3714 3715 END 3717 12.2. XML Schema Registration 3719 This section registers an XML schema as per the guidelines in 3720 [RFC3688]. 3722 URI: urn:ietf:params:xml:schema:xcon:ccmp 3723 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3724 Barnes (mary.barnes@nortel.com). 3725 Schema: The XML for this schema can be found as the entirety of 3726 Section 11 of this document. 3728 12.3. MIME Media Type Registration for 'application/ccmp+xml' 3730 This section registers the "application/ccmp+xml" MIME type. 3732 To: ietf-types@iana.org 3733 Subject: Registration of MIME media type application/ccmp+xml 3734 MIME media type name: application 3735 MIME subtype name: ccmp+xml 3736 Required parameters: (none) 3737 Optional parameters: charset 3738 Indicates the character encoding of enclosed XML for which the 3739 default is UTF-8. 3740 Encoding considerations: Uses XML, which can employ 8-bit 3741 characters, depending on the character encoding used. See RFC 3742 3023 [RFC3023], section 3.2. 3743 Security considerations: This content type is designed to carry 3744 protocol data related conference control. Some of the data could 3745 be considered private and thus should be protected. 3746 Interoperability considerations: None. 3747 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 3748 replace XXXX with the RFC number for this specification.]] 3749 Applications which use this media type: Centralized Conferencing 3750 control clients and servers. 3751 Additional Information: Magic Number(s): (none) 3752 File extension(s): .xml 3753 Macintosh File Type Code(s): (none) 3754 Person & email address to contact for further information: Mary 3755 Barnes 3756 Intended usage: LIMITED USE 3757 Author/Change controller: The IETF 3758 Other information: This media type is a specialization of 3759 application/xml [RFC3023], and many of the considerations 3760 described there also apply to application/ccmp+xml. 3762 12.4. DNS Registrations 3764 Section 12.4.1 defines an Application Service tag of "XCON", which is 3765 used to identify the centralized conferencing (XCON) server for a 3766 particular domain. The Application Protocol tag "CCMP", defined in 3767 Section 12.4.2, is used to identify an XCON server that understands 3768 the CCMP protocol. 3770 12.4.1. Registration of a Conference Control Server Application Service 3771 Tag 3773 This section registers a new S-NAPTR/U-NAPTR Application Service tag 3774 for XCON, as mandated by [RFC3958]. 3776 Application Service Tag: XCON 3778 Intended usage: Identifies a server that supports centralized 3779 conferencing. 3781 Defining publication: RFCXXXX 3783 Contact information: The authors of this document 3785 Author/Change controller: The IESG 3787 12.4.2. Registration of a Conference Control Server Application 3788 Protocol Tag for CCMP 3790 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 3791 for the CCMP protocol, as mandated by [RFC3958]. 3793 Application Service Tag: CCMP 3795 Intended Usage: Identifies the Centralized Conferencing (XCON) 3796 Manipulation Protocol. 3798 Applicable Service Tag(s): XCON 3800 Terminal NAPTR Record Type(s): U 3802 Defining Publication: RFCXXXX 3804 Contact Information: The authors of this document 3806 Author/Change Controller: The IESG 3808 12.5. CCMP Protocol Registry 3810 This document requests that the IANA create a new registry for the 3811 CCMP protocol including an initial registry for operation types and 3812 response codes. 3814 12.5.1. CCMP Message Types 3816 The CCMP messages are described in Section 4.1 and defined in the XML 3817 schema in Section 11. The following summarizes the requested 3818 registry: 3820 Related Registry: CCMP Message Types Registry 3821 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3822 with the RFC number for this specification.] 3823 Registration/Assignment Procedures: New CCMP message types are 3824 allocated on a specification required basis. 3825 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3826 Barnes (mary.barnes@nortel.com). 3828 This section pre-registers the following initial CCMP message types: 3830 blueprintsRequest: Used by a conference control client to query a 3831 conferencing system for its capabilities, in terms of available 3832 conference blueprints. 3833 blueprintsResponse: The blueprintsResponse returns a list of 3834 blueprints supported by the specific conference server. 3835 confsRequest: Used by a conference control client to query a 3836 conferencing system for its scheduled/active conferences. 3837 confsResponse: The "confsResponse" returns the list of the currently 3838 activated/scheduled conferences at the server. 3839 confRequest: The "confRequest" is used to create a conference object 3840 and/or to request an operation on the conference object as a 3841 whole. 3842 confResponse: The "confResponse" indicates the result of the 3843 operation on the conference object as a whole. 3844 userRequest: The "userRequest" is used to request an operation on 3845 the "user" element in the conference object. 3846 userResponse: The "userResponse" indicates the result of the 3847 requested operation on the "user" element in the conference 3848 object. 3849 usersRequest This "usersRequest" is used to manipulate the "users" 3850 element in the conference object, including parameters such as the 3851 "allowed-users-list", "join-handling", etc. 3853 usersResponse: This "usersResponse" indicates the result of the 3854 request to manipulate the "users" element in the conference 3855 object. 3856 sidebarRequest: This "sidebarRequest" is used to retrieve the 3857 information related to a sidebar or to create, change or delete a 3858 specific sidebar. 3859 sidebarResponse: This "sidebarResponse" indicates the result of the 3860 sidebarRequest. 3862 12.5.2. CCMP Response Codes 3864 The following summarizes the requested registry for CCMP Response 3865 codes: 3867 Related Registry: CCMP Response Code Registry 3868 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3869 with the RFC number for this specification.] 3870 Registration/Assignment Procedures: New response codes are allocated 3871 on a first-come/first-serve basis with specification required. 3872 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 3873 Barnes (mary.barnes@nortel.com). 3875 This section pre-registers the following thirteen initial response 3876 codes as described above in Section 4.1: 3878 200: This code indicates that the request was successfully 3879 processed. 3880 409: This code indicates that a requested "update" cannot be 3881 successfully completed by the server. An example of such 3882 situation is when the modification of an object cannot be applied 3883 due to conflicts arising at the server's side (e.g. because the 3884 client version of the object is an obsolete one and the requested 3885 modifications collide with the up-to-date state of the object 3886 stored at the server). 3887 400: This code indicates that the request was badly formed in some 3888 fashion. 3889 401: This code indicates that the user was not authorized for the 3890 specific operation on the conference object. 3891 403: This code indicates that the specific operation is not valid 3892 for the target conference object. 3893 404: This code indicates that the specific conference object was not 3894 found. 3895 420: This code is returned in answer to a "userRequest/create" 3896 operation, in the case of a third-party invite, when the 3897 "confUserID" (contained in the "entity" attribute of the 3898 "userInfo" parameter) of the user to be added is unknown. 3900 421: This code is returned in the case of requests in which the 3901 "confUserID" of the sender is invalid. 3902 422: This code is returned in response to all requests wishing to 3903 access/manipulate a password-protected conference object, when the 3904 "conference-password" parameter contained in the request is wrong. 3905 423: This code is returned in response to all requests wishing to 3906 access/manipulate a password-protected conference object, when the 3907 "conference-password" parameter is missing in the request. 3908 424: This code is returned in response whenever the server wants to 3909 authenticate the requestor through the "subject" parameter and 3910 such a parameter is not provided in the request. 3911 425: This code indicates that the conferencing system cannot delete 3912 the specific conference object because it is a parent for another 3913 conference object. 3914 426: This code indicates that the target conference object cannot be 3915 changed (e.g., due to policies, roles, privileges, etc.). 3916 510: This code indicates that the request could not be processed 3917 within a reasonable time, with the time specific to a conferencing 3918 system implementation. 3919 500: This code indicates that the conferencing system experienced 3920 some sort of internal error. 3921 501: This code indicates that the specific operation is not 3922 implemented on that conferencing system. 3924 13. Acknowledgments 3926 The authors appreciate the feedback provided by Dave Morgan, Pierre 3927 Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean 3928 Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special 3929 thanks go to Roberta Presta for her invaluable contribution to this 3930 document. Roberta has worked on the specification of the CCMP 3931 protocol at the University of Napoli for the preparation of her 3932 Master thesis. She has also implemented the CCMP prototype used for 3933 the trials and from which the dumps provided in Section 6 have been 3934 extracted. 3936 14. Changes since last Version 3938 NOTE TO THE RFC-Editor: Please remove this section prior to 3939 publication as an RFC. 3941 The following summarizes the changes between the WG 03 and the 04: 3943 1. Re-organized document based on feedback from Richard Barnes. 3945 2. Editorial clarifications and nits, including those identified by 3946 Richard and Simo Veikkolainen. 3948 The following summarizes the changes between the WG 02 and the 03: 3950 1. Clarified that the confUserID is optional in the generic CCMP 3951 request message for a userRequest with a "create" operation. 3952 2. Added response-code (error cases) handling - a general section 3953 for each of the operations (as part of CCMP Response Code 3954 section), so we don't need to re-iterate for each of the messages 3955 and message specific cases as appropriate (e.g., 425, modified) 3956 3. Moved "operation" parameter to be part of general CCMP request 3957 and response messages since it is used for more than one message 3958 type. And, it's necessary to define before describing the 3959 operation specific response-code handling. 3960 4. Revised normative statements for the various protocol messages 3961 and operations - e.g., messages MUST include parameter x versus 3962 SHOULD, adding text for handling of cases where the SHOULDs don't 3963 happen and the SHOULD NOTs do. Added descriptions for all the 3964 operation types, as appropriate. 3965 5. Added lots more details in the security section. 3966 6. Added section to describe requirements for an HTTP implementation 3967 to support CCMP. 3968 7. Updated section on notifications - XCON SIP event package is 3969 default, with some discussion of an HTTP callback mechanism 3970 (ffs). 3971 8. Misc editorial nits: qualifying message names in the text, etc., 3972 etc., etc. 3974 The following summarizes the changes between the WG 01 and the 02: 3976 1. Changed the basic approach from REST to HTTP as a transport. 3977 This impacted most of the document - i.e., a major rewrite - 02 3978 is closer to 00 than the 01. 3979 2. Added full example based on prototype. 3981 The following summarizes the changes between the WG 00 and the 01: 3983 1. Changed the basic approach from using SOAP to REST - the 3984 fundamentals are the same in terms of schema, basic operations. 3985 This impacted most sections, in particular introduction and 3986 motivation. 3987 2. Added new request types - blueprintsRequest, blueprintRequest and 3988 confsRequest. The first replaces the optionsRequest and the 3989 latter allows the client to get a list of all active conferences. 3990 3. Merged all requests into the basic operations table. Added 3991 summary of RESTful examples (referenced by the basic operations 3992 table. 3994 4. Added examples showing RESTful approach - i.e., HTTP methods for 3995 message exchange. 3996 5. Removed requestID from the schema (it should be handle by the 3997 transport - e.g., HTTP). Updated schema (based on current 3998 prototype - it still needs another revision. 3999 6. Added placeholders for Notifications and Role Based Access 4000 Control. 4001 7. Added some text for discovery using DNS (including IANA 4002 registrations) 4003 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 4004 informational section. 4006 15. References 4008 15.1. Normative References 4010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4011 Requirement Levels", BCP 14, RFC 2119, March 1997. 4013 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4014 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4015 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4017 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 4018 Leach, P., Luotonen, A., and L. Stewart, "HTTP 4019 Authentication: Basic and Digest Access Authentication", 4020 RFC 2617, June 1999. 4022 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 4024 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 4025 Mechanism", RFC 2965, October 2000. 4027 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4028 January 2004. 4030 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 4031 Centralized Conferencing", RFC 5239, June 2008. 4033 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4034 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 4036 [I-D.ietf-xcon-common-data-model] 4037 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 4038 "Conference Information Data Model for Centralized 4039 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18 4040 (work in progress), February 2010. 4042 15.2. Informative References 4044 [REST] Fielding, "Architectural Styles and the Design of Network- 4045 based Software Architectures", 2000. 4047 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 4048 Types", RFC 3023, January 2001. 4050 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4051 A., Peterson, J., Sparks, R., Handley, M., and E. 4052 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4053 June 2002. 4055 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 4056 Service Location Using SRV RRs and the Dynamic Delegation 4057 Discovery Service (DDDS)", RFC 3958, January 2005. 4059 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 4060 RFC 3966, December 2004. 4062 [I-D.ietf-xcon-event-package] 4063 Camarillo, G., Srinivasan, S., Even, R., and J. 4064 Urpalainen, "Conference Event Package Data Format 4065 Extension for Centralized Conferencing (XCON)", 4066 draft-ietf-xcon-event-package-01 (work in progress), 4067 September 2008. 4069 [I-D.ietf-xcon-examples] 4070 Barnes, M., Miniero, L., Presta, R., and S. Romano, 4071 "Centralized Conferencing Manipulation Protocol (CCMP) 4072 Call Flow Examples", draft-ietf-xcon-examples-04 (work in 4073 progress), April 2010. 4075 [W3C.REC-soap12-part1-20030624] 4076 Gudgin, M., Nielsen, H., Hadley, M., Moreau, J., and N. 4077 Mendelsohn, "SOAP Version 1.2 Part 1: Messaging 4078 Framework", World Wide Web Consortium FirstEdition REC- 4079 soap12-part1-20030624, June 2003, 4080 . 4082 [W3C.REC-soap12-part2-20030624] 4083 Mendelsohn, N., Nielsen, H., Hadley, M., Moreau, J., and 4084 M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 4085 Web Consortium FirstEdition REC-soap12-part2-20030624, 4086 June 2003, 4087 . 4089 Appendix A. Appendix A: Other protocol models and transports considered 4090 for CCMP 4092 The operations on the objects can be implemented in at least two 4093 different ways, namely as remote procedure calls - using SOAP as 4094 described in Appendix A.1 and by defining resources following a 4095 RESTful architecture Appendix A.2. 4097 In both approaches, servers will have to recreate their internal 4098 state representation of the object with each update request, checking 4099 parameters and triggering function invocations. In the SOAP 4100 approach, it would be possible to describe a separate operation for 4101 each atomic element, but that would greatly increase the complexity 4102 of the protocol. A coarser-grained approach to the CCMP does require 4103 that the server process XML elements in updates that have not changed 4104 and that there can be multiple changes in one update. 4106 For CCMP, the resource (REST) model might appear more attractive, 4107 since the conference operations fit the CRUD approach. 4109 Neither of these approaches were considered ideal as SOAP was not 4110 considered to be general purpose enough for use in a broad range of 4111 operational environments. It is quite awkward to apply a RESTful 4112 approach since the CCMP requires a more complex request/response 4113 protocol in order to maintain the data both in the server and at the 4114 client. This doesn't map very elegantly to the basic request/ 4115 response model, whereby a response typically indicates whether the 4116 request was successful or not, rather than providing additional data 4117 to maintain the synchronization between the client and server data. 4118 In addition, the CCMP clients may also receive the data in 4119 Notifications. While the notification method or protocol used by 4120 some conferencing clients can be independent of the CCMP, the same 4121 data in the server is used for both the CCMP and Notifications - this 4122 requires a server application above the transport layer (e.g., HTTP) 4123 for maintaining the data, which in the CCMP model is transparent to 4124 the transport protocol. 4126 A.1. Using SOAP for the CCMP 4128 A remote procedure call (RPC) mechanism for the CCMP could use SOAP 4129 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 4130 -soap12-part2-20030624]), where conferences and the other objects are 4131 modeled as services with associated operations. Conferences and 4132 other objects are selected by their own local identifiers, such as 4133 email-like names for users. This approach has the advantage that it 4134 can easily define atomic operations that have well-defined error 4135 conditions. 4137 All SOAP operations would use a single HTTP verb. While the RESTful 4138 approach requires the use of a URI for each object, SOAP can use any 4139 token. 4141 A.2. A RESTful approach for the CCMP 4143 Conference objects can also be modeled as resources identified by 4144 URIs, with the basic CRUD operations mapped to the HTTP methods POST/ 4145 PUT for creating objects, GET for reading objects, PATCH/POST/PUT for 4146 changing objects and DELETE for deleting them. Many of the objects, 4147 such as conferences, already have natural URIs. 4149 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 4150 design pattern. The basic CRUD operations are used to manipulate 4151 conference objects, which are XML documents containing the 4152 information characterizing a specified conference instance, be it an 4153 active conference or a conference blueprint used by the conference 4154 server to create new conference instances through a simple clone 4155 operation. 4157 Following the CRUD approach, CCMP could use a general-purpose 4158 protocol such as HTTP [RFC2616] to transfer domain-specific XML- 4159 encoded data objects defined in the Conference Information Data Model 4160 for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. 4162 Following on the CRUD approach, CCMP could follow the well-known REST 4163 (REpresentational State Transfer) architectural style [REST]. The 4164 CCMP could map onto the REST philosophy, by specifying resource URIs, 4165 resource formats, methods supported at each URI and status codes that 4166 have to be returned when a certain method is invoked on a specific 4167 URI. A REST-style approach must ensure sure that all operations can 4168 be mapped to HTTP operations. 4170 The following summarizes the specific HTTP method that could be used 4171 for each of the CCMP Requests: 4173 Retrieve: HTTP GET could be used on XCON-URIs, so that clients can 4174 obtain data about conference objects in the form of XML data model 4175 documents. 4177 Create: HTTP PUT could be used to create a new object as identified 4178 by the XCON-URI or XCON-USERID. 4180 Change: Either HTTP PATCH or HTTP POST could be used to change the 4181 conference object identified by the XCON-URI. 4183 Delete: HTTP DELETE could be used to delete conference objects and 4184 parameters within conference objects identified by the XCON-URI. 4186 Authors' Addresses 4188 Mary Barnes 4189 Nortel 4191 Email: mary.barnes@nortel.com 4193 Chris Boulton 4194 NS-Technologies 4196 Email: chris@ns-technologies.com 4198 Simon Pietro Romano 4199 University of Napoli 4200 Via Claudio 21 4201 Napoli 80125 4202 Italy 4204 Email: spromano@unina.it 4206 Henning Schulzrinne 4207 Columbia University 4208 Department of Computer Science 4209 450 Computer Science Building 4210 New York, NY 10027 4212 Email: hgs+xcon@cs.columbia.edu