XCON Working Group M. Barnes Internet-Draft Nortel Intended status: Standards Track C. Boulton Expires: December 18, 2008 Avaya S P. Romano University of Napoli H. Schulzrinne Columbia University June 16, 2008 Centralized Conferencing Manipulation Protocol draft-ietf-xcon-ccmp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 18, 2008. Abstract The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the Barnes, et al. Expires December 18, 2008 [Page 1] Internet-Draft CCMP June 2008 interactions specified via Web Services Description Language (WSDL). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 6 6. Conference Object and User Identifiers . . . . . . . . . . . . 8 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 8 6.2. Conference Users and Participants . . . . . . . . . . . . 8 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 7.1. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Protocol Operations on Conference Objects . . . . . . . . . . 12 8.1. Locating a Conference Control Server . . . . . . . . . . . 13 8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 13 8.2.1. Options Request . . . . . . . . . . . . . . . . . . . 13 8.2.2. Operations Requests . . . . . . . . . . . . . . . . . 14 8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 15 8.3.1. Options Response . . . . . . . . . . . . . . . . . . . 16 8.3.2. Operation Responses . . . . . . . . . . . . . . . . . 16 9. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 9.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 20 9.2. Request ID Parameter . . . . . . . . . . . . . . . . . . . 20 9.3. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 20 9.4. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 20 9.5. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 21 9.6. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 21 9.7. Conference-info Parameter . . . . . . . . . . . . . . . . 21 9.8. User Parameter . . . . . . . . . . . . . . . . . . . . . . 22 9.9. Users Parameter . . . . . . . . . . . . . . . . . . . . . 22 9.10. Sidebar Parameters . . . . . . . . . . . . . . . . . . . . 23 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Creating a New Conference . . . . . . . . . . . . . . . . 23 10.2. Creating a New Conference User . . . . . . . . . . . . . . 26 10.3. Adding a User to a Conference . . . . . . . . . . . . . . 26 11. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 28 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 33 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 34 14.2. XML Schema Registration . . . . . . . . . . . . . . . . . 35 14.3. MIME Media Type Registration for 'application/ccmp+xml' . 35 Barnes, et al. Expires December 18, 2008 [Page 2] Internet-Draft CCMP June 2008 14.4. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 36 14.4.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 36 14.4.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 37 15. Security Considerations . . . . . . . . . . . . . . . . . . . 38 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 17.1. Normative References . . . . . . . . . . . . . . . . . . . 38 17.2. Informative References . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 42 Barnes, et al. Expires December 18, 2008 [Page 3] Internet-Draft CCMP June 2008 1. Introduction The Framework for Centralized Conferencing (XCON) [I-D.ietf-xcon-framework]defines a signaling-agnostic framework, naming conventions and logical entities required for constructing advanced conferencing systems. A primary concept introduced in the XCON framework is the existence of a conference object. The framework introduces the conference object as a logical representation of a conference instance which represents the current state and capabilities of a conference. The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document allows the creation, manipulation and deletion of a conference object by authenticated and authorized clients. This includes adding and removing participants, changing their roles, as well as adding and removing media streams and associated end points. CCMP implements a client-server model. The server is the Conference Control Server defined in the XCON framework. The client is the Conference and Media Control Client in the XCON framework. This document describes the protocol used by the client for conference control. CCMP manipulates conferences based on their semantic properties and is based on a client-server Remote Procedure Call (RPC) mechanism, with the Simple Object Access Protocol (SOAP) [W3C.REC-soap12-part1-20030624] and [W3C.REC-soap12-part2-20030624] used to carry out the appropriate client-server protocol transactions. The common information contained in conference objects is defined using an XML representation based on the schema in the XCON data model [I-D.ietf-xcon-common-data-model]. These data structures are used as the basis for the Web Services Description Language (WSDL) [W3C.CR-wsdl20-20051215] definition and XML schema. This document first provides some background on the motivations associated with the design of CCMP in Section 4 followed by a brief discussion of the system architecture in Section 5. A discussion of the primary keys in the conference object carried in the protocol is detailed in Section 6. An overview of the operations associated with each protocol request and response is provided in Section 7, with the practical sequence of protocol requests and responses discussed in Section 8 and examples provided in Section 10. The protocol parameters are detailed in Section 9. The transaction model is described in Section 11. The XML schema is Barnes, et al. Expires December 18, 2008 [Page 4] Internet-Draft CCMP June 2008 provided in Section 12 and the corresponding WSDL information is detailed in Section 13. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Terminology This document reuses the terminology defined in the Framework for Centralized Conferencing [I-D.ietf-xcon-framework]. In addition, the following acronyms and terms are used in this document: SOAP: Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W 3C.REC-soap12-part2-20030624]. WSDL: Web Services Description Language[W3C.CR-wsdl20-20051215]. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document- oriented or procedure-oriented information. W3C: World Wide Web Consortium. The organization that developed the SOAP and WSDL specifications referenced within this document. 4. Motivation SOAP is chosen as the RPC mechanism due to its compatibility with the requirements for the conference control protocol as introduced in the framework for centralized conferencing. SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP allows the re-use of libraries, servers and other infrastructure and provides a convenient mechanism for the formal definition of protocol syntax using Web Services Description Language (WSDL). WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol Barnes, et al. Expires December 18, 2008 [Page 5] Internet-Draft CCMP June 2008 and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings included in this document describe how to use WSDL in conjunction with SOAP. It is likely that implementations and future standardization work will add more conference attributes and parameters. There are three types of extensions. The first and simplest type of extension adds elements to the overall conference description, media descriptions or descriptions of users. The XML namespace mechanism makes such extensions relatively easy, although implementations still have to deal with implementations that may not understand the new namespaces. The Options operation (Section 8.2.1) allows clients to determine the capabilities of a specific server, reflected by the specific blueprints supported by that server. A second type of extension replaces the conference, user or media objects with completely new schema definitions, i.e., the namespaces for these objects themselves differ from the basic one defined in this document. As long as the Options request remains available and keeps to a mutually-understood definition, a compatible client and server will be able to bootstrap themselves into using these new objects. Finally, it is conceivable that new object types are needed beyond the core conference, user and media objects and their children. These would also be introduced by namespaces. 5. System Architecture CCMP supports the framework for centralized conferencing. Figure 1 depicts a subset of the 'Conferencing System Logical Decomposition' architecture from the framework for centralized conferencing document. It illustrates the role that CCMP assumes within the overall centralized architecture. Barnes, et al. Expires December 18, 2008 [Page 6] Internet-Draft CCMP June 2008 ........................................................ . Conferencing System . . . . +---------------------------------------+ . . | C O N F E R E N C E O B J E C T | . . +-+-------------------------------------+ | . . | C O N F E R E N C E O B J E C T | | . . +-+-------------------------------------+ | | . . | C O N F E R E N C E O B J E C T | | | . . | | | | . . | | |-+ . . | |-+ . . +---------------------------------------+ . . ^ . . | . . v . . +-------------------+ . . | Conference Control| . . | Server | . . +-------------------+ . . ^ . .........................|.............................. | |Conference |Control |Protocol | | .........................|.............................. . V . . +----------------+ . . | Conference | . . | Control | . . | Client | . . +----------------+ . . . . Conferencing Client . ........................................................ Figure 1: Conference Client Interaction CCMP serves as the Conference Control Protocol, allowing the conference control client to interface with the conference object maintained by the conferencing system, as represented in Figure 1. Conference Control is one part of functionality for advanced conferencing supported by a conferencing client. Other functions are discussed in the framework for centralized conferencing document and Barnes, et al. Expires December 18, 2008 [Page 7] Internet-Draft CCMP June 2008 related documents. 6. Conference Object and User Identifiers This section provides an overview of the conference object and conference users which are key protocol elements for creating the CCMP requests and responses. The identifiers used in CCMP for the conference object (XCON-URI) and conference user (XCON-USERID) are introduced in the XCON framework and defined in the XCON data model [I-D.ietf-xcon-common-data-model]. 6.1. Conference Object Conference objects feature a simple dynamic inheritance-and-override mechanism. Conference objects are linked into a tree, where each tree node inherits attributes from its parent node. The roots of these inheritance trees are also known as "blueprints". Nodes in the inheritance tree can be active conferences or simply descriptions that do not currently have any resources associated with them. An object can mark certain of its properties as unalterable, so that they cannot be overridden. The schema for the conference object is defined in the XCON data model. Conference objects are uniquely identified by the XCON-URI. A client MAY specify a parent element that indicates the parent from which the conference is to inherit values. When creating conferences, the XCON-URI included by the client is only a suggestion. To avoid identifier collisions and to conform to local server policy, the conference control server MAY choose a different identifier. 6.2. Conference Users and Participants Each conference can have zero or more users. All conference participants are users, but some users may have only administrative functions and do not contribute or receive media. Users are added one user at a time to simplify error reporting. Users are inherited as well, so that it is easy to set up a conference that has the same set of participants or a common administrator. The Conference Control Server creates individual users, assigning them a unique Conference User Identifier (XCON-USERID). A variety of elements defined in the common element as specified in the XCON data model are used to determine how a specific user expects and is allowed to join a conference as a participant, or users with specific privileges (e.g., observer). For example, the attribute defines how the caller joins the Barnes, et al. Expires December 18, 2008 [Page 8] Internet-Draft CCMP June 2008 conference, with a set of defined XML elements, namely for users that are allowed to dial in and for users that the conference focus will be trying to reach. is the default. If the conference is currently active, dial-out users are contacted immediately; otherwise, they are contacted at the start of the conference. The conference control server assigns a unique Conference User Identifier (XCON-USERID) to each user. The conference control server uses the XCON-USERID to change or delete elements. Depending upon policies and privileges, specific users MAY also manipulate elements. In many conferences, users can dial in if they know the XCON-URI and an access code shared by all conference participants. In this case, the system is typically not be aware of the call signaling URL. Thus, the initial element does not have an entity attribute and the default type of is used to support this type of user. For this case, the server assigns a locally-unique URI, such as a locally-scoped tel URI. The conference control server assigns a unique Conference User Identifier (XCON-USERID) to these users when they dial-in to join the conference. If the user supports the notification event package [I-D.ietf-xcon-event-package], they can receive their XCON-USERID, thus allowing them to also manipulate the attribute, including the entity attribute, in the conference object. 7. Protocol Operations The primary function of the protocol defined within this document is to provide a conference control client with the ability to carry out operations on a conference object as a whole and on specific elements within a conference object. This section describes the four basic operations on a conference object: retrieve, create, change and delete. The XCON-URI as discussed in Section 6.1 is the target for each of these operations. The normative protocol details as to the applicability of each of the operations for the various CCMP requests and responses are provided in Section 8 7.1. Retrieve The "retrieve" operation is used by a client to query a system for a specific template in the form of a blueprint prior to the creation of a conference. In this case, the "retrieve" operation often follows an "options" operation, although a conferencing control client may be pre-configured to perform the "retrieve" operation on a specific blueprint. Barnes, et al. Expires December 18, 2008 [Page 9] Internet-Draft CCMP June 2008 The "retrieve" operation is also used to get the current representation of a specific conference object (or specific parameters in the conference object) for a conference reservation or an active conference. The unique conference identifier (XCON-URI) is included in the CCMP request. The "retrieve" operation returns the XML document describing the conference object in its current state including all inherited values or the specific parameters per the specific request type. Elements may be marked by attributes, in particular, whether they are specific to this instance or have been inherited from the parent node. To simplify operations, HTTP GET can also be used directly on XCON- URIs, so that simple systems that need to only obtain data about conference objects do not need a full SOAP implementation. 7.2. Create The "create" operation is used by a client to create and reserve a conference object or a new conference user. The creation of a conference object can be explicit by requesting it to be created based upon a specific blueprint, based on an existing conference object (e.g., cloning a conference reservation or active conference object) or based on the data included in the request. In the first two cases, a specific XCON-URI MUST be included in the request. When the creation of a conference object is implicit, with no conference object for a blueprint or existing conference specified and no data included in the request, the creation and reservation of the conference instance is based on the default conference object. The default conference object is specific to a conference control server and its specification is outside the scope of this document. A client may first send a requeest with "retrieve" operation in order to obtain all the data as defined in [I-D.ietf-xcon-common-data-model] for the specific blueprint or existing conference object. This would allow the client to modify the data prior to sending the request with the "create" operation. In this case, the request would also include all the data. If the client wants to create the new conference by cloning the blueprint or existing conference object, there would be no data included in the request. The client may later modify this data by sending a request with a "change" operation. When creating conferences, any XCON-URI included by the client is considered as the target conference object from which the new conference is to be created. To avoid identifier collisions and to conform to local server policy, the conference control server Barnes, et al. Expires December 18, 2008 [Page 10] Internet-Draft CCMP June 2008 typically chooses a different identifier for the newly created conference object. The identifier is returned in the response. In addition, the conference description MAY contain a calendar element, in the iCal format in XML rendition defined in CPL [RFC3880] or (preferable, if available as stable reference) xCal [I-D.royer-calsch-xcal]. This description indicates when the conference is active. The "create" operation may also be used to create a new conference user with the "userRequest" message. In this case, the "userResponse" to this operation includes an XCON-USERID. To simplify operations, HTTP PUT can also be used to create a new object as idenfied by the XCON-URI or XCON-USERID. 7.3. Change The "change" operation updates the conference object as referenced by the XCON-URI included in the request. A request which attempts to change a non-existing object is an error, as is a request which attempts to change a parameter that is inherited from a protected element. During the lifetime of a conference, this operation is used by a conference control client to manipulate a conference object. This includes the ability to manipulate specific elements in the conference object through element specific requests such as "userRequest" or "sideBarRequest", etc. Upon receipt of a "change" operation, the conference control server updates the specific elements in the referenced conference object. Object properties that are not explicitly changed, remain as-is. This approach allows a conference control client to manipulate objects created by another application even if the manipulating application does not understand all object properties. To simplify operations, HTTP POST can also be used to change the conference object identified by the XCON-URI. 7.4. Delete This conference control operation is used to delete the current representation of a conference object or a specific parameter in the conference object and requires the unique conference identifier (XCON-URI) be provided by the client. A request which attempts to delete a conference object that is being Barnes, et al. Expires December 18, 2008 [Page 11] Internet-Draft CCMP June 2008 referenced by a child object is an error. To simplify operations, HTTP DELETE can also be used to delete conference objects and parameters within conference objects identified by the XCON-URI. 8. Protocol Operations on Conference Objects The primary function of CCMP is to provide a conference control client with the ability to carry out specific operations (Section 7) on a conference object through the protocol requests and responses. The CCMP requests (Section 8.2)and responses (Section 8.3) are enveloped in SOAP requests and responses. The basic request/response pairs defined in this document are: optionsRequest/optionsResponse: The optionsRequest is used to ascertain the namespaces, conference reservations and active conferences supported by the server. The optionsResponse returns a list of the requested types of conference objects (e.g., Blueprints, Conference Reservations and/or Active Confrences) supported by the specific conference server. confRequest/confResponse: The confRequest is used to request an operation on the conference object as a whole. userRequest/userResponse: The userRequest is used to request an operation on the "user" element in the conference object. [Editor's Note: we may want to add more discrete user requests/ responses as this is a very broad parameter] usersRequest/usersResponse: This usersRequest is used to manipulate the "users" element in the conference object, including parameters such as the allowed-users-list, join-handling, etc. sidebarRequest/sidebarResponse: This sidebarRequest is used to retrieve the information related to a sidebar or to create, change or delete a specific sidebar. [Editor's Note: the data model defines a byVal and byRef sidebar type. Rather than define two root operations, the preference is to have these two types reflected by a parameter in the request.] [Editor's Note: more core requests/responses will be added to this document once the WG agrees the basic protocol structure.] To simplify operations, a conference control server treats certain parameters as suggestions (e.g., for the "create" and "change" operations), as noted in the object description. If the conference control server cannot set the parameter to the values desired, it picks the next best value, according to local policy and returns the values selected in the response. If the client is not satisfied with these values, it simply deletes the object. Barnes, et al. Expires December 18, 2008 [Page 12] Internet-Draft CCMP June 2008 Along with the protocol requests and responses for manipulating the conference object, there is also a querying mechanism ("optionsRequest"/"optionsResponse") to ascertain the namespaces understood by the server. Any elements with namespaces not understood by the server are to be ignored by the server. This allows a client to include optional elements in requests without having to tailor its request to the capabilities of each server. A conference control client and conference control server MUST fully implement the SOAP WSDL schema defined in Section 13 which uses HTTP operations as the transport mechanism in this specification. Extensions MAY choose to use alternate transport mechanisms in association with the SOAP WSDL. A conference client must first discover the conference control server as described in Section 8.1. The conference control server is the recipient of the CCMP requests. 8.1. Locating a Conference Control Server If a conference control client is not pre-configured to use a specific conference control server for the requests, the client MUST first discover the conference control server before it can send any requests. There are several options for discovery of the conference control server. [Editor's note: need to add more detail in this section!] 8.2. Constructing a CCMP Request The construction of the SOAP envelope associated with a CCMP request message complies fully with the WSDL, as defined in Section 13. Construction of a valid CCMP request is based upon the operations defined in Section 7, depending upon the function and associated information desired by the conference control client. The following sections provide details of the "optionsRequest" message and summarize the CCMP requests related to the specific operations in Section 7. 8.2.1. Options Request The "optionsRequest" is used by a client to query a system for its capabilities in terms of types of conferences supported and isn't targeted toward a particular conference object. The "optionsRequest is also used by a client with appropriate authority to query a system for a list of the conference reservations and active conferences that Barnes, et al. Expires December 18, 2008 [Page 13] Internet-Draft CCMP June 2008 have been created on the specific conferencing system. The "optionsResponse" returns the XML namespaces that the server understands and the namespaces to be used in responses that it requires the client to understand. Within the conferencing system, the namespaces correlate with blueprints, as specified in the XCON framework. The blueprints are comprised of conference information initialized to specific values and ranges. Each blueprint has a corresponding XCON-URI. 8.2.2. Operations Requests Construction of other valid CCMP requests is based upon the operations defined in Section 7, depending upon the function and associated information desired by the conference control client. The following table summarizes specific request type and processing for each of the "operations". A value of "N/A" indicates the specific operation is not valid for the specific CCMP request. +---------------+------------+------------+------------+------------+ | Operation | Retrieve | Create | Change | Delete | | ------------ | | | | | | Request Type | | | | | +---------------+------------+------------+------------+------------+ | confRequest | Gets | Creates | Changes | Deletes | | | conference | conference | conference | conference | | | object or | object | object | Object as | | | blueprint. | | | a whole. | | ------------- | ---------- | ---------- | ---------- | ---------- | | userRequest | Gets a | Creates | Adds or | Deletes a | | | specific | XCON-UserI | modifies | user | | | user | D . | the | element as | | | element. | | specified | a whole. | | | | | user | | | | | | element. | | | ------------- | ---------- | ---------- | ---------- | ---------- | | usersRequest | Gets a | N/A | Adds or | Deletes a | | | specific | | modifies | user | | | users | | the | element as | | | element. | | specified | a whole. | | | | | users | | | | | | element. | | | ------------- | ---------- | ---------- | ---------- | ---------- | | sidebarReques | Gets a | N/A | Adds or | Removes/de | | t | sidebar | | modifies a | l etes the | | | element. | | sidebar. | entire | | | | | | sidebar. | +---------------+------------+------------+------------+------------+ Barnes, et al. Expires December 18, 2008 [Page 14] Internet-Draft CCMP June 2008 Table 1: Request Type Operation Specific Processing 8.3. Handling a CCMP Response As with the CCMP request message, the CCMP response message is enclosed in a SOAP envelope. A response to the CCMP request MUST contain a response code and may contain other elements depending upon the specific request and the value of the response code. All response codes are application-level, and MUST only be provided in successfully processed transport-level responses. For example where HTTP is used, CCMP Response messages MUST be accompanied by a 200 OK HTTP response. The set of CCMP Response codes currently contain the following tokens: success: This code indicates that the request was successfully processed. modified: This code indicates that the object was created, but may differ from the request. badRequest: This code indicates that the request was badly formed in some fashion. unauthorized: This code indicates that the user was not authorized for the specific operation on the conference object. forbidden: This code indicates that the specific operation is not valid for the target conference object. objectNotFound: This code indicates that the specific conference object was not found. operationNotAllowed: This code indicates that the specific operation is not allowed for the target conference object (e.g.., due to policies, etc.) deleteFailedParent: This code indicates that the conferencing system cannot delete the specific conference object because it is a parent for another conference object. changeFailedProtected: This code indicates that the target conference object cannot be changed (e.g., due to policies, roles, privileges, etc.). requestTimeout: This code indicates that the request could not be processed within a reasonable time, with the time specific to a conferencing system implementation. serverInternalError: This code indicates that the conferencing system experienced some sort of internal error. notImplemented: This code indicates that the specific operation is not implemented on that conferencing system. CCMP Response codes are defined to allow for extensibility. A conference control client SHOULD treat unrecognized response codes as Barnes, et al. Expires December 18, 2008 [Page 15] Internet-Draft CCMP June 2008 it handles a Response code of "notImplemented". 8.3.1. Options Response An "optionsResponse" message containing a response code of "success" MUST include the XML namespaces that the server understands and the namespaces to be used in subsequent responses that it requires the client to understand. Future work may add more global capabilities rather than conferencing system specific. Within the conferencing system, the namespaces correlate with blueprints, as specified in the XCON framework. The blueprints are comprised of conference information initialized to specific values and ranges. Upon receipt of a successful "optionsResponse" message, a conference control client may then initiate a "confRequest" with a "retrieve" operation per Section 7.1 to get a specific conference blueprint. In the case of a response code of "requestTimeout", a conference control client MAY re-attempt the request within a period of time that would be specific to a conference control client or conference control server. The response codes of "modified", "deleteParentFailed" and "changeFailedProtected" are not applicable to an "optionsRequest" and should be treated as "serverInternalError", the handling of which is specific to the conference control client. An "optionsResponse" message containing any other response code is an error and the handling is specific to the conference control client. Typically, an error for an "optionsRequest" indicates a configuration problem in the conference control server or in the client. 8.3.2. Operation Responses The following sections detail the operation specific handling of the response codes, including details associated with specific types of responses in the cases where the response handling is not generic. 8.3.2.1. Retrieve Operation Responses A confResponse for a "retrieve" operation containing a response code of "success" MUST contain the full XML document describing the conference object in its current state including all inherited values. Elements may be marked by attributes, in particular, whether they are specific to this instance or have been inherited from the parent node. Any other CCMP response message (e.g., userResponse, usersResponse, Barnes, et al. Expires December 18, 2008 [Page 16] Internet-Draft CCMP June 2008 etc.) for a "retrieve" operation containing a response code of "success" MUST contain the XML document describing the specific target parameter (as indicated by the specific type of Request) from the conference object. If a response code of "objectNotFound" is received in a "confResponse" message to a "confRequest" to get the initial blueprint, it is RECOMMENDED that a conference control client attempt to retrieve another conference blueprint if more than one had been received in the "optionsResponse" message. If there was only one blueprint in the "optionsResponse" initially, then the client should send another "optionsRequest" message to determine if there may be new or additional blueprints for the specific conferencing system. If this "optionsResponse" message contains no blueprints, the handling is specific to the conference control client. If the client was retrieving an existing conference object that had been returned in a previous "optionsRequest", the "objectNotFound" could reflect a conference object that has been deleted by another user. In this case, the client should consider another "optionsRequest" message to obtain an up-to-date list of conference objects. If a response code of "requestTimeout" is received in the CCMP response, a conference control client MAY re-attempt the request within a period of time that would be specific to a conference control client or conference control server. Response codes such as "notImplemented" and "forbidden" indicate that a subsequent "retrieve" would not likely be sucessful. Handling of these and other response codes is specific to the conference control client. For example, in the case of some clients an "options" operation might be performed again or another conference control server may be accessed. The response codes of "modified", "deleteParentFailed" and "changeFailedProtected" are not applicable to the "retrieve" operation and SHOULD be treated as "serverInternalError", the handling of which is specific to the conference control client. 8.3.2.2. Create Operation Responses The only valid responses containing a "create" operation are a "confResponse" and the "userResponse". If the CCMP response contains a response code of "success", a "confResponse" message MUST contain the XCON-URI for the conference object and a "userResponse" message MUST contain the XCON-USERID. If the confResponse to a "create" operation contains a response code of "modified", along with the XCON-URI for the conference object, the Barnes, et al. Expires December 18, 2008 [Page 17] Internet-Draft CCMP June 2008 response MUST also contain the entire XML document associated with that conference object for a "confRequest". For example, in the case where the conference object contained a calendar element, the conference server may only offer a subset of the dates requested, thus the updated dates are included in the returned XML document. In the case of a response code of "requestTimeout", a conference control client MAY re-attempt the request within a period of time that would be specific to a conference control client or conference control server. Response codes such as "unauthorized", "forbidden" and "operationNotAllowed" indicate the client does not have the appropriate permissions, there is an error in the permissions, or there is a system error in the client or conference control server, thus re-attempting the request would likely not succeed. The response codes of "deleteParentFailed" and "changeFailedProtected" are not applicable to the "create" operation and SHOULD be treated as "serverInternalError", the handling of which is specific to the conference control client. Any other response code indicates an error in the client or conference control server (e.g., "forbidden", "badRequest") and the handling is specific to the conference control client. 8.3.2.3. Change Operation Responses If the CCMP response to the "change" operation contains a response code of "success", the response SHOULD also contain the XCON-URI for the conference object that was changed. If the CCMP response to the "change" operation contains a response code of "modified", the response MUST contain the XCON-URI for the conference object and the appropriate XML document (either the full XML document for a confResponse or specific paramaters for the other CCMP request types) associated with that conference object. For example, a conferencing system may not have the resources to support specific capabilities that were changed, such as in the , thus the supported are included in the returned XML document. If the CCMP response code of "requestTimeout" is received, a conference control client MAY re-attempt the request within a period of time that would be specific to a conference control client or conference control server. Response codes such as "unauthorized", "forbidden", Barnes, et al. Expires December 18, 2008 [Page 18] Internet-Draft CCMP June 2008 "operationNotAllowed" and "changeFailedProtected" indicate the client does not have the appropriate permissions, the conference is locked, there is an error in the permissions, or there is a system error in the client or conference control server, thus re-attempting the request would likely not succeed. The response code of "deleteParentFailed" is not applicable to the "change" operation and SHOULD be treated as "serverInternalError", the handling of which is specific to the conference control client. Any other response code indicates an error in the client or conference control server (e.g., "forbidden", "badRequest") and the handling is specific to the conference control client. 8.3.2.4. Delete Operation Responses If the CCMP response to the "delete" operation contains a response code of "success", the response MUST contain the XCON-URI for the conference object that was deleted for a "confResponse" or whose data element(s) were deleted for the other response types. The response code of "deleteParentFailed" indicates that the conference object could not be deleted because it is the Parent of another conference object that is in use. In this case, the response also includes the XCON-URI for the conference object and is only applicable to a "confResponse". If this response code is received for any other type of CCMP response, it should be treated as "serverInternalError", the handling of which is specific to the conference control client. If a response code of "requestTimeout" is received, a conference control client MAY re-attempt the request within a period of time that would be specific to a conference control client or conference control server. Response codes such as "unauthorized", "forbidden" and "operationNotAllowed" indicate the client does not have the appropriate permissions, the conference is locked, there is an error in the permissions, or there is a system error in the client or conference control server, thus re-attempting the request would likely not succeed. The response code of "changeFailedProtected" is not applicable to the "delete" operation and SHOULD be treated as "serverInternalError", the handling of which is specific to the conference control client. Any other response code indicates an error in the client or conference control server (e.g., "forbidden", "badRequest") and the Barnes, et al. Expires December 18, 2008 [Page 19] Internet-Draft CCMP June 2008 handling is specific to the conference control client. 9. Protocol Parameters This section describes in detail the parameters that are used for the CCMP protocol. 9.1. Operation Parameter The "operation" attribute is a mandatory token included in all CCMP request and response messages except the "optionsRequest" and "optionsResponse". This document defines four possible values for this parameter: "retrieve", "create", "change" and "delete". 9.2. Request ID Parameter The "requestID" attribute is a mandatory token included in all CCMP request and response messages. The "requestID" is used to correlate the requests with the appropriate response. 9.3. ConfObjID Parameter The "confObjID" attribute is an optional URI included in the CCMP request and response messages. This attribute is required in the case of an "operation" of "retrieve", "change", and "delete" in the CCMP request and response messages. The attribute is optional for an "operation" of "create" in the "confRequest" message. The "create" cases for which this parameter is REQUIRED are described in Section 7.2. This attribute is the XCON-URI which is the target for the specific operation. [Editor's Note: it might be good to re- iterate the normative text here.] This attribute is not included in the "userRequest" message for an operation of "create". In this case, the conference control client is requesting the creation of a new conference user, as detailed in Section 9.4. In the cases where the "conference-info" parameter Section 9.7 is also included in the requests and responses, the "confObjID" MUST match the XCON-URI in the "entity" attribute. 9.4. ConfUserID Parameter The "confUserID" attribute is optional URI included in the CCMP request and response messages. This is the XCON-USERID for the conference control client initiating the request. The attribute is required in the CCMP request and response messages with the exception Barnes, et al. Expires December 18, 2008 [Page 20] Internet-Draft CCMP June 2008 of the "userRequest" message. The "confUserID" parameter is used to determine if the conference control client has the authority to perform the operation. Note that the details for authorization and related policy are specified in a separate document [TBD]. This attribute is optional only for an "userRequest" message with a "create" operation. In this case, the request MUST include information about the user in the "user" element. At a minimum, the request MUST include the "user" element with an "entity" attribute. For this case, the conference control server MUST create a new conference user and return the associated confUserID in the response, if the allocation of a new XCON-USERID is succesful. In the case where there is a confUserID in the request that has already been allocated, this request may be the creation of a confUserID for the conference control client to take on an additional role. This attribute is required in the "userResponse" message in the case of an "operation" of "create" and for all other responses. 9.5. ResponseCode Parameter The "responseCode" attribute is a mandatory parameter in all CCMP response messages. The values for each of the "responseCode" values are detailed in Section 8.3 with the associated processing described in Section 8.3.2. 9.6. Blueprints Parameter The "blueprints" attribute is an optional parameter in the CCMP optionsResponse and confRequest messages. In the case of an "optionsRequest" message, the "optionsResponse" message with a "responseCode" of "success" SHOULD include the "blueprints" supported by the conference control server. The "blueprints" attribute is comprised of a list of blueprints supported by the specific conference server and includes a conference system specific "blueprintName" and a "confObjID" in the form of an XCON-URI for each of the blueprints. The "blueprints" attribute is optional for a confRequest with an operation of "retrieve". 9.7. Conference-info Parameter The "conference-info" element is optional in the CCMP confRequest and confResponse messages. Barnes, et al. Expires December 18, 2008 [Page 21] Internet-Draft CCMP June 2008 The "conference-info" element contains the data for the conference object that is the target for the "confRequest" operations for "create", "change" and "delete" operations. It is returned in a "confResponse" if the "confResponse" contains a responseCode of "modified" or if the original CCMP request for the "create" operation did not contain a "conference-info" element. The latter case occurs when a conference control client sends a "confRequest" containing any of the following: - a "confObjID" associated with a specific blueprint - a "confObjID associated with a specific active conference or conference reservation that was included in an "optionsResponse" message - no "confObjID" (or "conference-info") element, in which case the request is to create a conference object based on a default provided by a conferencing system. The details on the information that may be included in the "conference-info" element MUST follow the rules as specified in the XCON Data Model document [I-D.ietf-xcon-common-data-model]. The conference control client and conference control server MUST follow those rules in generating the "conference-info" in any of the CCMP request and response messages. Note that the "conference-info" element is not explicitly shown in the XML schema (Section 12) due to XML schema constraints. 9.8. User Parameter The "user" element contains the data for the conference user that is the target for the CCMP request operations. It is REQUIRED for all "userRequest" messages. The details on the information that may be included in the "user" element MUST follow the rules as specified in the XCON Data Model document [I-D.ietf-xcon-common-data-model]. The conference control client and conference control server MUST follow those rules in generating the "user" in any of the CCMP request and response messages. Note that the "user" element is not explicitly shown in the XML schema Section 12 due to XML schema constraints. 9.9. Users Parameter The "users" element contains the data for the conference users that are the target for the CCMP request operations. It is REQUIRED for all "usersRequest" messages. The details on the information that may be included in the "users" element MUST follow the rules as specified in the XCON Data Model Barnes, et al. Expires December 18, 2008 [Page 22] Internet-Draft CCMP June 2008 document [I-D.ietf-xcon-common-data-model]. The conference control client and conference control server MUST follow those rules in generating the "users" in any of the CCMP request and response messages. Note that the "users" element is not explicitly shown in the XML schema Section 12 due to XML schema constraints. 9.10. Sidebar Parameters The "sidebar" parameter contains the data for the sidebar that is the target for the CCMP request operations. It is REQUIRED for all "sidebarRequest" messages. There are two elements associated with a sidebar: "sidebar-by-val" and "sidebar-by-ref". The elements relate to whether the data for the sidebar is in the same conference object for which it serves as a sidebar or whether a new conference object is created for the sidebar. The details on the information that may be included in the "sidebar- by-val" or "sidebar-by-ref" element MUST follow the rules as specified in the XCON Data Model document [I-D.ietf-xcon-common-data-model]. The conference control client and conference control server MUST follow those rules in generating the "sidebar-by-val" or "sidebar-by-ref" element in any of the CCMP request and response messages. 10. Examples The examples below omits the standard SOAP header and wrappers, i.e., the examples below contain simply the of the requests and responses. 10.1. Creating a New Conference The first example creates a new conference. Barnes, et al. Expires December 18, 2008 [Page 23] Internet-Draft CCMP June 2008 99 create userA-confxyz987 http://example.com/conf200 Agenda: This month's goals sips:conf223@example.com participation http://sharep/salesgroup/ web-page http://example.com/conf233 control Figure 2: Create Request Example The response to this request is shown below; it returns the object identifier as a URL and the final conference description, which may modify the description offered by the user. Barnes, et al. Expires December 18, 2008 [Page 24] Internet-Draft CCMP June 2008 99 create modified xcon:confxyz987@example.com userA-confxyz987 xcon:confxyz987@example.com http://example.com/conf200 Agenda: This month's goals sips:conf223@example.com participation http://sharep/salesgroup/ web-page http://example.com/conf233 control Figure 3: Create Response Example Barnes, et al. Expires December 18, 2008 [Page 25] Internet-Draft CCMP June 2008 10.2. Creating a New Conference User The request below creates a new conference user, independent of a specific conference object. 101 create observer Figure 4: Create User Example The response to this request is shown below; it returns the conference user identifier. 101 create success userC-confxyz987 Figure 5: Create Response Example 10.3. Adding a User to a Conference The request below adds a user to the conference identified by the XCON-URI. Note that the user in "confUserID" element is the user requesting that the user "sip:claire@example.com" be added to the conference. The user may or may not be "claire" (i.e., a user, such as the moderator, can add another user to the conference. Barnes, et al. Expires December 18, 2008 [Page 26] Internet-Draft CCMP June 2008 100 change xcon:confxyz987@example.com userC-confxyz987 xcon:confxyz987@example.com participant dial-out Figure 6: Add User Example The response to this request is shown below; it returns the conference user identifier. Barnes, et al. Expires December 18, 2008 [Page 27] Internet-Draft CCMP June 2008 100 create success xcon:confxyz987@example.com userC-confxyz987 xcon:confxyz987@example.com participant Figure 7: Add User Response Example 11. Transaction Model The transaction model for CCMP complies fully with SOAP version 1.2 as defined by W3C in [W3C.REC-soap12-part1-20030624] and [W3C.REC-soap12-part2-20030624]. 12. XML Schema This section provides the XML schema definition of the "application/ ccmp+xml" format. Barnes, et al. Expires December 18, 2008 [Page 28] Internet-Draft CCMP June 2008 Barnes, et al. Expires December 18, 2008 [Page 29] Internet-Draft CCMP June 2008 Barnes, et al. Expires December 18, 2008 [Page 30] Internet-Draft CCMP June 2008 Barnes, et al. Expires December 18, 2008 [Page 31] Internet-Draft CCMP June 2008 Figure 8 Barnes, et al. Expires December 18, 2008 [Page 32] Internet-Draft CCMP June 2008 13. WSDL Definition The following provides the WSDL definition for conference control and manipulation, using the the XML schema defined in Section 12 as a basis. Barnes, et al. Expires December 18, 2008 [Page 33] Internet-Draft CCMP June 2008 Figure 9 14. IANA Considerations This document registers a new XML namespace, a new XML schema, and the MIME type for the schema. This document also defines registries for the CCMP operation types and response codes. 14.1. URN Sub-Namespace Registration This section registers a new XML namespace, ""urn:ietf:params:xml:ns:xcon:ccmp"". URI: "urn:ietf:params:xml:ns:xcon:ccmp" Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Barnes (mary.barnes@nortel.com). XML: Barnes, et al. Expires December 18, 2008 [Page 34] Internet-Draft CCMP June 2008 BEGIN CCMP Messages

Namespace for CCMP Messages

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

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

See RFCXXXX.

END 14.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:xcon:ccmp Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Barnes (mary.barnes@nortel.com). Schema: The XML for this schema can be found as the entirety of Section 12 of this document. 14.3. MIME Media Type Registration for 'application/ccmp+xml' This section registers the "application/ccmp+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/ccmp+xml MIME media type name: application MIME subtype name: ccmp+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], section 3.2. Barnes, et al. Expires December 18, 2008 [Page 35] Internet-Draft CCMP June 2008 Security considerations: This content type is designed to carry protocol data related conference control. Some of the data could be considered private and thus should be protected. Interoperability considerations: This content type provides a basis for a protocol Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications which use this media type: Centralized Conferencing control clients and servers. Additional Information: Magic Number(s): (none) File extension(s): .xml Macintosh File Type Code(s): (none) Person & email address to contact for further information: Mary Barnes Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/ccmp+xml. 14.4. CCMP Protocol Registry This document requests that the IANA create a new registry for the CCMP protocol including an initial registry for operation types and response codes. 14.4.1. CCMP Message Types The CCMP messages are described in Section 8 and defined in the XML schema in Section 12. The following summarizes the requested registry: Related Registry: CCMP Message Types Registry Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Registration/Assignment Procedures: New CCMP message types are allocated on a specification required basis. Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Barnes (mary.barnes@nortel.com). This section pre-registers the following initial CCMP message types: optionsRequest: Used by a conference control client to query a conferencing system for its capabilities. Barnes, et al. Expires December 18, 2008 [Page 36] Internet-Draft CCMP June 2008 optionsResponse: The optionsResponse returns a list of Blueprints supported by the specific conference server. confRequest: The confRequest is used to create a conference object and/or to request an operation on the conference object as a whole. confResponse: The confResponse indicates the result of the operation on the conference object as a whole. userRequest: The userRequest is used to request an operation on the "user" element in the conference object. userResponse: The userResponse indicates the result of the requested operation on the "user" element in the conference object. usersRequest This usersRequest is used to manipulate the "users" element in the conference object, including parameters such as the allowed-users-list, join-handling, etc. usersResponse: This usersResponse indicates the result of the request to manipulate the "users" element in the conference object. sidebarRequest: This sidebarRequest is used to retrieve the information related to a sidebar or to create, change or delete a specific sidebar. sidebarResponse: This sidebarResponse indicates the result of the sidebarRequest. 14.4.2. CCMP Response Codes The following summarizes the requested registry for CCMP Response codes: Related Registry: CCMP Response Code Registry Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Registration/Assignment Procedures: New response codes are allocated on a first-come/first-serve basis with specification required. Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Barnes (mary.barnes@nortel.com). This section pre-registers the following thirteen initial response codes as described above in Section 8.3: success: This code indicates that the request was successfully processed. modified: This code indicates that the object was created, but may differ from the request. badRequest: This code indicates that the request was badly formed in some fashion. Barnes, et al. Expires December 18, 2008 [Page 37] Internet-Draft CCMP June 2008 unauthorized: This code indicates that the user was not authorized for the specific operation on the conference object. forbidden: This code indicates that the specific operation is not valid for the target conference object. objectNotFound: This code indicates that the specific conference object was not found. operationNotAllowed: This code indicates that the specific operation is not allowed for the target conference object (e.g.., due to policies, etc.) deleteFailedParent: This code indicates that the conferencing system cannot delete the specific conference object because it is a parent for another conference object. changeFailedProtected: This code indicates that the target conference object cannot be changed (e.g., due to policies, roles, privileges, etc.). requestTimeout: This code indicates that the request could not be processed within a reasonable time, with the time specific to a conferencing system implementation. serverInternalError: This code indicates that the conferencing system experienced some sort of internal error. notImplemented: This code indicates that the specific operation is not implemented on that conferencing system. 15. Security Considerations Access to conference control functionality needs to be tightly controlled to keep attackers from disrupting conferences, adding themselves to conferences or engaging in theft of services. Implementors need to deploy standard HTTP and SOAP authentication and authorization mechanisms. Since conference information may contain secrets such as participant lists and dial-in codes, all conference control information SHOULD be carried over TLS (HTTPS). 16. Acknowledgments The authors appreciate the feedback provided by Dave Morgan and Pierre Tane. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Barnes, et al. Expires December 18, 2008 [Page 38] Internet-Draft CCMP June 2008 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [W3C.CR-wsdl20-20051215] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", W3C CR CR-wsdl20-20051215, December 2005. [W3C.REC-soap12-part1-20030624] Gudgin, M., Mendelsohn, N., Hadley, M., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1- 20030624, June 2003, . [W3C.REC-soap12-part2-20030624] Mendelsohn, N., Moreau, J., Nielsen, H., Hadley, M., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium FirstEdition REC-soap12-part2-20030624, June 2003, . [I-D.ietf-xcon-framework] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", draft-ietf-xcon-framework-11 (work in progress), April 2008. [I-D.ietf-xcon-common-data-model] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-11 (work in progress), June 2008. 17.2. Informative References [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Barnes, et al. Expires December 18, 2008 [Page 39] Internet-Draft CCMP June 2008 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [I-D.ietf-xcon-event-package] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", draft-ietf-xcon-event-package-00 (work in progress), February 2008. [I-D.royer-calsch-xcal] Royer, D., "iCalendar in XML Format (xCal-Basic)", draft-royer-calsch-xcal-03 (work in progress), October 2005. Authors' Addresses Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX Email: mary.barnes@nortel.com Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@avaya.com Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy Email: spromano@unina.it Barnes, et al. Expires December 18, 2008 [Page 40] Internet-Draft CCMP June 2008 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 Email: hgs+xcon@cs.columbia.edu Barnes, et al. Expires December 18, 2008 [Page 41] Internet-Draft CCMP June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Barnes, et al. Expires December 18, 2008 [Page 42]