idnits 2.17.1 draft-ietf-xcon-ccmp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2445. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 109 has weird spacing: '...tration of a ...' == Line 2118 has weird spacing: '...tration of a ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 3, 2008) is 5652 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: 'TBD' is mentioned on line 1216, but not defined == Unused Reference: 'RFC3261' is defined on line 2332, but no explicit reference was found in the text == Unused Reference: 'RFC3966' is defined on line 2345, 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) == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-12 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: May 7, 2009 Avaya 6 S P. Romano 7 University of Napoli 8 H. Schulzrinne 9 Columbia University 10 November 3, 2008 12 Centralized Conferencing Manipulation Protocol 13 draft-ietf-xcon-ccmp-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 7, 2009. 40 Abstract 42 The Centralized Conferencing Manipulation Protocol (CCMP) can create, 43 retrieve, change and delete objects describing a centralized 44 conference, such as state and capabilities of the conference, 45 participants, and their roles. The conference information is 46 contained in XML documents and fragments conforming to the 47 centralized conferencing data model schema. CCMP is a state-less 48 client-server protocol based on a request/response model. 50 Conferencing clients send requests to conference servers, which 51 respond to the client with the conference information. 53 This document also discusses options for using existing notification 54 protocols to inform conference client about the changes in the state 55 of a conference during its entire lifetime. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Rationale and Motivation . . . . . . . . . . . . . . . . . . . 5 63 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 7 64 6. Conference Object and User Identifiers . . . . . . . . . . . . 9 65 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Conference Users and Participants . . . . . . . . . . . . 9 67 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.2. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.3. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.4. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. Protocol Operations on Conference Objects . . . . . . . . . . 13 73 8.1. Locating a Conference Control Server . . . . . . . . . . . 14 74 8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 15 75 8.2.1. blueprintsRequest . . . . . . . . . . . . . . . . . . 16 76 8.2.2. confsRequest . . . . . . . . . . . . . . . . . . . . . 16 77 8.2.3. Operations Requests . . . . . . . . . . . . . . . . . 16 78 8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 18 79 8.3.1. blueprintsResponse . . . . . . . . . . . . . . . . . . 20 80 8.3.2. confsResponse . . . . . . . . . . . . . . . . . . . . 20 81 8.3.3. Operation Responses . . . . . . . . . . . . . . . . . 21 82 9. Managing sidebars . . . . . . . . . . . . . . . . . . . . . . 25 83 9.1. Sidebars by value . . . . . . . . . . . . . . . . . . . . 25 84 9.2. Sidebars by reference . . . . . . . . . . . . . . . . . . 26 85 10. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 26 86 10.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 26 87 10.2. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 26 88 10.3. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 27 89 10.4. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 27 90 10.5. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 28 91 10.6. Conference-info Parameter . . . . . . . . . . . . . . . . 28 92 10.7. User Parameter . . . . . . . . . . . . . . . . . . . . . . 29 93 10.8. Users Parameter . . . . . . . . . . . . . . . . . . . . . 29 94 10.9. Sidebar Parameters . . . . . . . . . . . . . . . . . . . . 29 95 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 11.1. HTTP methods for realizing a RESTful CCMP . . . . . . . . 30 97 11.2. CCMP Detailed Message Body Examples . . . . . . . . . . . 33 98 11.2.1. Creating a New Conference . . . . . . . . . . . . . . 33 99 11.2.2. Creating a New Conference User . . . . . . . . . . . . 36 100 11.2.3. Adding a User to a Conference . . . . . . . . . . . . 36 101 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 37 102 13. Managing notifications . . . . . . . . . . . . . . . . . . . . 45 103 14. Role based access control . . . . . . . . . . . . . . . . . . 46 104 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 105 15.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46 106 15.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 107 15.3. MIME Media Type Registration for 'application/ccmp+xml' . 47 108 15.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 48 109 15.4.1. Registration of a Location Server Application 110 Service Tag . . . . . . . . . . . . . . . . . . . . . 48 111 15.4.2. Registration of a Location Server Application 112 Protocol Tag for HELD . . . . . . . . . . . . . . . . 48 113 15.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 49 114 15.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 49 115 15.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 50 116 16. Security Considerations . . . . . . . . . . . . . . . . . . . 51 117 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 118 18. Changes since last Version . . . . . . . . . . . . . . . . . . 51 119 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 120 19.1. Normative References . . . . . . . . . . . . . . . . . . . 52 121 19.2. Informative References . . . . . . . . . . . . . . . . . . 52 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 123 Intellectual Property and Copyright Statements . . . . . . . . . . 55 125 1. Introduction 127 The Framework for Centralized Conferencing [RFC5239] (XCON FW) 128 defines a signaling-agnostic framework, naming conventions and 129 logical entities required for building advanced conferencing systems. 130 The XCON FW introduces the conference object as a logical 131 representation of a conference instance, representing the current 132 state and capabilities of a conference. 134 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 135 this document allows authenticated and authorized users to create, 136 manipulate and delete conference objects. Operations on conferences 137 include adding and removing participants, changing their roles, as 138 well as adding and removing media streams and associated end points. 140 CCMP implements the client-server model within the XCON FW, with the 141 conferencing client and conference control server acting as client 142 and server, respectively. CCMP is an instance of conference control 143 protocol (CCP). 145 CCMP can be mapped into the CRUD (Create, Read, Update, Delete) 146 design pattern. The basic CRUD operations are used to manipulate 147 conference objects, which are XML documents containing the 148 information characterizing a specified conference instance, be it an 149 active conference or a conference blueprint used by the conference 150 server to create new conference instances through a simple clone 151 operation. 153 CCMP can use a general-purpose protocol such as HTTP [RFC2616] to 154 transfer domain-specific XML-encoded data objects defined in the 155 Conference Information Data Model for Centralized Conferencing 156 [I-D.ietf-xcon-common-data-model]. 158 CCMP follows the well-known REST (REpresentational State Transfer) 159 architectural style [REST] This document describes how the CCMP 160 specification maps onto the REST philosophy, by specifying resource 161 URIs, resource formats, methods supported at each URI and status 162 codes that have to be returned when a certain method is invoked on a 163 specific URI. 165 Section 4 motivates the design of CCMP, followed by the system 166 architecture in Section 5. Section 6 discusses the primary keys in 167 the conference object carried in the protocol. An overview of the 168 operations associated with each protocol request and response is 169 provided in Section 7, with the sequence of protocol requests and 170 responses discussed in Section 8 and examples provided in Section 11. 171 The protocol parameters are detailed in Section 10. Section 12 172 provides the XML schema. 174 2. Conventions 176 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 177 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 178 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 179 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 180 levels for compliant implementations. 182 3. Terminology 184 In additon to the terms defined in the Framework for Centralized 185 Conferencing [RFC5239], this document uses the following terms and 186 acronyms: 188 CRUD: CRUD stands for Create/Read/Update/Delete and indicates a 189 design pattern supporting creating, retrieving, updating and 190 destroying objects. 191 REST: REpresentational State Transfer (REST) is an architectural 192 style, i.e., a coordinated set of architectural constraints. REST 193 is based on the consideration that a software architecture can 194 often be specified as an appropriate configuration of components, 195 data and connectors, all coordinated through constraining their 196 mutual relationships. Coordination and constraints help achieve a 197 desired set of architectural properties. [REST] 198 SOAP: Simple Object Access Protocol defined in 199 [W3C.REC-soap12-part1-20030624] and 200 [W3C.REC-soap12-part2-20030624]. 201 W3C: World Wide Web Consortium, the organization that developed the 202 SOAP and WSDL specifications referenced within this document. 204 4. Rationale and Motivation 206 This document specifies the basic operations that can create, 207 retrieve, modify and delete conference-related information in a 208 centralized conference. The core set of objects includes conference 209 blueprints, the conference itself, users, and sidebars. 211 The operations on these objects can be implemented in at least two 212 different ways, namely as remote procedure calls and by defining 213 resources. A remote procedure call (RPC) mechanism could use SOAP 214 (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC 215 -soap12-part2-20030624]), where conferences and the other objects are 216 modeled as services with associated operations. Conferences and 217 other objects are selected by their own local identifiers, such as 218 email-like names for users. This approach has the advantage that it 219 can easily define atomic operations that have well-defined error 220 conditions. 222 Alternatively, conference objects can be modeled as resources 223 identified by URIs, with the basic CRUD operations mapped to the HTTP 224 methods POST/PUT for creating objects, GET for reading objects, 225 PATCH/POST/PUT for changing objects and DELETE for deleting them. 226 Many of the objects, such as conferences, already have a natural 227 URIs. 229 In both approaches, servers will have to recreate their internal 230 state representation of the object with each update request, checking 231 parameters and triggering function invocations. In the SOAP 232 approach, it would be possible to describe a separate operation for 233 each atomic element, but that would greatly increase the complexity 234 of the protocol. The coarser-grained approach in CCMP does require 235 that the server process XML elements in updates that have not changed 236 and that there can be multiple changes in one update. 238 We assume that each update operation is atomic and either succeeds or 239 fails as a whole. Thus, a server has to first check all parameters, 240 before making any changes to the internal representation of the 241 conference object. For example, it would be undesirable to change 242 the of the conference, but then detect an invalid URI in 243 one of the and abort the remaining updates. 245 Because multiple clients can modify the same conference objects, 246 clients need to obtain the current object and then update the whole 247 object. 249 Editor's Note: Do we need locking, using WebDAV or floor control? 250 Otherwise, changes made by user A could get lost when user B wants to 251 modify some other parameter. For example, A changes the subject, B 252 adds the a service URI. 254 In summary, a REST-style approach must ensure sure that all 255 operations can be mapped to HTTP operations, while all SOAP 256 operations would use a single HTTP verb. While the RESTful approach 257 requires the use of a URI for each object, SOAP can use any token. 259 For CCMP, the resource (REST) model appears more attractive, since 260 the conference operations fit the CRUD approach. 262 It is likely that implementations and future standardization work 263 will add more conference attributes and parameters. There are three 264 types of extensions. The first and simplest type of extension adds 265 elements to the overall conference description, media descriptions or 266 descriptions of users. The XML namespace mechanism makes such 267 extensions relatively easy, although implementations still have to 268 deal with implementations that may not understand the new namespaces. 269 The CCMP "blueprintsRequest" message allows clients to determine the 270 capabilities of a specific server, reflected by the specific 271 blueprints supported by that server. 273 A second type of extension replaces the conference, user or media 274 objects with completely new schema definitions, i.e., the namespaces 275 for these objects themselves differ from the basic one defined in 276 this document. As long as the OPTIONS request remains available and 277 keeps to a mutually-understood definition, a compatible client and 278 server will be able to bootstrap themselves into using these new 279 objects. 281 Finally, it is conceivable that new object types are needed beyond 282 the core conference, user and media objects and their children. 283 These would also be introduced by namespaces and new URIs. 285 5. System Architecture 287 CCMP supports the framework for centralized conferencing. Figure 1 288 depicts a subset of the 'Conferencing System Logical Decomposition' 289 architecture from the framework for centralized conferencing 290 document. It illustrates the role that CCMP assumes within the 291 overall centralized architecture. 293 ........................................................ 294 . Conferencing System . 295 . . 296 . +---------------------------------------+ . 297 . | C O N F E R E N C E O B J E C T | . 298 . +-+-------------------------------------+ | . 299 . | C O N F E R E N C E O B J E C T | | . 300 . +-+-------------------------------------+ | | . 301 . | C O N F E R E N C E O B J E C T | | | . 302 . | | | | . 303 . | | |-+ . 304 . | |-+ . 305 . +---------------------------------------+ . 306 . ^ . 307 . | . 308 . v . 309 . +-------------------+ . 310 . | Conference Control| . 311 . | Server | . 312 . +-------------------+ . 313 . ^ . 314 .........................|.............................. 315 | 316 |Conference 317 |Control 318 |Protocol 319 | 320 | 321 .........................|.............................. 322 . V . 323 . +----------------+ . 324 . | Conference | . 325 . | Control | . 326 . | Client | . 327 . +----------------+ . 328 . . 329 . Conferencing Client . 330 ........................................................ 332 Figure 1: Conference Client Interaction 334 CCMP serves as the Conference Control Protocol, allowing the 335 conference control client to interface with the conference object 336 maintained by the conferencing system, as represented in Figure 1. 337 Conference Control is one part of functionality for advanced 338 conferencing supported by a conferencing client. Other functions are 339 discussed in the framework for centralized conferencing document and 340 related documents. 342 6. Conference Object and User Identifiers 344 This section provides an overview of the conference object and 345 conference users which are key protocol elements for creating the 346 CCMP requests and responses. The identifiers used in CCMP for the 347 conference object (XCON-URI) and conference user (XCON-USERID) are 348 introduced in the XCON framework and defined in the XCON data model 349 [I-D.ietf-xcon-common-data-model]. 351 6.1. Conference Object 353 Conference objects feature a simple dynamic inheritance-and-override 354 mechanism. Conference objects are linked into a tree, where each 355 tree node inherits attributes from its parent node. The roots of 356 these inheritance trees are also known as "blueprints". Nodes in the 357 inheritance tree can be active conferences or simply descriptions 358 that do not currently have any resources associated with them. An 359 object can mark certain of its properties as unalterable, so that 360 they cannot be overridden. 362 The schema for the conference object is defined in the XCON data 363 model. Conference objects are uniquely identified by the XCON-URI. 364 A client MAY specify a parent element that indicates the parent from 365 which the conference is to inherit values. When creating 366 conferences, the XCON-URI included by the client is only a 367 suggestion. To avoid identifier collisions and to conform to local 368 server policy, the conference control server MAY choose a different 369 identifier. 371 6.2. Conference Users and Participants 373 Each conference can have zero or more users. All conference 374 participants are users, but some users may have only administrative 375 functions and do not contribute or receive media. Users are added 376 one user at a time to simplify error reporting. Users are inherited 377 as well, so that it is easy to set up a conference that has the same 378 set of participants or a common administrator. The Conference 379 Control Server creates individual users, assigning them a unique 380 Conference User Identifier (XCON-USERID). 382 A variety of elements defined in the common element 383 as specified in the XCON data model are used to determine how a 384 specific user expects and is allowed to join a conference as a 385 participant, or users with specific privileges (e.g., observer). For 386 example, the attribute defines how the caller joins the 387 conference, with a set of defined XML elements, namely for 388 users that are allowed to dial in and for users that the 389 conference focus will be trying to reach. is the default. 391 If the conference is currently active, dial-out users are contacted 392 immediately; otherwise, they are contacted at the start of the 393 conference. The conference control server assigns a unique 394 Conference User Identifier (XCON-USERID) to each user. The 395 conference control server uses the XCON-USERID to change or delete 396 elements. Depending upon policies and privileges, specific 397 users MAY also manipulate elements. 399 In many conferences, users can dial in if they know the XCON-URI and 400 an access code shared by all conference participants. In this case, 401 the system is typically not aware of the call signaling URL. Thus, 402 the initial element does not have an entity attribute and the 403 default type of is used to support this type of user. For 404 this case, the server assigns a locally-unique URI, such as a 405 locally-scoped tel URI. The conference control server assigns a 406 unique Conference User Identifier (XCON-USERID) to these users when 407 they dial-in to join the conference. If the user supports the 408 notification event package [I-D.ietf-xcon-event-package], they can 409 receive their XCON-USERID, thus allowing them to also manipulate the 410 attribute, including the entity attribute, in the conference 411 object. 413 7. Protocol Operations 415 The primary function of the protocol defined within this document is 416 to provide a conference control client with the ability to carry out 417 operations on a conference object as a whole and on specific elements 418 within a conference object. This section describes the four basic 419 operations on a conference object: retrieve, create, change and 420 delete. The recommended HTTP method for each of the basic operations 421 is described. The XCON-URI as discussed in Section 6.1 is the 422 primary target for each of these operations. The normative protocol 423 details as to the applicability of each of the operations for the 424 various CCMP requests and responses are provided in Section 8. 426 7.1. Retrieve 428 The "retrieve" operation is used by a client to query a system for a 429 specific template in the form of a blueprint prior to the creation of 430 a conference. In this case, the "retrieve" operation often follows a 431 "blueprintsRequest" operation, although a conferencing control client 432 may be pre-configured to perform the "retrieve" operation on a 433 specific blueprint. 435 The "retrieve" operation is also used to get the current 436 representation of a specific conference object (or specific 437 parameters in the conference object) for a conference reservation or 438 an active conference. The unique conference identifier (XCON-URI) is 439 included in the CCMP request. 441 The "retrieve" operation returns the XML document describing the 442 conference object in its current state including all inherited values 443 or the specific parameters per the specific request type. Elements 444 may be marked by attributes, in particular, whether they are specific 445 to this instance or have been inherited from the parent node. 447 In the case of a RESTful implementation of the protocol, HTTP GET 448 MUST be used on XCON-URIs, so that clients can obtain data about 449 conference objects in the form of XML data model documents. 451 7.2. Create 453 The "create" operation is used by a client to create and reserve a 454 conference object or a new conference user. The creation of a 455 conference object can be explicit by requesting it to be created 456 based upon a specific blueprint, based on an existing conference 457 object (e.g., cloning a conference reservation or active conference 458 object) or based on the data included in the request. In the first 459 two cases, a specific XCON-URI MUST be included in the request. 461 When the creation of a conference object is implicit, with no 462 conference object for a blueprint or existing conference specified 463 and no data included in the request (i.e., an "empty" request sent to 464 a specific conference server), the creation and reservation of the 465 conference instance is based on the default conference object. The 466 default conference object is specific to a conference control server 467 and its specification is outside the scope of this document. 469 A client may first send a request with "retrieve" operation in order 470 to obtain all the data as defined in 471 [I-D.ietf-xcon-common-data-model] for the specific blueprint or 472 existing conference object. This would allow the client to modify 473 the data prior to sending the request with the "create" operation. 474 In this case, the request would also include all the data. If the 475 client wants to create the new conference by cloning the blueprint or 476 existing conference object, there would be no data included in the 477 request. The client may later modify this data by sending a request 478 with a "change" operation. 480 When creating conferences, any XCON-URI included by the client is 481 considered as the target conference object from which the new 482 conference is to be created. To avoid identifier collisions and to 483 conform to local server policy, the conference control server 484 typically chooses a different identifier for the newly created 485 conference object. The identifier is returned in the response. 487 In addition, the conference description MAY contain a calendar 488 element, in the iCal format in XML rendition defined in CPL [RFC3880] 489 or (preferable, if available as stable reference) xCal 490 [I-D.royer-calsch-xcal]. This description indicates when the 491 conference is active. 493 The "create" operation may also be used to create a new conference 494 user with the "userRequest" message. In this case, the 495 "userResponse" to this operation includes an XCON-USERID. 497 In the case of a RESTful implementation of the protocol, HTTP PUT 498 MUST be used to create a new object as identified by the XCON-URI or 499 XCON-USERID. 501 7.3. Change 503 The "change" operation updates the conference object as referenced by 504 the XCON-URI included in the request. A request which attempts to 505 change a non-existing object is an error, as is a request which 506 attempts to change a parameter that is inherited from a protected 507 element. 509 During the lifetime of a conference, this operation is used by a 510 conference control client to manipulate a conference object. This 511 includes the ability to manipulate specific elements in the 512 conference object through element specific requests such as 513 "userRequest" or "sideBarRequest", etc. 515 Upon receipt of a "change" operation, the conference control server 516 updates the specific elements in the referenced conference object. 517 Object properties that are not explicitly changed, remain as-is. 518 This approach allows a conference control client to manipulate 519 objects created by another application even if the manipulating 520 application does not understand all object properties. 522 In the case of a RESTful implementation of the protocol, either HTTP 523 PATCH or HTTP POST MUST be used to change the conference object 524 identified by the XCON-URI. 526 7.4. Delete 528 This conference control operation is used to delete the current 529 representation of a conference object or a specific parameter in the 530 conference object and requires the unique conference identifier 531 (XCON-URI) be provided by the client. 533 A request which attempts to delete a conference object that is being 534 referenced by a child object is an error. 536 In case of a RESTful implementation of the protocol, HTTP DELETE MUST 537 be used to delete conference objects and parameters within conference 538 objects identified by the XCON-URI. 540 8. Protocol Operations on Conference Objects 542 The primary function of CCMP is to provide a conference control 543 client with the ability to carry out specific operations (Section 7) 544 on a conference object through the protocol requests and responses. 545 In case of a RESTful implementation of the protocol, the CCMP 546 requests (Section 8.2)and responses (Section 8.3) MUST be represented 547 as HTTP requests and responses. The basic CCMP request/response 548 pairs defined in this document are: 550 blueprintsRequest/blueprintsResponse: The blueprintsRequest is used 551 to ascertain the list of blueprints available at the conference 552 server. The blueprintsResponse returns a list of the requested 553 blueprints, in the form of XCON URIs. 554 confsRequest/confsResponse: The confsRequest is used to ascertain 555 conference reservations and active conferences supported by the 556 server. The confsResponse returns a list of the requested types 557 of conference objects (i.e. Conference Reservations and/or Active 558 Conferences) supported by the specific conference server. 559 blueprintRequest/blueprintResponse: The blueprintRequest is used to 560 request an operation on a specific blueprint. 561 confRequest/confResponse: The confRequest is used to request an 562 operation on the conference object as a whole. 563 userRequest/userResponse: The userRequest is used to request an 564 operation on the "user" element in the conference object. 565 [Editor's Note: we may want to add more discrete user requests/ 566 responses as this is a very broad parameter] 567 usersRequest/usersResponse: This usersRequest is used to manipulate 568 the "users" element in the conference object, including parameters 569 such as the allowed-users-list, join-handling, etc. 570 sidebarRequest/sidebarResponse: This sidebarRequest is used to 571 retrieve the information related to a sidebar or to create, change 572 or delete a specific sidebar. [Editor's Note: the data model 573 defines a byVal and byRef sidebar type. Rather than define two 574 root operations, the preference is to have these two types 575 reflected by a parameter in the request.] 577 With respect to the above mentioned operations, we remark that the 578 difference between "blueprintsRequest" and "confsRequest" only exists 579 at the semantic level. They both ask for a list of XCON-URIs and 580 they have exactly the same format. The returned XCON-URIs, though, 581 represent blueprints in the former case, real (i.e. either active or 582 reserved) conferences in the latter. The fact that blueprints and 583 conferences share the same representation (a conference object 584 compliant with the XCON data model) is a mere coincidence. The same 585 holds for "confRequest/blueprintRequest", which aim at managing, 586 respectively, a specific conference object and a specific blueprint. 588 To simplify operations, a conference control server treats certain 589 parameters as suggestions (e.g., for the "create" and "change" 590 operations), as noted in the object description. If the conference 591 control server cannot set the parameter to the values desired, it 592 picks the next best value, according to local policy and returns the 593 values selected in the response. If the client is not satisfied with 594 these values, it simply deletes the object. 596 As illustrated above, along with the protocol requests and responses 597 for manipulating the conference object, there are also querying 598 mechanisms ("blueprintsRequest"/"blueprintsResponse" and 599 "confsRequest/confsResponse") to get information about either 600 blueprints or scheduled/active conferences supported by the server. 601 Any elements with namespaces not understood by the server are to be 602 ignored by the server. This allows a client to include optional 603 elements in requests without having to tailor its request to the 604 capabilities of each server. 606 A conference client must first discover the conference control server 607 as described in Section 8.1. The conference control server is the 608 recipient of the CCMP requests. 610 8.1. Locating a Conference Control Server 612 If a conference control client is not pre-configured to use a 613 specific conference control server for the requests, the client MUST 614 first discover the conference control server before it can send any 615 requests. The result of the discovery process, is the address of the 616 server supporting conferencing. In this document, the result is an 617 http: or https: URI, which identifies a conference server. 619 This document proposes the use of DNS to locate the conferencing 620 server. U-NAPTR resolution for conferencing takes a domain name as 621 input and produces a URI that identifies the conferencing server. 622 This process also requires an Application Service tag and an 623 Application Protocol tag, which differentiate conferencing-related 624 NAPTR records from other records for that domain. 626 Section 15.4.1 defines an Application Service tag of "XCON", which is 627 used to identify the centralized conferencing (XCON) server for a 628 particular domain. The Application Protocol tag "CCMP", defined in 629 Section 15.4.2, is used to identify an XCON server that understands 630 the CCMP protocol. 632 The NAPTR records in the following example Figure 2 demonstrate the 633 use of the Application Service and Protocol tags. Iterative NAPTR 634 resolution is used to delegate responsibility for the conferencing 635 service from "zonea.example.com." and "zoneb.example.com." to 636 "outsource.example.com.". 638 zonea.example.com. 639 ;; order pref flags 640 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 641 "" ; regex 642 outsource.example.com. ; replacement 643 ) 644 zoneb.example.com. 645 ;; order pref flags 646 IN NAPTR 100 10 "" "XCON:CCMP" ( ; service 647 "" ; regex 648 outsource.example.com. ; replacement 649 ) 650 outsource.example.com. 651 ;; order pref flags 652 IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service 653 "!*.!https://confs.example.com/!" ; regex 654 . ; replacement 655 ) 657 Figure 2: Sample XCON:CCMP Service NAPTR Records 659 Details for the "XCON" Application Service tag and the "CCMP" 660 Application Protocol tag are included in Section 15.4. 662 8.2. Constructing a CCMP Request 664 Construction of a valid CCMP request is based upon the operations 665 defined in Section 7, depending upon the function and associated 666 information desired by the conference control client. The next two 667 sections provide details of the "blueprintsRequest" and 668 "confsRequest" messages, which differ from the other CCMP messages in 669 that they are only used to ask the conference system for general 670 information (blueprints and conferences). Subsequent sections 671 summarize the CCMP requests related to the specific operations in 672 Section 7. 674 8.2.1. blueprintsRequest 676 The "blueprintsRequest" is used by a client to query a system for its 677 capabilities in terms of types of conferences supported and isn't 678 targeted toward a particular conference object. Detailed information 679 about a specific blueprint, can be subsequently obtained through the 680 blueprintRequest operation, which is used to retrieve a whole XCON 681 blueprint (in the form of a conference object) available at the 682 server. 684 The "blueprintsResponse" returns the XML namespaces that the server 685 understands and the namespaces to be used in responses that it 686 requires the client to understand. Within the conferencing system, 687 the namespaces correlate with blueprints, as specified in the XCON 688 framework. The blueprints are comprised of conference information 689 initialized to specific values and ranges. Each blueprint has a 690 corresponding XCON-URI. 692 8.2.2. confsRequest 694 The "confsRequest" is used by a client to query a system for 695 information about reserved/active conferences and isn't targeted 696 toward a particular conference object. Detailed information about a 697 specific conference, can be subsequently obtained through the 698 confRequest operation, which can be used to retrieve a whole XCON 699 conference (in the form of a conference object) available at the 700 server. 702 The "confsResponse" returns the XCON-URIs of all reserved and active 703 conferences currently hosted by the server. 705 8.2.3. Operations Requests 707 Construction of other valid CCMP requests is based upon the 708 operations defined in Section 7, depending upon the function and 709 associated information desired by the conference control client. The 710 following table summarizes specific request type and processing for 711 each of the "operations". A value of "N/A" indicates the specific 712 operation is not valid for the specific CCMP request. Following the 713 table examples for each of the HTTP operations for each of the 714 request types is provided. 716 Editors' Notes: 718 1. Sidebars need additional consideration - e.g., due to the byVal 719 and byRef options, it's messy. Operations approach may need 720 additional consideration (or we need separate request types). 722 +---------------+------------+------------+------------+------------+ 723 | Operation | Retrieve | Create | Change | Delete | 724 | (HTTP method) | (GET) | (PUT) | (PATCH or | (DELETE) | 725 | ------------- | | | POST) | | 726 | Request Type | | | | | 727 +---------------+------------+------------+------------+------------+ 728 | blueprintsReq | Gets list | N/A | N/A | N/A | 729 | uest | of | | | | 730 | | available | | | | 731 | | blueprints | | | | 732 | ------------- | ---------- | ---------- | ---------- | ---------- | 733 | confsRequest | Gets list | N/A | N/A | N/A | 734 | | of active | | | | 735 | | or | | | | 736 | | reserved | | | | 737 | | confs | | | | 738 | ------------- | ---------- | ---------- | ---------- | ---------- | 739 | blueprintRequ | Gets a | Creates a | Changes a | Deletes a | 740 | est | specific | blueprint | blueprint | blueprint | 741 | | blueprint | (needs | (needs | (needs | 742 | | | admin | admin | admin | 743 | | | privileges | privileges | privileges | 744 | | | ) | ) | ) | 745 | ------------- | ---------- | ---------- | ---------- | ---------- | 746 | confRequest | Gets | Creates | Changes | Deletes | 747 | | conference | conference | conference | conference | 748 | | object | object | object | Object as | 749 | | | | | a whole | 750 | ------------- | ---------- | ---------- | ---------- | ---------- | 751 | userRequest | Gets a | Creates a | Modifies | Deletes a | 752 | | specific | user and | the | user | 753 | | user | associated | specified | element as | 754 | | element | XCON-UserI | user | a whole | 755 | | | D | element | | 756 | ------------- | ---------- | ---------- | ---------- | ---------- | 757 | usersRequest | Gets a | N/A | Modifies | Deletes a | 758 | | specific | | the | users | 759 | | users | | specified | element as | 760 | | element | | users | a whole | 761 | | | | element | | 762 | ------------- | ---------- | ---------- | ---------- | ---------- | 763 | sidebarReques | Gets a | Creates a | Modifies a | Removes/de | 764 | t | sidebar | new | sidebar by | l etes the | 765 | | element by | sidebar by | Val | entire | 766 | | Val or by | Val | | sidebar b | 767 | | Ref | | | y Val | 768 +---------------+------------+------------+------------+------------+ 770 Table 1: Request Type Operation Specific Processing 772 The following provides HTTP examples for each of the valid operations 773 for each request type in the above table Table 1 775 o blueprintsRequest: GET /blueprints 776 o confsRequest: GET /confs 777 o blueprintRequest 778 * GET /blueprint/blueprintId 779 * PUT /blueprint/blueprintId 780 * POST /blueprint/blueprintId 781 * DELETE /blueprint/blueprintId 782 o confRequest 783 * GET /confs/confObjId 784 * PUT /confs/confObjId 785 * POST /confs/confObjId 786 * DELETE /confs/confObjId 787 o userRequest 788 * GET /user/confUserId 789 * PUT /user/confUserId 790 * POST /user/confUserId 791 * DELETE /user/confUserId 792 o usersRequest 793 * GET /confs/confObjId/users 794 * POST /confs/confObjId/users 795 * DELETE /confs/confObjId/users 796 o sidebarRequest 797 * By val: GET /confs/confObjId/sidebars/entityAttribute 798 * By val: N/A (use a "confRequest" message with a "change" 799 operation for this) 800 * By val: N/A (use a "confRequest" message with a "change" 801 operation for this) 802 * By val: N/A (use a "confRequest" message with a "change" 803 operation for this) 804 * By ref: GET /sidebars/sidebarId 806 8.3. Handling a CCMP Response 808 A response to the CCMP request MUST contain a response code and may 809 contain other elements depending upon the specific request and the 810 value of the response code. 812 In case of a RESTful implementation, the CCMP response message MUST 813 be enclosed in a HTTP response message. CCMP-related error codes 814 will be carried in the body of the response: no mapping is proposed 815 in this document regarding the potential association between CCMP and 816 HTTP error codes. For the sake of adhering to the principle of 817 separation of concerns, HTTP maintains its own semantics, while 818 delegating to the CCMP response message (which is in the body of the 819 HTTP response) the task of informing the CCMP client about error 820 conditions. This means that, in case of a CCMP error, the client 821 receives a 200 OK in the HTTP response, but a CCMP-specific response 822 code in the body of such response. 824 All response codes are application-level, and MUST only be provided 825 in successfully processed transport-level responses. For example 826 where HTTP is used, CCMP Response messages MUST be accompanied by a 827 200 OK HTTP response. 829 The set of CCMP Response codes currently contain the following 830 tokens: 832 success: This code indicates that the request was successfully 833 processed. 834 modified: This code indicates that the object was created, but may 835 differ from the request. 836 badRequest: This code indicates that the request was badly formed in 837 some fashion. 838 unauthorized: This code indicates that the user was not authorized 839 for the specific operation on the conference object. 840 forbidden: This code indicates that the specific operation is not 841 valid for the target conference object. 842 objectNotFound: This code indicates that the specific conference 843 object was not found. 844 operationNotAllowed: This code indicates that the specific operation 845 is not allowed for the target conference object (e.g.., when 846 trying to make a "confRequest" operation with a request type equal 847 to "delete" on a conference object representing a blueprint, etc.) 848 deleteFailedParent: This code indicates that the conferencing system 849 cannot delete the specific conference object because it is a 850 parent for another conference object. 851 changeFailedProtected: This code indicates that the target 852 conference object cannot be changed (e.g., due to policies, roles, 853 privileges, etc.). 854 requestTimeout: This code indicates that the request could not be 855 processed within a reasonable time, with the time specific to a 856 conferencing system implementation. 858 serverInternalError: This code indicates that the conferencing 859 system experienced some sort of internal error. 860 notImplemented: This code indicates that the specific operation is 861 not implemented on that conferencing system. 863 CCMP Response codes are defined to allow for extensibility. A 864 conference control client SHOULD treat unrecognized response codes as 865 it handles a Response code of "notImplemented". 867 8.3.1. blueprintsResponse 869 A "blueprintsResponse" message containing a response code of 870 "success" MUST include the XML namespaces that the server understands 871 and the namespaces to be used in subsequent responses that it 872 requires the client to understand. Future work may add more global 873 capabilities rather than conferencing system specific. Within the 874 conferencing system, the namespaces correlate with blueprints, as 875 specified in the XCON framework. The blueprints are comprised of 876 conference information initialized to specific values and ranges. 878 Upon receipt of a successful "blueprintsResponse" message, a 879 conference control client may then initiate a "blueprintRequest" with 880 a "retrieve" operation per Section 7.1 to get a specific conference 881 blueprint. 883 In the case of a response code of "requestTimeout", a conference 884 control client MAY re-attempt the request within a period of time 885 that would be specific to a conference control client or conference 886 control server. 888 The response codes of "modified", "deleteParentFailed" and 889 "changeFailedProtected" are not applicable to a "blueprintsRequest" 890 and should be treated as "serverInternalError", the handling of which 891 is specific to the conference control client. 893 A "blueprintsResponse" message containing any other response code is 894 an error and the handling is specific to the conference control 895 client. Typically, an error for a "blueprintsRequest" indicates a 896 configuration problem in the conference control server or in the 897 client. 899 8.3.2. confsResponse 901 A "confsResponse" message containing a response code of "success" 902 MUST include the list of XCON-URIs associated with reserved/active 903 conferences at the server. 905 Upon receipt of a successful "confsResponse" message, a conference 906 control client may then initiate a "confRequest" with a "retrieve" 907 operation per Section 7.1 to get a specific conference object. 909 In the case of a response code of "requestTimeout", a conference 910 control client MAY re-attempt the request within a period of time 911 that would be specific to a conference control client or conference 912 control server. 914 The response codes of "modified", "deleteParentFailed" and 915 "changeFailedProtected" are not applicable to a "confsRequest" and 916 should be treated as "serverInternalError", the handling of which is 917 specific to the conference control client. 919 A "confsResponse" message containing any other response code is an 920 error and the handling is specific to the conference control client. 921 Typically, an error for a "blueprintsRequest" indicates a 922 configuration problem in the conference control server or in the 923 client. 925 8.3.3. Operation Responses 927 The following sections detail the operation specific handling of the 928 response codes, including details associated with specific types of 929 responses in the cases where the response handling is not generic. 931 8.3.3.1. Retrieve Operation Responses 933 A confResponse for a "retrieve" operation containing a response code 934 of "success" MUST contain the full XML document describing the 935 conference object in its current state including all inherited 936 values. Elements may be marked by attributes, in particular, whether 937 they are specific to this instance or have been inherited from the 938 parent node. 940 A blueprintResponse for a "retrieve" operation containing a response 941 code of "success" MUST contain the full XML document describing the 942 conference object associated with the requested blueprint 944 Any other CCMP response message (e.g., userResponse, usersResponse, 945 etc.) for a "retrieve" operation containing a response code of 946 "success" MUST contain the XML document describing the specific 947 target parameter (as indicated by the specific type of Request) from 948 the conference object. 950 If a response code of "objectNotFound" is received in a 951 "blueprintResponse" message to a "blueprintRequest" to get the 952 initial blueprint, it is RECOMMENDED that a conference control client 953 attempt to retrieve another conference blueprint if more than one had 954 been received in the "blueprintsResponse" message. If there was only 955 one blueprint in the "blueprintsResponse" initially, then the client 956 should send another "blueprintsRequest" message to determine if there 957 may be new or additional blueprints for the specific conferencing 958 system. If this "blueprintsResponse" message contains no blueprints, 959 the handling is specific to the conference control client. This 960 might indicate, for example, that something is going wrong at the 961 server, since no more blueprints are now available at it. In such 962 case, the client MAY interpret the new answer as a 963 'serverInternalError' and assume that no more service associated with 964 blueprints (e.g. creation of a new conference starting from a server- 965 side template) is available. 967 If a response code of "requestTimeout" is received in the CCMP 968 response, a conference control client MAY re-attempt the request 969 within a period of time that would be specific to a conference 970 control client or conference control server. 972 Response codes such as "notImplemented" and "forbidden" indicate that 973 a subsequent "retrieve" would not likely be sucessful. Handling of 974 these and other response codes is specific to the conference control 975 client. For example, in the case of some clients a 976 "blueprintsRequest" operation might be performed again or another 977 conference control server may be accessed. 979 The response codes of "modified", "deleteParentFailed" and 980 "changeFailedProtected" are not applicable to the "retrieve" 981 operation and SHOULD be treated as "serverInternalError", the 982 handling of which is specific to the conference control client. 984 8.3.3.2. Create Operation Responses 986 The only valid responses containing a "create" operation are a 987 "confResponse", a "blueprintResponse" and the "userResponse". The 988 "blueprintRequest" containing a "create" operation has to be 989 considered a special operation, used by a conference server 990 administrator wishing to remotely add a new blueprint to the 991 conference server. The operation requires that the new blueprint is 992 associated with an XCON-URI. Such URI is provided by the 993 administrator in the request, but has to be considered as a 994 suggestion. The conference server MAY change such identifier and 995 create a new one. The new identifier MUST be returned to the client 996 as part of the "blueprintResponse" message. If the CCMP response 997 contains a response code of "success", a "confResponse" message MUST 998 contain the XCON-URI for the conference object and a "userResponse" 999 message MUST contain the XCON-USERID. 1001 If the confResponse to a "create" operation contains a response code 1002 of "modified", along with the XCON-URI for the conference object, the 1003 response MUST also contain the entire XML document associated with 1004 that conference object for a "confRequest". For example, in the case 1005 where the conference object contained a calendar element, the 1006 conference server may only offer a subset of the dates requested, 1007 thus the updated dates are included in the returned XML document. 1009 In the case of a response code of "requestTimeout", a conference 1010 control client MAY re-attempt the request within a period of time 1011 that would be specific to a conference control client or conference 1012 control server. 1014 Response codes such as "unauthorized", "forbidden" and 1015 "operationNotAllowed" indicate the client does not have the 1016 appropriate permissions, there is an error in the permissions, or 1017 there is a system error in the client or conference control server, 1018 thus re-attempting the request would likely not succeed. 1020 The response codes of "deleteParentFailed" and 1021 "changeFailedProtected" are not applicable to the "create" operation 1022 and SHOULD be treated as "serverInternalError", the handling of which 1023 is specific to the conference control client. 1025 Any other response code indicates an error in the client or 1026 conference control server (e.g., "forbidden", "badRequest") and the 1027 handling is specific to the conference control client. 1029 8.3.3.3. Change Operation Responses 1031 If the CCMP response to the "change" operation contains a response 1032 code of "success", the response SHOULD also contain the XCON-URI for 1033 the conference object that was changed. 1035 The "blueprintRequest" containing a "change" operation has to be 1036 considered a special operation, used by a conference server 1037 administrator wishing to remotely an existing blueprint in the 1038 conference server. 1040 If the CCMP response to the "change" operation contains a response 1041 code of "modified", the response MUST contain the XCON-URI for the 1042 conference object and the appropriate XML document (either the full 1043 XML document for a confResponse or specific paramaters for the other 1044 CCMP request types) associated with that conference object. For 1045 example, a conferencing system may not have the resources to support 1046 specific capabilities that were changed, such as in the 1047 , thus the supported are included in the 1048 returned XML document. 1050 If the CCMP response code of "requestTimeout" is received, a 1051 conference control client MAY re-attempt the request within a period 1052 of time that would be specific to a conference control client or 1053 conference control server. 1055 Response codes such as "unauthorized", "forbidden", 1056 "operationNotAllowed" and "changeFailedProtected" indicate the client 1057 does not have the appropriate permissions, the conference is locked, 1058 there is an error in the permissions, or there is a system error in 1059 the client or conference control server, thus re-attempting the 1060 request would likely not succeed. 1062 The response code of "deleteParentFailed" is not applicable to the 1063 "change" operation and SHOULD be treated as "serverInternalError", 1064 the handling of which is specific to the conference control client. 1066 Any other response code indicates an error in the client or 1067 conference control server (e.g., "forbidden", "badRequest") and the 1068 handling is specific to the conference control client. 1070 [Note by spromano: In case of "change" with a userRequest, the server 1071 first has to change the user's information stored; then, it has to 1072 update all conference objects which include that user. The 1073 association between the user and the conferences in which she/he is 1074 participating is guaranteed through the "entity" attribute of the 1075 element. IMO, after doing all that, the server just answers 1076 with a userResponse message; then, if it is also using notifications, 1077 it might raise events towards the interested subscribers, to notify 1078 them about the changes in the updated conference objects. Is this 1079 right??] 1081 8.3.3.4. Delete Operation Responses 1083 If the CCMP response to the "delete" operation contains a response 1084 code of "success", the response MUST contain the XCON-URI for the 1085 conference object that was deleted for a "confResponse" or whose data 1086 element(s) were deleted for the other response types. 1088 The "blueprintRequest" containing a "delete" operation has to be 1089 considered a special operation, used by a conference server 1090 administrator wishing to remotely remove a blueprint from the 1091 conference server. 1093 The response code of "deleteParentFailed" indicates that the 1094 conference object could not be deleted because it is the Parent of 1095 another conference object that is in use. In this case, the response 1096 also includes the XCON-URI for the conference object and is only 1097 applicable to a "confResponse". If this response code is received 1098 for any other type of CCMP response, it should be treated as 1099 "serverInternalError", the handling of which is specific to the 1100 conference control client. 1102 If a response code of "requestTimeout" is received, a conference 1103 control client MAY re-attempt the request within a period of time 1104 that would be specific to a conference control client or conference 1105 control server. 1107 Response codes such as "unauthorized", "forbidden" and 1108 "operationNotAllowed" indicate the client does not have the 1109 appropriate permissions, the conference is locked, the object that 1110 the client is trying to delete is actually a blueprint, there is an 1111 error in the permissions, or there is a system error in the client or 1112 conference control server, thus re-attempting the request would 1113 likely not succeed. 1115 The response code of "changeFailedProtected" is not applicable to the 1116 "delete" operation and SHOULD be treated as "serverInternalError", 1117 the handling of which is specific to the conference control client. 1119 Any other response code indicates an error in the client or 1120 conference control server (e.g., "forbidden", "badRequest") and the 1121 handling is specific to the conference control client. 1123 [Note by spromano (same comment as for "change"): In case of "delete" 1124 with a userRequest, the server first has to delete the user's 1125 information stored; then, it has to update all conference objects 1126 which include that user. The association between the user and the 1127 conferences in which she/he is participating is guaranteed through 1128 the "entity" attribute of the element. IMO, after doing all 1129 that, the server just answers with a userResponse message; then, if 1130 it is also using notifications, it might raise events towards the 1131 interested subscribers, to notify them about the changes in the 1132 updated conference objects. Is this right??] 1134 9. Managing sidebars 1136 Sidebars can be either "by reference" or "by value". The management 1137 of sidebars differs in the two cases, as discussed below 1139 9.1. Sidebars by value 1141 Sidebars by value represent an inner part of the conference object 1142 associated with the root conference from which they stem. One or 1143 more sidebars by value are then created by using the "confRequest" 1144 message with an operation of "change". The conference description 1145 provided in the request MUST contain the desired sidebars 1146 information, in the form of a sequence of one or more 1147 elements under the element. Information about a 1148 sidebar by value can be accessed directly through a "sidebarRequest" 1149 message containing the identifier of the required sidebar (i.e. its 1150 "entity" attribute value). 1152 9.2. Sidebars by reference 1154 Sidebars by reference represent semi-independent conference objects, 1155 i.e. objects that exist on their own, but which are strictly coupled 1156 to the conference object from which they stem. A sidebar by 1157 reference is then created by using the "confRequest" message with an 1158 operation of "create". 1160 Editor's Note: should we have a means to indicate that the object we 1161 are creating is actually a sidebar? This would go in the 1162 confRequest/create message. Otherwise, we might add a 1163 sidebarRequest/create operation which basically does a conference 1164 creation, but, e.g., stores it in a different repository (/sidebars 1165 rather than /confs). 1167 Once the sidebar has been created, you can add it to a conference by 1168 issuing a "confRequest" message with a "change" operation on the 1169 conference object which the sidebar belongs to. Information about a 1170 sidebar by reference can be accessed directly through a 1171 "sidebarRequest" message containing the identifier of the required 1172 sidebar (i.e. the value of its element). 1174 10. Protocol Parameters 1176 This section describes in detail the parameters that are used for the 1177 CCMP protocol. 1179 10.1. Operation Parameter 1181 The "operation" attribute is a mandatory token included in all CCMP 1182 request and response messages. This document defines four possible 1183 values for this parameter: "retrieve", "create", "change" and 1184 "delete". 1186 10.2. ConfObjID Parameter 1188 The "confObjID" attribute is an optional URI included in the CCMP 1189 request and response messages. This attribute is required in the 1190 case of an "operation" of "retrieve", "change", and "delete" in the 1191 CCMP request and response messages. The attribute is optional for an 1192 "operation" of "create" in the "confRequest" message. The "create" 1193 cases for which this parameter is REQUIRED are described in 1194 Section 7.2. This attribute is the XCON-URI which is the target for 1195 the specific operation. [Editor's Note: it might be good to re- 1196 iterate the normative text here.] 1198 This attribute is not included in the "userRequest" message for an 1199 operation of "create". In this case, the conference control client 1200 is requesting the creation of a new conference user, as detailed in 1201 Section 10.3. 1203 In the cases where the "conference-info" parameter Section 10.6 is 1204 also included in the requests and responses, the "confObjID" MUST 1205 match the XCON-URI in the "entity" attribute. 1207 10.3. ConfUserID Parameter 1209 The "confUserID" attribute is optional URI included in the CCMP 1210 request and response messages. This is the XCON-USERID for the 1211 conference control client initiating the request. The attribute is 1212 required in the CCMP request and response messages with the exception 1213 of the "userRequest" message. The "confUserID" parameter is used to 1214 determine if the conference control client has the authority to 1215 perform the operation. Note that the details for authorization and 1216 related policy are specified in a separate document [TBD]. 1218 This attribute is optional only for an "userRequest" message with a 1219 "create" operation. In this case, the request MUST include 1220 information about the user in the "user" element. At a minimum, the 1221 request MUST include the "user" element with an "entity" attribute. 1222 For this case, the conference control server MUST create a new 1223 conference user and return the associated confUserID in the response, 1224 if the allocation of a new XCON-USERID is succesful. 1226 In the case where there is a confUserID in the request that has 1227 already been allocated, this request may be the creation of a 1228 confUserID for the conference control client to take on an additional 1229 role. 1231 This attribute is required in the "userResponse" message in the case 1232 of an "operation" of "create" and for all other responses. 1234 10.4. ResponseCode Parameter 1236 The "responseCode" attribute is a mandatory parameter in all CCMP 1237 response messages. The values for each of the "responseCode" values 1238 are detailed in Section 8.3 with the associated processing described 1239 in Section 8.3.3. 1241 10.5. Blueprints Parameter 1243 The "blueprints" attribute is an optional parameter in the CCMP 1244 blueprintsResponse message. In the case of a "blueprintsRequest" 1245 message, the "blueprintsResponse" message with a "responseCode" of 1246 "success" SHOULD include the "blueprints" supported by the conference 1247 control server. The "blueprints" attribute is comprised of a list of 1248 blueprints supported by the specific conference server and includes a 1249 conference system specific "blueprintName" and a "confObjID" in the 1250 form of an XCON-URI for each of the blueprints. 1252 10.6. Conference-info Parameter 1254 The "conference-info" element is optional in the CCMP confRequest and 1255 confResponse messages. 1257 The "conference-info" element contains the data for the conference 1258 object that is the target for the "confRequest" operations for 1259 "create", "change" and "delete" operations. It is returned in a 1260 "confResponse" if the "confResponse" contains a responseCode of 1261 "modified" or if the original CCMP request for the "create" operation 1262 did not contain a "conference-info" element. The latter case occurs 1263 when a conference control client sends a "confRequest" containing any 1264 of the following: - a "confObjID" associated with a specific 1265 blueprint - a "confObjID associated with a specific active conference 1266 or conference reservation that was included in a "confsResponse" 1267 message - no "confObjID" (or "conference-info") element, in which 1268 case the request is to create a conference object based on a default 1269 provided by a conferencing system. 1271 The "conference-info" element is also returned in a "userResponse" 1272 message, in the case of a "change" operation. In such case, in fact, 1273 the request contains the element to be added to the conference 1274 indicated in the parameter; the associated answer SHOULD 1275 carry the updated conference object in its body. 1277 The details on the information that may be included in the 1278 "conference-info" element MUST follow the rules as specified in the 1279 XCON Data Model document [I-D.ietf-xcon-common-data-model]. The 1280 conference control client and conference control server MUST follow 1281 those rules in generating the "conference-info" in any of the CCMP 1282 request and response messages. 1284 Note that the "conference-info" element is not explicitly shown in 1285 the XML schema (Section 12) due to XML schema constraints. 1287 10.7. User Parameter 1289 The "user" element contains the data for the conference user that is 1290 the target for the CCMP request operations. It is REQUIRED for all 1291 "userRequest" messages. 1293 The details on the information that may be included in the "user" 1294 element MUST follow the rules as specified in the XCON Data Model 1295 document [I-D.ietf-xcon-common-data-model]. The conference control 1296 client and conference control server MUST follow those rules in 1297 generating the "user" in any of the CCMP request and response 1298 messages. 1300 Note that the "user" element is not explicitly shown in the XML 1301 schema Section 12 due to XML schema constraints. 1303 10.8. Users Parameter 1305 The "users" element contains the data for the conference users that 1306 are the target for the CCMP request operations. It is REQUIRED for 1307 all "usersRequest" messages. 1309 The details on the information that may be included in the "users" 1310 element MUST follow the rules as specified in the XCON Data Model 1311 document [I-D.ietf-xcon-common-data-model]. The conference control 1312 client and conference control server MUST follow those rules in 1313 generating the "users" in any of the CCMP request and response 1314 messages. 1316 Note that the "users" element is not explicitly shown in the XML 1317 schema Section 12 due to XML schema constraints. 1319 10.9. Sidebar Parameters 1321 The "sidebar" parameter contains the data for the sidebar that is the 1322 target for the CCMP request operations. It is REQUIRED for all 1323 "sidebarRequest" messages. There are two elements associated with a 1324 sidebar: "sidebar-by-val" and "sidebar-by-ref". The elements relate 1325 to whether the data for the sidebar is in the same conference object 1326 for which it serves as a sidebar or whether a new conference object 1327 is created for the sidebar. 1329 The details on the information that may be included in the "sidebar- 1330 by-val" or "sidebar-by-ref" element MUST follow the rules as 1331 specified in the XCON Data Model document 1332 [I-D.ietf-xcon-common-data-model]. The conference control client and 1333 conference control server MUST follow those rules in generating the 1334 "sidebar-by-val" or "sidebar-by-ref" element in any of the CCMP 1335 request and response messages. 1337 11. Examples 1339 Examples on the use of HTTP as the CCP based on a RESTful 1340 implementation are provided in Section 11.1. The body of the HTTP 1341 methods contains the CCMP operations and data. Examples of the CCMP 1342 operations and related data are provided in section Section 11.2 1344 11.1. HTTP methods for realizing a RESTful CCMP 1346 This section provides a series of examples using the HTTP methods for 1347 realization of the CCMP. The examples provide a sequence of 1348 operations that a typical user might invoke in activating a 1349 conference, adding users to a conference, retrieving conference data 1350 and then deleting an active conference. Note, the examples do not 1351 include any details beyond the basic operation. For example, the 1352 "Host" that would be the result of discovery of the conference server 1353 per Section 8.1 would be included in the HTTP messages. 1355 Alice retrieves info about active/scheduled CCMP 'conferences': 1357 CCMP client "Alice" ConfS 1358 | | 1359 | GET /confs | 1360 |--------------------------------------------->| 1361 | |--+ Prepare 1362 | | | formatted 1363 | 200 OK (w/ body) |<-+ conf info 1364 |<---------------------------------------------| (list of 1365 | | conf objs) 1367 Figure 3: Getting a List of Active Coferences 1369 Alice is now able to retrieve info about a specific conference: 1371 CCMP client "Alice" ConfS 1372 | | 1373 | GET /confs/confid-34fg67h | 1374 |--------------------------------------------->| 1375 | |--+ Prepare 1376 | | | formatted 1377 | 200 OK (w/ body) |<-+ XML info 1378 |<---------------------------------------------| 1379 | | 1381 Figure 4: Getting a Specific Coference 1383 Alice decides to add a new user to this conference: 1385 CCMP client "Alice" ConfS 1386 | | 1387 | PUT /confs/confid-34fg67h/users/pippo876 | 1388 | (w/ body=new user info) | 1389 |--------------------------------------------->| 1390 | |--+ Add new user 1391 | | | to data model 1392 | 200 OK (w/ body) |<-+ and update 1393 |<---------------------------------------------| user in system 1394 | | 1395 | | (event triggered 1396 | | e.g. RFC4575) 1397 | |----------------> 1398 | | 1400 Figure 5: Adding a New User to an Active Conference 1402 Subsequent GETs on both the conference object as a whole and the 1403 users portion reflect the addition of the New User: 1405 CCMP client "Alice" ConfS 1406 | | 1407 | GET /confs/confid-34fg67h/users/pippo876 | 1408 |--------------------------------------------->| 1409 | |--+ Prepare 1410 | | | formatted 1411 | 200 OK (w/ body) |<-+ XML info 1412 |<---------------------------------------------| 1413 | | 1414 | GET /users/pippo876 | 1415 |--------------------------------------------->| 1416 | |--+ Prepare 1417 | | | formatted 1418 | 200 OK (w/ body) |<-+ XML info 1419 |<---------------------------------------------| 1420 | | 1422 Figure 6: Getting a Specific Conference Object after Changes 1424 Alice updates some info related to the same user: 1426 CCMP client "Alice" ConfS 1427 | | 1428 | POST /confs/confid-34fg67h/users/pippo876 | 1429 | (w/ body=updated user info) | 1430 |--------------------------------------------->| 1431 | |--+ Update user 1432 | | | in data 1433 | 200 OK (w/ body) |<-+ and in 1434 |<---------------------------------------------| system 1435 | | 1436 | |Event trigger 1437 | |e.g. RFC4575 1438 | |-------------> 1439 | | 1440 Figure 7: Updating a User's Information 1442 Alice destroys the running conference: when trying to access it, the 1443 server returns an error: 1445 CCMP client "Alice" ConfS 1446 | | 1447 | DELETE /confs/confid-34fg67h | 1448 |--------------------------------------------->| 1449 | |--+ Prepare 1450 | | | formatted 1451 | 200 OK (w/ body) |<-+ XML info 1452 |<---------------------------------------------| 1453 | | 1454 | GET /confs/confid-34fg67h | 1455 |--------------------------------------------->| 1456 | |--+ ConfS can't 1457 | | | find the 1458 | 200 OK (w/body: |<-+ conference 1459 |<---------------------------------------------| 1460 | responseCode=objectNotFound | 1461 | | 1463 Figure 8: Deleting an Active Coference 1465 11.2. CCMP Detailed Message Body Examples 1467 The examples below contain simply the of the requests and 1468 responses. In the case that HTTP serves as the transport, the HTTP 1469 methods as identified in Table 1 (and per the examples in 1470 Section 11.1) would include the CCMP requests and Responses as the 1471 body of the HTTP methods. 1473 11.2.1. Creating a New Conference 1475 The first example creates a new conference. 1477 1478 create 1479 userA-confxyz987 1481 1484 1485 http://example.com/conf200 1486 Agenda: This month's goals 1487 1488 1489 sips:conf223@example.com 1490 participation 1491 1492 1493 1494 1495 http://sharep/salesgroup/ 1496 web-page 1497 1498 1499 http://example.com/conf233 1500 control 1501 1502 1503 1504 1506 1508 Figure 9: Create Request Example 1510 The response to this request is shown below; it returns the object 1511 identifier as a URL and the final conference description, which may 1512 modify the description offered by the user. 1514 create 1516 modified 1517 xcon:confxyz987@example.com 1518 userA-confxyz987 1520 1523 xcon:confxyz987@example.com 1524 1525 http://example.com/conf200 1526 Agenda: This month's goals 1527 1528 1529 sips:conf223@example.com 1530 participation 1531 1532 1533 1534 1535 http://sharep/salesgroup/ 1536 web-page 1537 1538 1539 http://example.com/conf233 1540 control 1541 1542 1544 1547 1548 1549 1550 1551 1553 1554 1556 1558 Figure 10: Create Response Example 1560 11.2.2. Creating a New Conference User 1562 The request below creates a new conference user, independent of a 1563 specific conference object. 1565 1566 create 1568 1569 observer 1570 1572 1574 Figure 11: Create User Example 1576 The response to this request is shown below; it returns the 1577 conference user identifier. 1579 1580 create 1581 success 1582 userC-confxyz987 1583 1585 Figure 12: Create Response Example 1587 11.2.3. Adding a User to a Conference 1589 The request below adds a user to the conference identified by the 1590 XCON-URI. Note that the user in "confUserID" element is the user 1591 requesting that the user "sip:claire@example.com" be added to the 1592 conference. The user may or may not be "claire" (i.e., a user, such 1593 as the moderator, can add another user to the conference. 1595 Editor's note: Do we need to consider users adding users OBO of other 1596 users or in that case do we just change the conference object as a 1597 whole? 1598 1599 change 1600 xcon:confxyz987@example.com 1601 userC-confxyz987 1603 1604 participant 1605 dial-out 1606 1608 1610 Figure 13: Add User Example 1612 The response to this request is shown below. 1614 1615 change 1616 success 1617 xcon:confxyz987@example.com 1618 userC-confxyz987 1620 1621 participant 1622 1623 1624 1625 1627 1629 Figure 14: Add User Response Example 1631 12. XML Schema 1633 This section provides the XML schema definition of the "application/ 1634 ccmp+xml" format. 1636 Editor's Note: the schema currently matches the prototype - it needs 1637 updating to include changes/additions to request names (e.g., 1638 optionsRequest -> blueprintsRequest, addition of blueprintRequest and 1639 confsRequest. 1641 1642 1649 1650 1654 1656 1659 1661 1662 1663 1665 1666 1668 1670 1672 1673 1674 1676 1677 1679 1681 1684 1686 1687 1690 1692 1693 1695 1697 1699 1700 1701 1702 1704 1706 1707 1708 1709 1710 1712 1714 1715 1716 1717 1718 1719 1720 1721 1722 1724 1726 1727 1728 1729 1730 1731 1732 1733 1734 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1747 1749 1751 1753 1754 1756 1758 1760 1761 1763 1765 1766 1767 1768 1769 1770 1771 1772 1773 1775 1777 1778 1779 1780 1781 1782 1783 1784 1786 1788 1790 1791 1792 1793 1794 1795 1796 1797 1798 1800 1802 1803 1804 1805 1806 1807 1808 1809 1810 1812 1814 1815 1816 1817 1818 1819 1820 1821 1822 1824 1826 1828 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1848 1850 1853 1854 1855 1858 1859 1861 1862 1863 1864 1865 1867 1869 1872 1873 1874 1877 1878 1879 1881 1884 1885 1886 1890 1893 1894 1896 1898 1900 1901 1902 1906 1909 1910 1912 1914 1916 1917 1918 1922 1925 1926 1928 1930 1933 1934 1935 1939 1942 1943 1945 1947 1950 1951 1952 1956 1959 1960 1962 1964 1967 1968 1969 1973 1977 1978 1980 1982 1983 1984 1985 1986 1987 1988 1989 1990 1992 Figure 15 1994 13. Managing notifications 1996 This section is still "Under Construction" and currently contains 1997 some views on handling notifications. 1999 One proposal is to stick with SIP notification. Another alternative, 2000 which is commonly done in other web-based systems, is a "call back", 2001 i.e., the CCMP client provides the conference server with an HTTP URL 2002 which is invoked when a change occurs. This is apparently how most 2003 credit card shopping cards work, having implemented one. This works 2004 well for our scenario since a CCMP "client" is likely to be a web 2005 server that provides the graphical HTML user interface and uses CCMP 2006 as the backend to talk to the conference server. In that particular 2007 case, there doesn't seem to be a problem of having both models. PC- 2008 based clients behind NATs would provide a SIP event URI, web servers 2009 would probably find the HTTP model much easier to program with. 2011 Another option being considered is BOSH 2012 (http://xmpp.org/extensions/xep-0124.html), which is basically an 2013 extension to XMPP designed with the following aim: "...a transport 2014 protocol that emulates a bidirectional stream between two entities 2015 (such as a client and a server) by efficiently using multiple 2016 synchronous HTTP request/response pairs without requiring the use of 2017 polling or asynchronous chunking." 2019 A final consideration (under discussion only) is basic XMPP. 2021 14. Role based access control 2023 Editors' Note: this section is also under construction. This topic 2024 is planned to be described in a separate document that will be 2025 reference here. XACML is the current proposed direction for which 2026 the authors would like feedback. 2028 15. IANA Considerations 2030 This document registers a new XML namespace, a new XML schema, and 2031 the MIME type for the schema. This document also registers the 2032 "XCON" Application Service tag and the "CCMP" Application Protocol 2033 tag. This document also defines registries for the CCMP operation 2034 types and response codes. 2036 15.1. URN Sub-Namespace Registration 2038 This section registers a new XML namespace, 2039 ""urn:ietf:params:xml:ns:xcon:ccmp"". 2041 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 2042 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 2043 Mary Barnes (mary.barnes@nortel.com). 2044 XML: 2046 BEGIN 2047 2048 2050 2051 2052 CCMP Messages 2053 2054 2055

Namespace for CCMP Messages

2056

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

2057 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2058 with the RFC number for this specification.]] 2059

See RFCXXXX.

2060 2061 2062 END 2064 15.2. XML Schema Registration 2066 This section registers an XML schema as per the guidelines in 2067 [RFC3688]. 2069 URI: urn:ietf:params:xml:schema:xcon:ccmp 2070 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 2071 Barnes (mary.barnes@nortel.com). 2072 Schema: The XML for this schema can be found as the entirety of 2073 Section 12 of this document. 2075 15.3. MIME Media Type Registration for 'application/ccmp+xml' 2077 This section registers the "application/ccmp+xml" MIME type. 2079 To: ietf-types@iana.org 2080 Subject: Registration of MIME media type application/ccmp+xml 2081 MIME media type name: application 2082 MIME subtype name: ccmp+xml 2083 Required parameters: (none) 2084 Optional parameters: charset 2085 Indicates the character encoding of enclosed XML. Default is 2086 UTF-8. 2087 Encoding considerations: Uses XML, which can employ 8-bit 2088 characters, depending on the character encoding used. See RFC 2089 3023 [RFC3023], section 3.2. 2090 Security considerations: This content type is designed to carry 2091 protocol data related conference control. Some of the data could 2092 be considered private and thus should be protected. 2093 Interoperability considerations: This content type provides a basis 2094 for a protocol 2095 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2096 replace XXXX with the RFC number for this specification.]] 2097 Applications which use this media type: Centralized Conferencing 2098 control clients and servers. 2099 Additional Information: Magic Number(s): (none) 2100 File extension(s): .xml 2101 Macintosh File Type Code(s): (none) 2102 Person & email address to contact for further information: Mary 2103 Barnes 2104 Intended usage: LIMITED USE 2105 Author/Change controller: The IETF 2106 Other information: This media type is a specialization of 2107 application/xml [RFC3023], and many of the considerations 2108 described there also apply to application/ccmp+xml. 2110 15.4. DNS Registrations 2112 Section 15.4.1 defines an Application Service tag of "XCON", which is 2113 used to identify the centralized conferencing (XCON) server for a 2114 particular domain. The Application Protocol tag "CCMP", defined in 2115 Section 15.4.2, is used to identify an XCON server that understands 2116 the CCMP protocol. 2118 15.4.1. Registration of a Location Server Application Service Tag 2120 This section registers a new S-NAPTR/U-NAPTR Application Service tag 2121 for XCON, as mandated by [RFC3958]. 2123 Application Service Tag: XCON 2125 Intended usage: Identifies a server that supports centralized 2126 conferencing. 2128 Defining publication: RFCXXXX 2130 Contact information: The authors of this document 2132 Author/Change controller: The IESG 2134 15.4.2. Registration of a Location Server Application Protocol Tag for 2135 HELD 2137 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 2138 for the CCMP protocol, as mandated by [RFC3958]. 2140 Application Service Tag: CCMP 2142 Intended Usage: Identifies the Centralized Conferencing (XCON) 2143 Manipulation Protocol. 2145 Applicable Service Tag(s): XCON 2147 Terminal NAPTR Record Type(s): U 2149 Defining Publication: RFCXXXX 2151 Contact Information: The authors of this document 2153 Author/Change Controller: The IESG 2155 15.5. CCMP Protocol Registry 2157 This document requests that the IANA create a new registry for the 2158 CCMP protocol including an initial registry for operation types and 2159 response codes. 2161 15.5.1. CCMP Message Types 2163 The CCMP messages are described in Section 8 and defined in the XML 2164 schema in Section 12. The following summarizes the requested 2165 registry: 2167 Related Registry: CCMP Message Types Registry 2168 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2169 with the RFC number for this specification.] 2170 Registration/Assignment Procedures: New CCMP message types are 2171 allocated on a specification required basis. 2172 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 2173 Barnes (mary.barnes@nortel.com). 2175 This section pre-registers the following initial CCMP message types: 2177 blueprintsRequest: Used by a conference control client to query a 2178 conferencing system for its capabilities, in terms of available 2179 conference blueprints. 2180 blueprintsResponse: The optionsResponse returns a list of Blueprints 2181 supported by the specific conference server. 2182 confsRequest: Used by a conference control client to query a 2183 conferencing system for its scheduled/active conferences. 2184 confsResponse: The confsResponse returns the list of the currently 2185 activated/scheduled conferences at the server. 2186 confRequest: The confRequest is used to create a conference object 2187 and/or to request an operation on the conference object as a 2188 whole. 2189 confResponse: The confResponse indicates the result of the operation 2190 on the conference object as a whole. 2191 userRequest: The userRequest is used to request an operation on the 2192 "user" element in the conference object. 2193 userResponse: The userResponse indicates the result of the requested 2194 operation on the "user" element in the conference object. 2195 usersRequest This usersRequest is used to manipulate the "users" 2196 element in the conference object, including parameters such as the 2197 allowed-users-list, join-handling, etc. 2198 usersResponse: This usersResponse indicates the result of the 2199 request to manipulate the "users" element in the conference 2200 object. 2202 sidebarRequest: This sidebarRequest is used to retrieve the 2203 information related to a sidebar or to create, change or delete a 2204 specific sidebar. 2205 sidebarResponse: This sidebarResponse indicates the result of the 2206 sidebarRequest. 2208 15.5.2. CCMP Response Codes 2210 The following summarizes the requested registry for CCMP Response 2211 codes: 2213 Related Registry: CCMP Response Code Registry 2214 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2215 with the RFC number for this specification.] 2216 Registration/Assignment Procedures: New response codes are allocated 2217 on a first-come/first-serve basis with specification required. 2218 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 2219 Barnes (mary.barnes@nortel.com). 2221 This section pre-registers the following thirteen initial response 2222 codes as described above in Section 8.3: 2224 success: This code indicates that the request was successfully 2225 processed. 2226 modified: This code indicates that the object was created, but may 2227 differ from the request. 2228 badRequest: This code indicates that the request was badly formed in 2229 some fashion. 2230 unauthorized: This code indicates that the user was not authorized 2231 for the specific operation on the conference object. 2232 forbidden: This code indicates that the specific operation is not 2233 valid for the target conference object. 2234 objectNotFound: This code indicates that the specific conference 2235 object was not found. 2236 operationNotAllowed: This code indicates that the specific operation 2237 is not allowed for the target conference object (e.g.., due to 2238 policies, etc.) 2239 deleteFailedParent: This code indicates that the conferencing system 2240 cannot delete the specific conference object because it is a 2241 parent for another conference object. 2242 changeFailedProtected: This code indicates that the target 2243 conference object cannot be changed (e.g., due to policies, roles, 2244 privileges, etc.). 2245 requestTimeout: This code indicates that the request could not be 2246 processed within a reasonable time, with the time specific to a 2247 conferencing system implementation. 2249 serverInternalError: This code indicates that the conferencing 2250 system experienced some sort of internal error. 2251 notImplemented: This code indicates that the specific operation is 2252 not implemented on that conferencing system. 2254 16. Security Considerations 2256 Access to conference control functionality needs to be tightly 2257 controlled to keep attackers from disrupting conferences, adding 2258 themselves to conferences or engaging in theft of services. In the 2259 case of a RESTful implementation of the CCMP, implementors need to 2260 deploy standard HTTP authentication and authorization mechanisms. 2261 Since conference information may contain secrets such as participant 2262 lists and dial-in codes, all conference control information SHOULD be 2263 carried over TLS (HTTPS). 2265 17. Acknowledgments 2267 The authors appreciate the feedback provided by Dave Morgan, Pierre 2268 Tane, Lorenzo Miniero and Tobia Castaldi 2270 18. Changes since last Version 2272 NOTE TO THE RFC-Editor: Please remove this section prior to 2273 publication as an RFC. 2275 The following summarizes the changes between the WG 00 and the 01: 2277 1. Changed the basic approach from using SOAP to REST - the 2278 fundamentals are the same in terms of schema, basic operations. 2279 This impacted most sections, in particular introduction and 2280 motivation. 2281 2. Added new request types - blueprintsRequest, blueprintRequest and 2282 confsRequest. The first replaces the optionsRequest and the 2283 latter allows the client to get a list of all active conferences. 2284 3. Merged all requests into the basic operations table. Added 2285 summary of RESTful examples (referenced by the basic operations 2286 table. 2287 4. Added examples showing RESTful approach - i.e., HTTP methods for 2288 message exchange. 2289 5. Removed requestID from the schema (it should be handle by the 2290 transport - e.g., HTTP). Updated schema (based on current 2291 prototype - it still needs another revision. 2293 6. Added placeholders for Notifications and Role Based Access 2294 Control. 2295 7. Added some text for discovery using DNS (including IANA 2296 registrations) 2297 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 2298 informational section. 2300 19. References 2302 19.1. Normative References 2304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2305 Requirement Levels", BCP 14, RFC 2119, March 1997. 2307 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2308 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2309 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2311 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2312 January 2004. 2314 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 2315 Centralized Conferencing", RFC 5239, June 2008. 2317 [I-D.ietf-xcon-common-data-model] 2318 Novo, O., Camarillo, G., Morgan, D., Even, R., and J. 2319 Urpalainen, "Conference Information Data Model for 2320 Centralized Conferencing (XCON)", 2321 draft-ietf-xcon-common-data-model-12 (work in progress), 2322 October 2008. 2324 19.2. Informative References 2326 [REST] Fielding, "Architectural Styles and the Design of Network- 2327 based Software Architectures", 2000. 2329 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2330 Types", RFC 3023, January 2001. 2332 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2333 A., Peterson, J., Sparks, R., Handley, M., and E. 2334 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2335 June 2002. 2337 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 2338 Language (CPL): A Language for User Control of Internet 2339 Telephony Services", RFC 3880, October 2004. 2341 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 2342 Service Location Using SRV RRs and the Dynamic Delegation 2343 Discovery Service (DDDS)", RFC 3958, January 2005. 2345 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 2346 RFC 3966, December 2004. 2348 [I-D.ietf-xcon-event-package] 2349 Camarillo, G., Srinivasan, S., Even, R., and J. 2350 Urpalainen, "Conference Event Package Data Format 2351 Extension for Centralized Conferencing (XCON)", 2352 draft-ietf-xcon-event-package-01 (work in progress), 2353 September 2008. 2355 [I-D.royer-calsch-xcal] 2356 Royer, D., "iCalendar in XML Format (xCal-Basic)", 2357 draft-royer-calsch-xcal-03 (work in progress), 2358 October 2005. 2360 [W3C.REC-soap12-part1-20030624] 2361 Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. 2362 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", 2363 World Wide Web Consortium FirstEdition REC-soap12-part1- 2364 20030624, June 2003, 2365 . 2367 [W3C.REC-soap12-part2-20030624] 2368 Moreau, J., Mendelsohn, N., Hadley, M., Nielsen, H., and 2369 M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 2370 Web Consortium FirstEdition REC-soap12-part2-20030624, 2371 June 2003, 2372 . 2374 Authors' Addresses 2376 Mary Barnes 2377 Nortel 2378 2201 Lakeside Blvd 2379 Richardson, TX 2381 Email: mary.barnes@nortel.com 2382 Chris Boulton 2383 Avaya 2384 Building 3 2385 Wern Fawr Lane 2386 St Mellons 2387 Cardiff, South Wales CF3 5EA 2389 Email: cboulton@avaya.com 2391 Simon Pietro Romano 2392 University of Napoli 2393 Via Claudio 21 2394 Napoli 80125 2395 Italy 2397 Email: spromano@unina.it 2399 Henning Schulzrinne 2400 Columbia University 2401 Department of Computer Science 2402 450 Computer Science Building 2403 New York, NY 10027 2405 Email: hgs+xcon@cs.columbia.edu 2407 Full Copyright Statement 2409 Copyright (C) The IETF Trust (2008). 2411 This document is subject to the rights, licenses and restrictions 2412 contained in BCP 78, and except as set forth therein, the authors 2413 retain all their rights. 2415 This document and the information contained herein are provided on an 2416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2418 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2419 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2420 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2423 Intellectual Property 2425 The IETF takes no position regarding the validity or scope of any 2426 Intellectual Property Rights or other rights that might be claimed to 2427 pertain to the implementation or use of the technology described in 2428 this document or the extent to which any license under such rights 2429 might or might not be available; nor does it represent that it has 2430 made any independent effort to identify any such rights. Information 2431 on the procedures with respect to rights in RFC documents can be 2432 found in BCP 78 and BCP 79. 2434 Copies of IPR disclosures made to the IETF Secretariat and any 2435 assurances of licenses to be made available, or the result of an 2436 attempt made to obtain a general license or permission for the use of 2437 such proprietary rights by implementers or users of this 2438 specification can be obtained from the IETF on-line IPR repository at 2439 http://www.ietf.org/ipr. 2441 The IETF invites any interested party to bring to its attention any 2442 copyrights, patents or patent applications, or other proprietary 2443 rights that may cover technology that may be required to implement 2444 this standard. Please address the information to the IETF at 2445 ietf-ipr@ietf.org.