idnits 2.17.1 draft-barnes-xcon-ccmp-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1528. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1092 has weird spacing: '...element name=...' == 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 (February 25, 2008) is 5903 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) -- Looks like a reference, but probably isn't: 'TBD' on line 780 == Unused Reference: '2' is defined on line 1409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-10 == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-09 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '9') (Obsoleted by RFC 7303) == Outdated reference: A later version (-01) exists of draft-ietf-xcon-event-package-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 12 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: August 28, 2008 Avaya 6 H. Schulzrinne 7 Columbia University 8 February 25, 2008 10 Centralized Conferencing Manipulation Protocol 11 draft-barnes-xcon-ccmp-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 45 this document provides the mechanisms to create, change and delete 46 objects related to centralized conferences, including participants, 47 their media and their roles. The protocol relies on web services and 48 SIP event notification as its infrastructure, but can control 49 conferences that use any signaling protocol to invite users. CCMP is 50 based on the Simple Object Access Protocol (SOAP), with the data 51 necessary for the interactions specified via Web Services Description 52 Language (WSDL). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 6 61 6. Conference Object and User Identifiers . . . . . . . . . . . . 8 62 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 8 63 6.2. Conference Users and Participants . . . . . . . . . . . . 8 64 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.2. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.3. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.4. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.5. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Protocol Operations on Conference Objects . . . . . . . . . . 12 71 8.1. Locating a Conference Control Server . . . . . . . . . . . 12 72 8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 12 73 8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 13 74 8.3.1. Response codes . . . . . . . . . . . . . . . . . . . . 13 75 8.3.2. Operation Responses . . . . . . . . . . . . . . . . . 14 76 9. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 17 78 9.2. Request ID Parameter . . . . . . . . . . . . . . . . . . . 18 79 9.3. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 18 80 9.4. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 18 81 9.5. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 19 82 9.6. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 19 83 9.7. Conference-info Parameter . . . . . . . . . . . . . . . . 19 84 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Creating a New Conference . . . . . . . . . . . . . . . . 20 86 10.2. Creating a New Conference User . . . . . . . . . . . . . . 22 87 10.3. Adding a User to a Conference . . . . . . . . . . . . . . 23 88 11. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 24 89 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 13. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 27 91 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 29 93 14.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 94 14.3. MIME Media Type Registration for 'application/ccmp+xml' . 30 95 14.4. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 31 96 14.4.1. CCMP Operations . . . . . . . . . . . . . . . . . . . 31 97 14.4.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 31 98 15. Security Considerations . . . . . . . . . . . . . . . . . . . 32 99 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 100 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 17.1. Normative References . . . . . . . . . . . . . . . . . . . 33 102 17.2. Informative References . . . . . . . . . . . . . . . . . . 33 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 104 Intellectual Property and Copyright Statements . . . . . . . . . . 35 106 1. Introduction 108 The Framework for Centralized Conferencing (XCON) [7]defines a 109 signaling-agnostic framework, naming conventions and logical entities 110 required for constructing advanced conferencing systems. A primary 111 concept introduced in the XCON framework is the existence of a 112 conference object. The framework introduces the conference object as 113 a logical representation of a conference instance which represents 114 the current state and capabilities of a conference. 116 The Centralized Conferencing Manipulation Protocol (CCMP) defined in 117 this document allows the creation, manipulation and deletion of a 118 conference object by authenticated and authorized clients. This 119 includes adding and removing participants, changing their roles, as 120 well as adding and removing media streams and associated end points. 122 CCMP implements a client-server model. The server is the Conference 123 Control Server defined in the XCON framework, while clients can 124 either be signaling end points, such as Session Initiation Protocol 125 (SIP) RFC 3261 [10] user agents, or control-only agents that do not 126 contribute media to the conference. 128 CCMP manipulates conferences based on their semantic properties and 129 is based on a client-server Remote Procedure Call (RPC) mechanism, 130 with the Simple Object Access Protocol (SOAP) [5] and [6] used to 131 carry out the appropriate client-server protocol transactions. 133 The common information contained in conference objects is defined 134 using an XML representation based on the schema in the XCON data 135 model [8]. These data structures are used as the basis for the Web 136 Services Description Language (WSDL) [4] definition and XML schema. 138 This document first provides some background on the motivations 139 associated with the design of CCMP in Section 4 followed by a brief 140 discussion of the system architecture in Section 5. The protocol 141 operations are then detailed in Section 7, with a discussion of the 142 key elements in the conference object in Section 6. The practical 143 sequence of protocol operations is discussed in Section 8, with 144 examples provided in Section 10. An XML schema is provided in 145 Section 12. WSDL information is detailed in Section 13. 147 2. Conventions 149 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 150 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 151 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 152 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 153 compliant implementations. 155 3. Terminology 157 This document reuses the terminology defined in the Framework for 158 Centralized Conferencing [7]. In addition, the following acronyms 159 and terms are used in this document: 161 SOAP: Simple Object Access Protocol[5][6]. 162 WSDL: Web Services Description Language[4]. WSDL is an XML format 163 for describing network services as a set of endpoints operating on 164 messages containing either document-oriented or procedure-oriented 165 information. 166 W3C: World Wide Web Consortium. The organization that developed the 167 SOAP and WSDL specifications referenced within this document. 169 4. Motivation 171 SOAP is chosen as the RPC mechanism due to its compatibility with the 172 requirements for the conference control protocol as introduced in the 173 framework for centralized conferencing. SOAP is a lightweight 174 protocol for exchange of information in a decentralized, distributed 175 environment. It is an XML-based protocol that consists of three 176 parts: an envelope that defines a framework for describing what is in 177 a message to process it, a set of encoding rules for expressing 178 instances of application-defined datatypes, and a convention for 179 representing remote procedure calls and responses. SOAP allows the 180 re-use of libraries, servers and other infrastructure and provides a 181 convenient mechanism for the formal definition of protocol syntax 182 using Web Services Description Language (WSDL). 184 WSDL is an XML format for describing network services as a set of 185 endpoints operating on messages containing either document-oriented 186 or procedure-oriented information. The operations and messages are 187 described abstractly, and then bound to a concrete network protocol 188 and message format to define an endpoint. Related concrete endpoints 189 are combined into abstract endpoints (services). WSDL is extensible 190 to allow description of endpoints and their messages regardless of 191 what message formats or network protocols are used to communicate, 192 however, the only bindings described in this document describe how to 193 use WSDL in conjunction with SOAP. 195 It is likely that implementations and future standardization work 196 will add more conference attributes and parameters. There are three 197 types of extensions. The first and simplest type of extension adds 198 elements to the overall conference description, media descriptions or 199 descriptions of users. The XML namespace mechanism makes such 200 extensions relatively easy, although implementations still have to 201 deal with implementations that may not understand the new namespaces. 202 The Options operation (Section 7.1) allows clients to determine the 203 capabilities of a specific server, reflected by the specific 204 blueprints supported by that server. 206 A second type of extension replaces the conference, user or media 207 objects with completely new schema definitions, i.e., the namespaces 208 for these objects themselves differ from the basic one defined in 209 this document. As long as the Options request remains available and 210 keeps to a mutually-understood definition, a compatible client and 211 server will be able to bootstrap themselves into using these new 212 objects. 214 Finally, it is conceivable that new object types are needed beyond 215 the core conference, user and media objects and their children. 216 These would also be introduced by namespaces. 218 5. System Architecture 220 CCMP supports the framework for centralized conferencing. Figure 1 221 depicts a subset of the 'Conferencing System Logical Decomposition' 222 architecture from the framework for centralized conferencing 223 document. It illustrates the role that CCMP assumes within the 224 overall centralized architecture. 226 ........................................................ 227 . Conferencing System . 228 . . 229 . +---------------------------------------+ . 230 . | C O N F E R E N C E O B J E C T | . 231 . +-+-------------------------------------+ | . 232 . | C O N F E R E N C E O B J E C T | | . 233 . +-+-------------------------------------+ | | . 234 . | C O N F E R E N C E O B J E C T | | | . 235 . | | | | . 236 . | | |-+ . 237 . | |-+ . 238 . +---------------------------------------+ . 239 . ^ . 240 . | . 241 . v . 242 . +-------------------+ . 243 . | Conference Control| . 244 . | Server | . 245 . +-------------------+ . 246 . ^ . 247 .........................|.............................. 248 | 249 |Conference 250 |Control 251 |Protocol 252 | 253 | 254 .........................|.............................. 255 . V . 256 . +----------------+ . 257 . | Conference | . 258 . | Control | . 259 . | Client | . 260 . +----------------+ . 261 . . 262 . Conferencing Client . 263 ........................................................ 265 Figure 1: Conference Client Interaction 267 CCMP serves as the Conference Control Protocol, allowing the 268 conference control client to interface with the conference object 269 maintained by the conferencing system, as represented in Figure 1. 270 Conference Control is one part of functionality for advanced 271 conferencing supported by a conferencing client. Other functions are 272 discussed in the framework for centralized conferencing document and 273 related documents. 275 6. Conference Object and User Identifiers 277 This section provides an overview of the conference object and 278 conference users in relation to the CCMP protocol. The identifiers 279 used in CCMP for the conference object (XCON-URI) and conference user 280 (XCON-USERID) are introduced in the XCON framework and defined in the 281 XCON data model [8] 283 6.1. Conference Object 285 Conference objects feature a simple dynamic inheritance-and-override 286 mechanism. Conference objects are linked into a tree, where each 287 tree node inherits attributes from its parent node. The roots of 288 these inheritance trees are also known as "blueprints". Nodes in the 289 inheritance tree can be active conferences or simply descriptions 290 that do not currently have any resources associated with them. An 291 object can mark certain of its properties as unalterable, so that 292 they cannot be overridden. 294 The schema for the conference object is defined in the XCON data 295 model. Conference objects are uniquely identified by the XCON-URI. 296 A client MAY specify a parent element that indicates the parent from 297 which the conference is to inherit values. When creating 298 conferences, the XCON-URI included by the client is only a 299 suggestion. To avoid identifier collisions and to conform to local 300 server policy, the conference control server MAY choose a different 301 identifier. 303 6.2. Conference Users and Participants 305 Each conference can have zero or more users. All conference 306 participants are users, but some users may have only administrative 307 functions and do not contribute or receive media. Users are added 308 one user at a time to simplify error reporting. Users are inherited 309 as well, so that it is easy to set up a conference that has the same 310 set of participants or a common administrator. The Conference 311 Control Server creates individual users, assigning them a unique 312 Conference User Identifier (XCON-USERID). 314 A variety of elements defined in the common element 315 as specified in the XCON data model are used to determine how a 316 specific user expects and is allowed to join a conference as a 317 participant, or users with specific privileges (e.g., observer). For 318 example, the attribute defines how the caller joins the 319 conference, with a set of defined XML elements, namely for 320 users that are allowed to dial in and for users that the 321 conference focus will be trying to reach. is the default. 323 If the conference is currently active, dial-out users are contacted 324 immediately; otherwise, they are contacted at the start of the 325 conference. The conference control server assigns a unique 326 Conference User Identifier (XCON-USERID) to each user. The 327 conference control server uses the XCON-USERID to change or delete 328 elements. Depending upon policies and privileges, specific 329 users MAY also manipulate elements. 331 In many conferences, users can dial in if they know the XCON-URI and 332 an access code shared by all conference participants. This type of 333 user is initially represented in the data by a element without 334 an entity attribute. Only the (default) type of is 335 permitted for this type of user. The users are identified, in the 336 entity attribute, by their call signaling URL, such as their SIP URL 337 or tel URI [12]. In cases where there is no such URI, e.g., because 338 a PSTN caller has blocked caller-ID delivery, the server assigns a 339 locally-unique URI, such as a locally-scoped tel URI. The conference 340 control server assigns a unique Conference User Identifier (XCON- 341 USERID) to these users when they dial in to join the conference. If 342 the user supports the notification event package [13], they can 343 receive their XCON-USERID, thus allowing them to also manipulate the 344 attribute in the conference object. 346 7. Protocol Operations 348 The primary function of the protocol defined within this document is 349 to provide a conference control client with the ability to carry out 350 specific operations on a conference object. This section describes 351 the generic behavior of the core protocol operations on conference 352 objects. Each object has four basic operations: retrieve, create, 353 change and delete. The XCON-URI as discussed in Section 6.1 is the 354 target for each of these operations. 356 To simplify operations, a conference control server treats certain 357 parameters as suggestions, as noted in the object description. If 358 the conference control server cannot set the parameter to the values 359 desired, it picks the next best value, according to local policy and 360 returns the values selected in the response. If the client is not 361 satisfied with these values, it simply deletes the object. 363 There is also a querying mechanism ("options") to ascertain the 364 namespaces understood by the server. Any elements with namespaces 365 not understood by the server are to be ignored by the server. This 366 allows a client to include optional elements in requests without 367 having to tailor its request to the capabilities of each server. 369 A conference control client and conference control server MUST 370 provide the ability to action all of the protocol operations in this 371 section and MUST fully implement the SOAP WSDL schema defined in 372 Section 13 which uses HTTP operations as the transport mechanism. 374 7.1. Options 376 The "options" operation is used by a client to query a system for its 377 capabilities and doesn't pertain to a particular conference object. 378 In this document, the response returns the XML namespaces that the 379 server understands and the namespaces to be used in responses that it 380 requires the client to understand. Within the conferencing system, 381 the namespaces correlate with blueprints, as specified in the XCON 382 framework. The blueprints are comprised of conference information 383 initialized to specific values and ranges. 385 7.2. Retrieve 387 The "retrieve" operation is used by a client to query a system for a 388 specific template in the form of a blueprint prior to the creation of 389 a conference. In this case, the "retrieve" operation often follows 390 an "options" operation, although a conferencing control client may be 391 pre-configured to perform the "retrieve" operation on a specific 392 blueprint. 394 The "retrieve" operation is also used to get the current 395 representation of a specific conference object for a conference 396 reservation or an active conference. In this case, the the unique 397 conference identifier (XCON-URI) MUST be included in the CCMP 398 request. 400 The "retrieve" operation returns the full XML document describing the 401 conference object in its current state including all inherited 402 values. Elements may be marked by attributes, in particular, whether 403 they are specific to this instance or have been inherited from the 404 parent node. 406 To simplify operations, HTTP GET can also be used directly on XCON- 407 URIs, so that simple systems that need to only obtain data about 408 conference objects do not need a full SOAP implementation. 410 7.3. Create 412 The "create" operation is used by a client to create and reserve a 413 conference object. The creation of the conference object can be 414 explicit by requesting it to be created based upon a specific 415 blueprint. When the creation of a conference object is implicit, 416 with no specific blueprint specified, the creation and reservation of 417 the conference instance is based on the default conference object. 418 The default conference object is specific to a conference control 419 server and its specification is outside the scope of this document. 421 When creating conferences, any XCON-URI included by the client is 422 considered as a suggestion. To avoid identifier collisions and to 423 conform to local server policy, the conference control server MAY 424 choose a different identifier. The identifier is returned in the 425 response. 427 In addition, the conference description MAY contain a calendar 428 element, in the iCal format in XML rendition defined in CPL [11] or 429 (preferable, if available as stable reference) xCal [14]. This 430 description indicates when the conference is active. 432 The "create" operation may also be used to create a new conference 433 user, in which case an XCON-USERID is included in the request. The 434 response to this operation includes an XCON-USERID, which may be 435 different than the one sent by the client in the request. 437 To simplify operations, HTTP PUT can also be used to create a new 438 objects as idenfied by the XCON-URI or XCON-URI. 440 7.4. Change 442 The "change" operation updates the conference object as referenced by 443 the XCON-URI included in the request. A request which attempts to 444 change a non-existing object is an error, as is a request which 445 attempts to change a parameter that is inherited from a protected 446 element. 448 During the lifetime of a conference, this operation is used by a 449 conference control client to manipulate a conference object. This 450 includes the ability to pass relevant fragments of the conference 451 object, to manipulate specific elements in the conference object. 452 [Editor's note: the mechanism for manipulation of specific elements 453 in the conference object (i.e., partial updates) requires further 454 consideration and detail.] 456 Upon receipt of a "change" operation, the conference control server 457 updates the specific elements in the referenced conference object. 458 Object properties that are not explicitly changed, remain as-is. 459 This approach allows a conference control client to manipulate 460 objects created by another application even if the manipulating 461 application does not understand all object properties. 463 To simplify operations, HTTP POST can also be used to change the 464 conference objectidentified by the XCON-URI. 466 7.5. Delete 468 This conference control operation is used to delete the current 469 representation of a conference object and requires the unique 470 conference identifier (XCON-URI) be provided by the client. 472 A request which attempts to delete a conference object that is being 473 referenced by a child object is an error. 475 To simplify operations, HTTP DELETE can also be used to delete 476 conference objects identified by the XCON-URI. 478 8. Protocol Operations on Conference Objects 480 The primary function of CCMP is to provide a conference control 481 client with the ability to carry out specific operations on a 482 conference object. As mentioned previously, SOAP is used as the XML 483 RPC mechanism to fulfill such operations. 485 A conference client must first discover the conference control server 486 as described in Section 8.1. The conference control server is the 487 target for the CCMP requests. 489 The conference control operations as described in Section 7 are 490 enveloped in SOAP requests and responses in the form of CCMP Requests 491 (Section 8.2 and CCMP Responses (Section 8.3 respectively. 493 8.1. Locating a Conference Control Server 495 If a conference control client is not pre-configured to use a 496 specific conference control server for the requests, the client MUST 497 first discover the conference control server before it can send any 498 requests. 500 There are several options for discovery of the conference control 501 server. 503 [Editor's note: need to add more detail in this section!] 505 8.2. Constructing a CCMP Request 507 The construction of the SOAP envelope associated with a CCMP request 508 message complies fully with the WSDL, as defined in Section 13. 509 Construction of a valid CCMP request is based upon the operations 510 defined in Section 7, depending upon the function and associated 511 information desired by the conference control client. 513 8.3. Handling a CCMP Response 515 As with the CCMP request message, the CCMP response message is 516 enclosed in a SOAP envelope. A response to the CCMP request MUST 517 contain a response code and may contain other elements depending upon 518 the type of request and the value of the response code. A summary of 519 the response codes is provided in Section 8.3.1 followed by the 520 handling of responses and specific response codes for each of the 521 operations in Section 8.3.2. 523 8.3.1. Response codes 525 All response codes are application-level, and MUST only be provided 526 in successfully processed transport-level responses. For example 527 where HTTP is used, CCMP Response messages MUST be accompanied by a 528 200 OK HTTP response. 530 The set of CCMP Response codes currently contain the following 531 tokens: 533 success: This code indicates that the request was successfully 534 processed. 535 pending: This code indicates that the notification is to follow. 536 modified: This code indicates that the object was created, but may 537 differ from the request. 538 badRequest: This code indicates that the request was badly formed in 539 some fashion. 540 unauthorized: This code indicates that the user was not authorized 541 for the specific operation on the conference object. 542 forbidden: This code indicates that the specific operation is not 543 valid for the target conference object. 544 objectNotFound: This code indicates that the specific conference 545 object was not found. 546 operationNotAllowed: This code indicates that the specific operation 547 is not allowed for the target conference object (e.g.., due to 548 policies, etc.) 549 deleteFailedParent: This code indicates that the conferencing system 550 cannot delete the specific conference object because it is a 551 parent for another conference object. 552 modifyFailedProtected: This code indicates that the target 553 conference object cannot be changed (e.g., due to policies, roles, 554 privileges, etc.). 556 requestTimeout: This code indicates that the request could not be 557 processed within a reasonable time, with the time specific to a 558 conferencing system implementation. 559 serverInternalError: This code indicates that the conferencing 560 system experienced some sort of internal error. 561 notImplemented: This code indicates that the specific operation is 562 not implemented on that conferencing system. 564 8.3.2. Operation Responses 566 The following sections detail the operation specific handling of the 567 response codes. 569 8.3.2.1. Options Response 571 A CCMP Response for an "options" operation, containing a response 572 code of "success", MUST include the XML namespaces that the server 573 understands and the namespaces to be used in subsequent responses 574 that it requires the client to understand. Future work may add more 575 global capabilities rather than conferencing system specific. Within 576 the conferencing system, the namespaces correlate with blueprints, as 577 specified in the XCON framework. The blueprints are comprised of 578 conference information initialized to specific values and ranges. 580 Upon receipt of a successful CCMP response, a conference control 581 client may then perform a "retrieve" operation per Section 7.2 to get 582 a specific conference blueprint. 584 In the case of a response code of "requestTimeout", a conference 585 control client MAY re-attempt the request within a period of time 586 that would be specific to a conference control client or conference 587 control server. 589 The response codes of "modified", "deleteParentFailed" and 590 "modifyFailedProtected" are not applicable to the "options" operation 591 and should be treated as "serverInternalError", the handling of which 592 is specific to the conference control client. 594 A CCMP response containing any other response code is an error and 595 the handling is specific to the conference control client. 596 Typically, an error for an "options" operation indicates a 597 configuration problem in the conference control server or in the 598 client. 600 8.3.2.2. Retrieve Response 602 The CCMP response for a "retrieve" operation containing a response 603 code of "success" MUST contain the full XML document describing the 604 conference object in its current state including all inherited 605 values. Elements may be marked by attributes, in particular, whether 606 they are specific to this instance or have been inherited from the 607 parent node. 609 If a response code of "objectNotFound" is received in the CCMP 610 response, it is RECOMMENDED that a conference control client attempt 611 to retrieve another conference blueprint, if more than one had been 612 received in response to the "options" operation. 614 If a response code of "requestTimeout" is received in the CCMP 615 response, a conference control client MAY re-attempt the request 616 within a period of time that would be specific to a conference 617 control client or conference control server. 619 Response codes such as "notImplemented" and "forbidden" indicate that 620 a subsequent "retrieve" would not likely be sucessful. Handling of 621 these and other response codes is specific to the conference control 622 client. For example, in the case of some clients an "options" 623 operation might be performed again or another conference control 624 server may be accessed. 626 The response codes of "modified", "deleteParentFailed" and 627 "modifyFailedProtected" are not applicable to the "retrieve" 628 operation and SHOULD be treated as "serverInternalError", the 629 handling of which is specific to the conference control client. 631 8.3.2.3. Create Response 633 If the CCMP response to the "create" operation contains a response 634 code of "success", the response MUST also contain either the XCON-URI 635 for the conference object or the XCON-USERID if the request was to 636 create a conference user. 638 If the CCMP response to the "create" operation contains a response 639 code of "modified", the response MUST also contain the XCON-URI for 640 the conference object and the XML document associated with that 641 conference object. For example, in the case where the conference 642 object contained a calendar element, the conference server may only 643 offer a subset of the dates requested, thus the updated dates are 644 included in the returned XML document. 646 In the case of a response code of "requestTimeout", a conference 647 control client MAY re-attempt the request within a period of time 648 that would be specific to a conference control client or conference 649 control server. 651 Response codes such as "unauthorized", "forbidden" and 652 "operationNotAllowed" indicate the client does not have the 653 appropriate permissions, there is an error in the permissions, or 654 there is a system error in the client or conference control server, 655 thus re-attempting the request would likely not succeed. 657 The response codes of "deleteParentFailed" and 658 "modifyFailedProtected" are not applicable to the "create" operation 659 and SHOULD be treated as "serverInternalError", the handling of which 660 is specific to the conference control client. 662 Any other response code indicates an error in the client or 663 conference control server (e.g., "forbidden", "badRequest") and the 664 handling is specific to the conference control client. 666 8.3.2.4. Change Response 668 If the CCMP response to the "change" operation contains a response 669 code of "success", the response also contains the XCON-URI for the 670 conference object that was changed. 672 If the CCMP response to the "change" operation contains a response 673 code of "modified", the response MUST contain the XCON-URI for the 674 conference object and the XML document associated with that 675 conference object. For example, a conferencing system may not have 676 the resources to support specific capabilities that were changed, 677 such as in the , thus the 678 supported are included in the returned XML document. 680 If the CCMP response code of "requestTimeout" is received, a 681 conference control client MAY re-attempt the request within a period 682 of time that would be specific to a conference control client or 683 conference control server. 685 Response codes such as "unauthorized", "forbidden", 686 "operationNotAllowed" and "modifyFailedProtected" indicate the client 687 does not have the appropriate permissions, the conference is locked, 688 there is an error in the permissions, or there is a system error in 689 the client or conference control server, thus re-attempting the 690 request would likely not succeed. 692 The response code of "deleteParentFailed" is not applicable to the 693 "modify" operation and SHOULD be treated as "serverInternalError", 694 the handling of which is specific to the conference control client. 696 Any other response code indicates an error in the client or 697 conference control server (e.g., "forbidden", "badRequest") and the 698 handling is specific to the conference control client. 700 8.3.2.5. Delete Response 702 If the CCMP response to the "delete" operation contains a response 703 code of "success", the response MUST contain the XCON-URI for the 704 conference object that was deleted. 706 The response code of "deleteParentFailed" indicates that the 707 conference object could not be deleted because it is the Parent of 708 another conference object that is in use. In this case, the response 709 also includes the XCON-URI for the conference object. 711 If a response code of "requestTimeout" is received, a conference 712 control client MAY re-attempt the request within a period of time 713 that would be specific to a conference control client or conference 714 control server. 716 Response codes such as "unauthorized", "forbidden" and 717 "operationNotAllowed" indicate the client does not have the 718 appropriate permissions, the conference is locked, there is an error 719 in the permissions, or there is a system error in the client or 720 conference control server, thus re-attempting the request would 721 likely not succeed. 723 The response code of "modifyFailedProtected" is not applicable to the 724 "delete" operation and SHOULD be treated as "serverInternalError", 725 the handling of which is specific to the conference control client. 727 Any other response code indicates an error in the client or 728 conference control server (e.g., "forbidden", "badRequest") and the 729 handling is specific to the conference control client. 731 9. Protocol Parameters 733 This section describes in detail the parameters that are used for the 734 CCMP protocol. 736 9.1. Operation Parameter 738 The "operation" attribute is a mandatory token included in all CCMP 739 request and response messages. This document defines five possible 740 values for this parameter: "options", "retrieve", "create", "modify" 741 and "delete". The details for the specific processing based on the 742 operation is provided in Section 9.1. 744 9.2. Request ID Parameter 746 The "requestID" attribute is a mandatory token included in all CCMP 747 request and response messages. The "requestID" is used to correlate 748 the requests with the appropriate response. 750 9.3. ConfObjID Parameter 752 The "confObjID" attribute is an optional URI included in the CCMP 753 request and response messages. This attribute is required in the 754 case of an "operation" of "change" and "delete" in the CCMP request 755 and response messages. This attribute is the XCON-URI which is the 756 target for the specific operation. 758 The only case when this attribute would not be included in the CCMP 759 request for an operation of "create" is when there is no "confObjID" 760 attribute in the CCMP request and the CCMP request contained a 761 confUserID. This latter case is the mechanism whereby a conference 762 control client can request the creation of a new conference user, as 763 detailed in Section 9.4. 765 In the cases where the "conference-info" parameter Section 9.7 is 766 also included in the requests and responses, the "confObjID" MUST 767 match the XCON-URI in the "entity" attribute. 769 9.4. ConfUserID Parameter 771 The "confUserID" attribute is an optional URI included in the CCMP 772 request and response messages. This is an XCON-USERID for the 773 conference control client initiating the request. 775 This attribute is required in the case of an "operation" of "create", 776 "change" and "delete" in the CCMP request message. In these cases, 777 it is used to determine if the conference control client has the 778 authority to perform the operation. Note that the details for 779 authorization and related policy are specified in a separate document 780 [TBD]. For any CCMP request with a "create" operation the conference 781 control server MUST create a new conference user and return the 782 associated confUserID in the response. In the case where the 783 confUserID in the request has already been allocated, this request 784 may be the creation of a confUserID for the conference control client 785 to take on an additional role. 787 This attribute is required in the CCMP response message in the case 788 of an "operation" of "create", which also contained a "confUserID" 789 attribute in the CCMP request with no "confObjID". 791 9.5. ResponseCode Parameter 793 The "responseCode" attribute is a mandatory parameter in all CCMP 794 response messages. The values for each of the "responseCode" values 795 are detailed in Section 8.3.1 with the associated processing 796 described in Section 8.3.2. 798 9.6. Blueprints Parameter 800 The "blueprints" attribute is a optional parameter in the CCMP 801 request and response messages. In the case of a CCMP request with an 802 operation of "options", the CCMP response includes the "blueprints" 803 supported by the conference control server. The "blueprints" 804 attribute is comprised of a list of blueprints supported by the 805 specific conference server and includes a conference system specific 806 "blueprintName" and a "confObjID" in the form of an XCON-URI for each 807 of the blueprints. 809 The "blueprints" attribute is required for a CCMP request with an 810 operation of "retrieve". 812 9.7. Conference-info Parameter 814 The "conference-info" element contains the data for the conference 815 object that is the target for the CCMP request operations for 816 "create", "change" and "delete" operations. It is returned in a CCMP 817 response if the CCMP response contains a responseCode of "modified" 818 or if the original CCMP request for the "create" operation did not 819 contain a "conference-info" element. The latter case would occur if 820 a conference control clients intends to create a conference object 821 based on a default provided by a conferening system. 823 The details on the information that may be included in the 824 "conference-info" element MUST follow the rules as specified in the 825 XCON Data Model document [8]. The conference control client and 826 conference control server MUST follow those rules in generating the 827 "conference-info" in any of the CCMP request and response messages. 829 Note that the "conference-info" element is not explicitly shown in 830 the XML schema Section 12 due to XML schema constraints. 832 10. Examples 834 The examples below omits the standard SOAP header and wrappers, i.e., 835 the examples below contain simply the of the requests and 836 responses. 838 10.1. Creating a New Conference 840 The first example creates a new conference. 842 843 99 844 create 846 849 850 http://example.com/conf200 851 Agenda: This month's goals 852 853 854 sips:conf223@example.com 855 participation 856 857 858 859 860 http://sharep/salesgroup/ 861 web-page 862 863 864 http://example.com/conf233 865 control 866 867 868 869 871 873 Figure 2: Create Request Example 875 The response to this request is shown below; it returns the object 876 identifier as a URL and the final conference description, which may 877 modify the description offered by the user. 879 880 99 881 create 882 modified 883 xcon:confxyz987@example.com 884 userA-confxyz987 886 889 xcon:confxyz987@example.com 890 891 http://example.com/conf200 892 Agenda: This month's goals 893 894 895 sips:conf223@example.com 896 participation 897 898 899 900 901 http://sharep/salesgroup/ 902 web-page 903 904 905 http://example.com/conf233 906 control 907 908 910 911 912 913 914 916 919 920 922 924 Figure 3: Create Response Example 926 10.2. Creating a New Conference User 928 The request below creates a new conference user, independent of a 929 specific conference object. 931 932 101 933 create 935 939 940 941 observer 942 943 944 945 947 949 Figure 4: Create User Example 951 The response to this request is shown below; it returns the 952 conference user identifier. 954 955 101 956 create 957 success 958 userC-confxyz987 959 961 Figure 5: Create Response Example 963 10.3. Adding a User to a Conference 965 The request below adds a user to the conference identified by the 966 XCON-URI. 968 969 100 970 change 971 xcon:confxyz987@example.com 973 976 xcon:confxyz987@example.com 977 979 980 participant 981 982 983 984 986 988 Figure 6: Add User Example 990 The response to this request is shown below; it returns the 991 conference user identifier. 993 994 100 995 create 996 success 997 xcon:confxyz987@example.com 998 userA-confxyz987 1000 1003 1006 xcon:confxyz987@example.com 1007 1008 1009 participant 1010 1011 1012 1013 1015 1017 Figure 7: Add User Response Example 1019 11. Transaction Model 1021 The transaction model for CCMP complies fully with SOAP version 1.2 1022 as defined by W3C in [5] and [6]. 1024 12. XML Schema 1026 This section provides the XML schema definition of the "application/ 1027 ccmp+xml" format. 1029 1030 1036 1037 1042 1045 1048 1050 1053 1055 1056 1060 1062 1065 1067 1069 1070 1072 1074 1077 1079 1082 1084 1086 1088 1091 1092 1096 1097 1100 1102 1104 1106 1107 1108 1109 1110 1111 1112 1113 1114 1116 1117 1118 1120 1122 1123 1124 1125 1127 1128 1129 1131 1132 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1153 1154 1155 1157 1158 1160 1161 1163 1165 Figure 8 1167 13. WSDL Definition 1169 The following provides the WSDL definition for conference control and 1170 manipulation, using the the XML schema defined in Section 12 as a 1171 basis. 1173 1174 1185 1189 1190 1191 1192 1193 1194 1196 1197 1198 1199 1200 1201 1203 1204 1206 1207 1208 1209 1212 1213 1214 1217 1218 1219 1220 1221 1222 1223 1224 1226 1228 Figure 9 1230 14. IANA Considerations 1232 This document registers a new XML namespace, a new XML schema, and 1233 the MIME type for the schema. This document also defines registries 1234 for the CCMP operation types and response codes. 1236 14.1. URN Sub-Namespace Registration 1238 This section registers a new XML namespace, 1239 ""urn:ietf:params:xml:ns:xcon:ccmp"". 1241 URI: "urn:ietf:params:xml:ns:xcon:ccmp" 1242 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), 1243 Mary Barnes (mary.barnes@nortel.com). 1244 XML: 1246 BEGIN 1247 1248 1250 1251 1252 CCMP Messages 1253 1254 1255

Namespace for CCMP Messages

1256

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

1257 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1258 with the RFC number for this specification.]] 1259

See RFCXXXX.

1260 1261 1262 END 1264 14.2. XML Schema Registration 1266 This section registers an XML schema as per the guidelines in [3]. 1268 URI: urn:ietf:params:xml:schema:xcon:ccmp 1269 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 1270 Barnes (mary.barnes@nortel.com). 1271 Schema: The XML for this schema can be found as the entirety of 1272 Section 12 of this document. 1274 14.3. MIME Media Type Registration for 'application/ccmp+xml' 1276 This section registers the "application/ccmp+xml" MIME type. 1278 To: ietf-types@iana.org 1279 Subject: Registration of MIME media type application/ccmp+xml 1280 MIME media type name: application 1281 MIME subtype name: ccmp+xml 1282 Required parameters: (none) 1283 Optional parameters: charset 1284 Indicates the character encoding of enclosed XML. Default is 1285 UTF-8. 1286 Encoding considerations: Uses XML, which can employ 8-bit 1287 characters, depending on the character encoding used. See RFC 1288 3023 [9], section 3.2. 1289 Security considerations: This content type is designed to carry 1290 protocol data related conference control. Some of the data could 1291 be considered private and thus should be protected. 1292 Interoperability considerations: This content type provides a basis 1293 for a protocol 1294 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 1295 replace XXXX with the RFC number for this specification.]] 1296 Applications which use this media type: Centralized Conferencing 1297 control clients and servers. 1298 Additional Information: Magic Number(s): (none) 1299 File extension(s): .xml 1300 Macintosh File Type Code(s): (none) 1301 Person & email address to contact for further information: Mary 1302 Barnes 1303 Intended usage: LIMITED USE 1304 Author/Change controller: The IETF 1305 Other information: This media type is a specialization of 1306 application/xml [9], and many of the considerations described 1307 there also apply to application/ccmp+xml. 1309 14.4. CCMP Protocol Registry 1311 This document requests that the IANA create a new registry for the 1312 CCMP protocol including an initial registry for operation types and 1313 response codes. 1315 14.4.1. CCMP Operations 1317 The "operation" are included in CCMP messages as described in 1318 Section 9.1 and defined in the 'operationType' in the XML schema in 1319 Section 12. The following summarizes the requested registry: 1321 Related Registry: CCMP Operation Registry 1322 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1323 with the RFC number for this specification.] 1324 Registration/Assignment Procedures: New operations are allocated on 1325 a first-come/first-serve basis with specification required. 1326 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 1327 Barnes (mary.barnes@nortel.com). 1329 This section pre-registers the following five initial operations: 1331 options: Used by a conference control client to query a conferncing 1332 system for its capabiliites. 1333 retrieve: Used by a conference control client to retrieve a specific 1334 blueprint. 1335 create: Used by a conference control client to create a new 1336 conference object or new conference user. 1337 modify: Used by a conference control client to modify a conference 1338 object(s). 1339 delete: Used by a client to delete a conference object(s). 1341 14.4.2. CCMP Response Codes 1343 The following summarizes the requested registry for CCMP Response 1344 codes: 1346 Related Registry: CCMP Response Code Registry 1347 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1348 with the RFC number for this specification.] 1349 Registration/Assignment Procedures: New response codes are allocated 1350 on a first-come/first-serve basis with specification required. 1351 Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary 1352 Barnes (mary.barnes@nortel.com). 1354 This section pre-registers the following thirteen initial response 1355 codes as described above in Section 8.3: 1357 success: This code indicates that the request was successfully 1358 processed. 1359 pending: This code indicates that the notification is to follow. 1360 modified: This code indicates that the object was created, but may 1361 differ from the request. 1362 badRequest: This code indicates that the request was badly formed in 1363 some fashion. 1364 unauthorized: This code indicates that the user was not authorized 1365 for the specific operation on the conference object. 1366 forbidden: This code indicates that the specific operation is not 1367 valid for the target conference object. 1368 objectNotFound: This code indicates that the specific conference 1369 object was not found. 1370 operationNotAllowed: This code indicates that the specific operation 1371 is not allowed for the target conference object (e.g.., due to 1372 policies, etc.) 1373 deleteFailedParent: This code indicates that the conferencing system 1374 cannot delete the specific conference object because it is a 1375 parent for another conference object. 1376 modifyFailedProtected: This code indicates that the target 1377 conference object cannot be changed (e.g., due to policies, roles, 1378 privileges, etc.). 1379 requestTimeout: This code indicates that the request could not be 1380 processed within a reasonable time, with the time specific to a 1381 conferencing system implementation. 1382 serverInternalError: This code indicates that the conferencing 1383 system experienced some sort of internal error. 1384 notImplemented: This code indicates that the specific operation is 1385 not implemented on that conferencing system. 1387 15. Security Considerations 1389 Access to conference control functionality needs to be tightly 1390 controlled to keep attackers from disrupting conferences, adding 1391 themselves to conferences or engaging in theft of services. 1392 Implementors need to deploy standard HTTP and SOAP authentication and 1393 authorization mechanisms. Since conference information may contain 1394 secrets such as participant lists and dial-in codes, all conference 1395 control information SHOULD be carried over TLS (HTTPS). 1397 16. Acknowledgments 1399 The authors appreciate the feedback provided by Simon Pietro Romano, 1400 Dave Morgan and Pierre Tane. 1402 17. References 1404 17.1. Normative References 1406 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1407 Levels", BCP 14, RFC 2119, March 1997. 1409 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1410 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1411 HTTP/1.1", RFC 2616, June 1999. 1413 [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1414 January 2004. 1416 [4] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web 1417 Services Description Language (WSDL) Version 2.0 Part 1: Core 1418 Language", W3C CR CR-wsdl20-20051215, December 2005. 1420 [5] Gudgin, M., Hadley, M., Moreau, J., Mendelsohn, N., and H. 1421 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World 1422 Wide Web Consortium FirstEdition REC-soap12-part1-20030624, 1423 June 2003, 1424 . 1426 [6] Mendelsohn, N., Moreau, J., Hadley, M., Nielsen, H., and M. 1427 Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web 1428 Consortium FirstEdition REC-soap12-part2-20030624, June 2003, 1429 . 1431 [7] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1432 Centralized Conferencing", draft-ietf-xcon-framework-10 (work 1433 in progress), November 2007. 1435 [8] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference 1436 Information Data Model for Centralized Conferencing (XCON)", 1437 draft-ietf-xcon-common-data-model-09 (work in progress), 1438 February 2008. 1440 17.2. Informative References 1442 [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1443 RFC 3023, January 2001. 1445 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1446 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1447 Session Initiation Protocol", RFC 3261, June 2002. 1449 [11] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1450 Language (CPL): A Language for User Control of Internet 1451 Telephony Services", RFC 3880, October 2004. 1453 [12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1454 December 2004. 1456 [13] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, 1457 "Conference Event Package Data Format Extension for Centralized 1458 Conferencing (XCON)", draft-ietf-xcon-event-package-00 (work 1459 in progress), February 2008. 1461 [14] Royer, D., "iCalendar in XML Format (xCal-Basic)", 1462 draft-royer-calsch-xcal-03 (work in progress), October 2005. 1464 Authors' Addresses 1466 Mary Barnes 1467 Nortel 1468 2201 Lakeside Blvd 1469 Richardson, TX 1471 Email: mary.barnes@nortel.com 1473 Chris Boulton 1474 Avaya 1475 Building 3 1476 Wern Fawr Lane 1477 St Mellons 1478 Cardiff, South Wales CF3 5EA 1480 Email: cboulton@avaya.com 1482 Henning Schulzrinne 1483 Columbia University 1484 Department of Computer Science 1485 450 Computer Science Building 1486 New York, NY 10027 1488 Email: hgs+xcon@cs.columbia.edu 1490 Full Copyright Statement 1492 Copyright (C) The IETF Trust (2008). 1494 This document is subject to the rights, licenses and restrictions 1495 contained in BCP 78, and except as set forth therein, the authors 1496 retain all their rights. 1498 This document and the information contained herein are provided on an 1499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1506 Intellectual Property 1508 The IETF takes no position regarding the validity or scope of any 1509 Intellectual Property Rights or other rights that might be claimed to 1510 pertain to the implementation or use of the technology described in 1511 this document or the extent to which any license under such rights 1512 might or might not be available; nor does it represent that it has 1513 made any independent effort to identify any such rights. Information 1514 on the procedures with respect to rights in RFC documents can be 1515 found in BCP 78 and BCP 79. 1517 Copies of IPR disclosures made to the IETF Secretariat and any 1518 assurances of licenses to be made available, or the result of an 1519 attempt made to obtain a general license or permission for the use of 1520 such proprietary rights by implementers or users of this 1521 specification can be obtained from the IETF on-line IPR repository at 1522 http://www.ietf.org/ipr. 1524 The IETF invites any interested party to bring to its attention any 1525 copyrights, patents or patent applications, or other proprietary 1526 rights that may cover technology that may be required to implement 1527 this standard. Please address the information to the IETF at 1528 ietf-ipr@ietf.org. 1530 Acknowledgment 1532 Funding for the RFC Editor function is provided by the IETF 1533 Administrative Support Activity (IASA).