XCON Working Group M. Barnes Internet-Draft Nortel Expires: August 9, 2007 C. Boulton Ubiquity Software Corporation H. Schulzrinne Columbia University February 5, 2007 Centralized Conferencing Manipulation Protocol draft-barnes-xcon-ccmp-02 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 August 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 and SIP event notification as its infrastructure, but can control Barnes, et al. Expires August 9, 2007 [Page 1] Internet-Draft CCMP February 2007 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 interactions specified via Web Services Description Language (WSDL). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 5 6. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 7 6.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Conference Objects . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Conference Object Definition . . . . . . . . . . . . . . . 9 7.2. Conference Users and Participants . . . . . . . . . . . . 10 7.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Media Groups . . . . . . . . . . . . . . . . . . . . . . . 12 8. Protocol Operations on Conference Objects . . . . . . . . . . 12 8.1. Identifying a Conference Instance . . . . . . . . . . . . 12 8.2. Constructing a CCMP request . . . . . . . . . . . . . . . 13 8.3. Sending a CCMP Request . . . . . . . . . . . . . . . . . . 13 8.4. Handling Responses and Error Conditions . . . . . . . . . 13 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 16 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Barnes, et al. Expires August 9, 2007 [Page 2] Internet-Draft CCMP February 2007 1. Introduction The Framework and Data Model for Centralized Conferencing [6] defines a signaling agnostic data model, naming conventions and logical entities required for constructing advanced conferencing systems. A primary concept introduced in the framework and data model for centralized conferencing is the existence of a conference object. The conference object is 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 and privileges, as well as adding and removing media streams and associated end points. CCMP is based on the three fundamental components of a centralized conference: the conference as a whole, users and media. CCMP implements a client-server model. The server is the Conference Control Server defined in the framework [6], while clients can either be signaling end points, such as SIP user agents, or control-only agents that do not contribute media to the conference. 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) used to carry out the appropriate client-server protocol transactions. The common information contained in conference objects is defined using an XML representation such as the one introduced in Conference Package [11] and 'A Common Conference Information Data Model for Centralized Conferencing' [12]. These data structures are used as the basis for the Web Services Description Language (WSDL) [3] 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. The protocol operations are then detailed in Section 6, with a discussion of the key elements in the conference object in Section 7. The practical sequence of protocol operations is discussed in Section 8, with examples provided in Section 9. An XML schema is provided in Section 11. WSDL information is detailed in Section 12. Barnes, et al. Expires August 9, 2007 [Page 3] Internet-Draft CCMP February 2007 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 [1] and indicate requirement levels for compliant implementations. 3. Terminology This document reuses the terminology defined in the Framework and Data Model for Centralized Conferencing [6] and High-Level Requirements for Tightly Coupled SIP Conferencing [9]. In addition, the following acronyms and terms are used in this document: SOAP: Simple Object Access Protocol. WSDL: Web Services Description Language. 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 and data model 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 and how 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). SOAP can be used with a variety of transport protocols. For the purposes of its role in providing the basis for the conference control protocol, HTTP is the chosen transport. The advantages of the use of SOAP as the basis for the conference control protocol are deemed to be the re-use of existing standards, the ease of software development, the availability of tools, and the ease of integration with deployed systems. Barnes, et al. Expires August 9, 2007 [Page 4] Internet-Draft CCMP February 2007 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 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 described 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, simplest type of extension adds elements to the overall conference, 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 6.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 and data model for centralized conferencing [6]. Figure 1 depicts a subset of the 'Conferencing System Logical Decomposition' architecture from the framework and data model for centralized conferencing document. It illustrates the role that CCMP assumes within the overall centralized architecture. Barnes, et al. Expires August 9, 2007 [Page 5] Internet-Draft CCMP February 2007 ........................................................ . 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 conference control server, as represented in Figure 1. Conference Control is one set of functionality for advancing conferencing supported by a conferencing client. Other functions are discussed in the framework and data model for Barnes, et al. Expires August 9, 2007 [Page 6] Internet-Draft CCMP February 2007 centralized conferencing document and related documents. 6. 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 specific operations on a conference object. This section describes the generic behavior of the four core operations on conference objects. These operations should operate in the same manner for new objects that might be defined later. There is also a querying mechanism to ascertain the namespaces understood by the server, thus 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 provide the ability to action all of the protocol operations in this section and MUST fully implement the SOAP WSDL schema defined in Section 12 which uses HTTP operations as the transport mechanism. 6.1. Options The "options" operation is used by a client to query a system for its capabilities and doesn't pertain to a particular conference or conference object. In this document, the response returns the XML namespaces that the server understands and the namespaces to be used in 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 [6]. The blueprints are comprised of common conference information initialized to specific values and ranges. [TBD: Should this also be made available via an HTTP OPTIONS request?] 6.2. Get The "get" operation returns the full XML document describing the 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. The "get" 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. The "get" operation is also used to retrieve the current representation of a specific conference object for a conference reservation or an active conference. In this case, the operation requires the unique conference identifier be provided by Barnes, et al. Expires August 9, 2007 [Page 7] Internet-Draft CCMP February 2007 the client as defined by [13] To simplify operations, the HTTP/SOAP "get" method can also be used directly on these URLs, so that simple systems that need to only obtain data about conference objects do not need a full SOAP implementation. 6.3. Create The "create" operation is used by a client to create and reserve a conference object. The creation of the conference object can be explicit by requesing it to be created based upon a specific blueprint. When the creation of a conference object is implicit, with no specific blueprint specified, the creation and reservation of the conference instance is based on the default conference object. The default conference object is specific to a conferencing system and its specification is outside the scope of this document. The "create" operation may also be used to create a new conference user. To simplify operations, the HTTP/SOAP PUT can also be used to create a new objects. 6.4. Change The "change" operation updates the object identified. 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 conference control operation is used by a conference control client to manipulate a conference object. This includes the ability to pass relevant fragments of the conference object along with relevant operation types (add, delete, modify, etc.). To simplify operations, the HTTP/SOAP POST can also be used to change objects. 6.5. Delete This conference control operation is used to delete the current representation of a conference object and requires the unique conference identifier be provided by the client, as as defined by [13]. A request which attempts to delete a conference object that is being referenced by a child object is an error. Barnes, et al. Expires August 9, 2007 [Page 8] Internet-Draft CCMP February 2007 7. Conference Objects This section describes some of the key elements in the conference object manipulated by the conference control protocol. Conference objects are referenced by unique identifiers as defined in [6] and [13] 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. Each object has four basic operations: create, change, delete and get, as described in Section 6. Object properties that are not explicitly replaced, remain as-is. This approach makes it possible to manipulate objects created by another application even if the manipulating application does not understand all object properties. To simplify operations, a server treats certain parameters as suggestions, as noted in the object description. If the 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. 7.1. Conference Object Definition Conferences use the conference object as defined by the schema in [12]. A client MAY add a parent element that indicates the parent from which the conference is to inherit values. When creating conferences, the conference URIs are only suggestions by the client. To avoid identifier collisions and to conform to local server policy, the server MAY choose different identifiers. These identifiers are returned in the response. In addition, the conference description MAY contain a calendar element, in the iCal format in XML rendition defined in CPL [7] or (preferable, if available as stable reference) xCal [15]. This description indicates when the conference is active. As discussed above, the conference server may be only offer a subset of the dates, indicated by the 203 response. Barnes, et al. Expires August 9, 2007 [Page 9] Internet-Draft CCMP February 2007 7.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. A variety of elements defined in the common conference information as specified in [12] are used to determine how a specific user expects and is allowed to join a conference. Many of the attributes are based on those defined in Section 5.6.4 of [11], such as the element. The element defines how the caller is to be reached, 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. If the conference is currently active, dial-out users are contacted immediately; otherwise, they are contacted at the start of the conference. is the default. In many conferences, users dial in if they know the conference URI and an access code shared by all conference participants. We represent this user by a element without entity attribute. Only the (default) type of is permitted for this type of user. The Conference Control Server then creates individual users as users dial in, identified, in the entity attribute, by their call signaling URL, such as their SIP URL, tel URI [8] or similar. In cases where there is no such URI, e.g., because a PSTN caller has blocked caller-ID delivery, the server assigns a locally-unique URI, such as a locally-scoped tel URI. The system uses the entity identifier or access code to change or delete user elements. Three examples for user elements are shown below; the second user element is a dial-in user with access code and only listen capability, while the other access code allows full participant access. Barnes, et al. Expires August 9, 2007 [Page 10] Internet-Draft CCMP February 2007 moderator sending receiving en questions lecture passiveParticipant activeParticipant Figure 2: User Element Examples 7.3. Roles While the conference package allows the association of a role with each user, it does not offer a mechanism to define those roles. This document provides an initial mechanism to associate roles with a set of associated permitted activities, i.e., rights. An empty list designates no permissions. The set of rights is defined by the in [12] Roles cannot be changed by normal users and are likely to be media- specific. Thus, we use the concept of media groups instead. In addition, there is a media permission list for each role, identified by the media bus or label per Section 7.4 Active participants can always subscribe to conference events and see their own status. It is expected that the conference roles are defined in conference documents that are then inherited by most locally-defined conferences so that conferences would typically not have to define new roles. getUsers moderator addUser Barnes, et al. Expires August 9, 2007 [Page 11] Internet-Draft CCMP February 2007 Figure 3: Role Example 7.4. Media Groups The concept of a media bus/floor describes all the media sources that are controlled together and mixed together. If the conference has floor control such as via BFCP, read and write permission are governed by the floor control protocol. If not, the static configuration modified via CCMP can be used to control read and write access to media groups. SDP labels [11]are used to identify media streams. In addition to the name, the media group may also designate rendering properties of the floor. Initially, we designate the grid (e.g., 4x4) for video streams and how many squares the active speaker occupies. For audio streams, the stereo position is expressed as a number from -1 (leftmost) to +1 (rightmost). Additional properties can be added later by extensions from additional namespaces. Figure 4: Media Group Example 8. Protocol Operations on Conference Objects The primary function of the conference control protocol is to provide a conference control client with the ability to carry out specific operations on a conference object. As mentioned previously, SOAP is used as the the XML RPC mechanism to fulfill such operations. A conference control client wishing to perform an operation(s) on a particular conference object follows a series of steps as detailed in the following sections. 8.1. Identifying a Conference Instance For any operation that is to be carried out on an existing conference object, a unique identifier is required. The framework and data model for centralized conferencing [6] defines a conference object identifier with the details provided in [13]. Barnes, et al. Expires August 9, 2007 [Page 12] Internet-Draft CCMP February 2007 Operations can be initiated from a conference control client for the purpose of creating a conference object. To achieve this, an operation is executed without specifying a unique conference object identifier. If the operation is successful, the unique conference object identifier be included in the SOAP response transaction. 8.2. Constructing a CCMP request The construction of the SOAP envelope associated with a conference control request message complies fully with the WSDL, as defined in Section 12. Construction of a valid conference control protocol message is based upon the operations defined in Section 6, depending upon the function and associated information desired by the conference control client. 8.3. Sending a CCMP Request A constructed CCMP message that is compliant to the SOAP WSDL is then ready to be executed using appropriate protocol operations as described in Section 6. [Editors Note: It is fully expected that the Operations will involve asynchronous transactions. This section will be expanded at a later date to allow asynchronous transactions. ]. 8.4. Handling Responses and Error Conditions Specific error conditions are described below, but there are several general conditions that can occur for any object and operation. Errors are described by a combination of a status code and a reason phrase. As in SIP and HTTP, responses contain a three-digit numeric status code and a textual response, possibly in different languages. The numeric status codes are described below. For easy recognition, they correspond to SIP response codes where this makes sense, but the name spaces are otherwise distinct. Barnes, et al. Expires August 9, 2007 [Page 13] Internet-Draft CCMP February 2007 +----------------------+----------------------+---------------------+ | Code | Reason phrase | Explanation | +----------------------+----------------------+---------------------+ | 200 | OK | successful | | 202 | Pending | notification to | | | | follow | | 203 | Modified | The object was | | | | created, but may | | | | differ from the | | | | request. | | 302 | Moved temporarily | An object should be | | | | referenced by a | | | | different | | | | identifier. | | 400 | Bad request | | | 401 | Unauthorized | | | 403 | Forbidden | | | 404 | Object not found | | | 405 | Method not allowed | user is not allowed | | | | to perform this | | | | method, such as | | | | 'create', on the | | | | object | | 408 | Request timeout | | | 409 | Cannot delete since | | | | it is a parent for | | | | another node | | | 410 | Cannot change since | | | | it is marked as | | | | protected | | | 500 | Server internal | | | | error | | | 501 | Not implemented | The function or | | | | object has not been | | | | implemented. | +----------------------+----------------------+---------------------+ Figure 5: Response Codes 9. Examples The examples below omits the standard SOAP header and wrappers, i.e., the part below is simply the of the response. The first example creates a new conference. The conference URIs are proposals by the client to the server; the server makes the final Barnes, et al. Expires August 9, 2007 [Page 14] Internet-Draft CCMP February 2007 decision as to whether it will honor those requests. create 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 6: Create 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. 200 OK [... modified conference description ...] Figure 7: Create Response Barnes, et al. Expires August 9, 2007 [Page 15] Internet-Draft CCMP February 2007 The request below adds a user to the conference identified by the conference URI. create receiving Figure 8: Add User Example 10. Transaction Model The transaction model for CCMP complies fully with SOAP version 1.2 as defined by W3C in [ref]. 11. XML Schema [Editor's note: This current version is currently bare bones. It will be enhanced and updated and also needs to align with the fundamental XCON data model that is agreed.] Barnes, et al. Expires August 9, 2007 [Page 16] Internet-Draft CCMP February 2007 Barnes, et al. Expires August 9, 2007 [Page 17] Internet-Draft CCMP February 2007 Figure 9 12. WSDL Definition The following provides the WSDL definition for conference control and manipulation, using the the XML schema defined in Section 11 as a basis. Barnes, et al. Expires August 9, 2007 [Page 18] Internet-Draft CCMP February 2007 Figure 10 13. IANA Considerations TODO 14. Security Considerations Access to conference control functionality needs to be tightly controlled to avoid attackers disrupting conferences, adding themselves to conferences or engaging in theft of services. Implementors needs 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). Barnes, et al. Expires August 9, 2007 [Page 19] Internet-Draft CCMP February 2007 15. Acknowledgments This document incorporates Henning's original "COMP: Conference Object Manipulation Protocol" proposal. 16. References 16.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] 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. [4] Moreau, J., Gudgin, M., Nielsen, H., Hadley, M., and N. Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium Recommendation REC-soap12-part1- 20030624, June 2003, . [5] Hadley, M., Mendelsohn, N., Moreau, J., Gudgin, M., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium Recommendation REC-soap12-part2-20030624, June 2003, . 16.2. Informative References [6] Barnes, M., "A Framework and Data Model for Centralized Conferencing", draft-ietf-xcon-framework-07 (work in progress), January 2007. [7] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. [8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [9] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. Barnes, et al. Expires August 9, 2007 [Page 20] Internet-Draft CCMP February 2007 [10] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [11] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [12] Novo, O., "A Common Conference Information Data Model for Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-03 (work in progress), October 2006. [13] Boulton, C. and M. Barnes, "A Universal Resource Identifier (URI) for Centralized Conferencing (XCON)", draft-boulton-xcon-uri-00 (work in progress), October 2006. [14] Boulton, C. and M. Barnes, "A User Identifier for Centralized Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in progress), October 2006. [15] 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 Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Barnes, et al. Expires August 9, 2007 [Page 21] Internet-Draft CCMP February 2007 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 August 9, 2007 [Page 22] Internet-Draft CCMP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Barnes, et al. Expires August 9, 2007 [Page 23]