XCON Working Group M. Barnes Internet-Draft Nortel Expires: December 26, 2006 C. Boulton Ubiquity Software Corporation June 24, 2006 Centralized Conferencing Manipulation Protocol draft-barnes-xcon-ccmp-01 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 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract "A Framework and Data Model for Centralized Conferencing" defines a model whereby client intereaction is required for creation, deletion, and manipulation of a conference, as well as querying the state of a conference. The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the appropriate mechanisms for these protocol interactions. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions Barnes & Boulton Expires December 26, 2006 [Page 1] Internet-Draft CCMP June 2006 specified via Web Services Description Language (WSDL). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 5.1. Identifying a Conference Instance . . . . . . . . . . . . 5 5.2. Constructing a CCMP request . . . . . . . . . . . . . . . 5 5.2.1. Query Blueprints . . . . . . . . . . . . . . . . . . . 5 5.2.2. Get Template . . . . . . . . . . . . . . . . . . . . . 6 5.2.3. Create a Conference Object (Explicitly) . . . . . . . 6 5.2.4. Create a Conference Object (Implicitly) . . . . . . . 6 5.2.5. Manipulate a Conference Object . . . . . . . . . . . . 6 5.2.6. Query Conference Object . . . . . . . . . . . . . . . 6 5.2.7. Delete Conference Object . . . . . . . . . . . . . . . 6 5.3. Sending a CCMP Request . . . . . . . . . . . . . . . . . . 7 6. System Architecture . . . . . . . . . . . . . . . . . . . . . 7 7. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 9 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 8.1. Query Blueprints . . . . . . . . . . . . . . . . . . . . . 9 8.2. Get Template . . . . . . . . . . . . . . . . . . . . . . . 9 8.3. Create Conference Object . . . . . . . . . . . . . . . . . 9 8.4. Manipulate Conference Object . . . . . . . . . . . . . . . 9 8.5. Query Conference Object . . . . . . . . . . . . . . . . . 9 8.6. Delete Conference Object . . . . . . . . . . . . . . . . . 9 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 11 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 15.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Barnes & Boulton Expires December 26, 2006 [Page 2] Internet-Draft CCMP June 2006 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. It is the purpose of this document to allow the manipulation of a conference object by authenticated and authorized clients. This is achieved using an appropriate client-server Remote Procedure Call (RPC) mechanism. In this document the Simple Object Access Protocol (SOAP) has been chosen to carry out the appropriate client-server protocol transactions. The common information contained in all conference objects is defined using an XML representation such as the one introduced in Conference Package [7] and 'A Common Conference Information Data Model for Centralized Conferencing' [9]. These data structures are used as the basis for the Web Services Description Language (WSDL) [3] definition and XML schema. This document first provides an overview of the protocol operations in Section 5, followed by a system architecture in Section 6. The detailed potocol operation information is provided in Section 8. An XML schema is provided in Section 9. WSDL information is detailed in Section 10 and some example interactions in Section 11. 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]. In addition, the following acronyms and terms are used in this document: Barnes & Boulton Expires December 26, 2006 [Page 3] Internet-Draft CCMP June 2006 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 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. WSDL is a natural fit for specifying the content of the conference control protocol messages. 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. [Editor's note: the current content of this document is very incomplete. This document can very easily be combined with [10] as a starting point for a very comprehensive document once the XCON WG agrees on the fundamental verbs and nouns (and required level of granularity) for the protocol. ] Barnes & Boulton Expires December 26, 2006 [Page 4] Internet-Draft CCMP June 2006 5. Overview of Operation The primary function of this document 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 carry out operations on a particular conference object follows a series of steps as detailed in the following sections. 5.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 the appropriate conference object identifier. [Editors Note: Requests using this mechanism need to convey the appropriate conference instance identifier as defined in the XCON Framework. This will be included in later versions of this document.] 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. [Editors Note: More detail to be provided. Again, need to discuss inclusion of conference identifier] 5.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 10. Construction of a valid conference control protocol message includes the options, discussed in the following sections, depending upon the function and associated information desired by the conference control client. 5.2.1. Query Blueprints The Query Blueprints operation is used by a client to query a system for its capabilities. These capabilities are represented by blueprints, as specified in [6]. The blueprints are comprised of common conference information initialized to specific values and ranges, and typically a single template for specifying media Barnes & Boulton Expires December 26, 2006 [Page 5] Internet-Draft CCMP June 2006 characteristics, etc. 5.2.2. Get Template The Get Template operation is used by a client to query a system for a specific template. The templates are either included in the blueprint by-value or by-reference. In the case of by-reference, a client may need to obtain any new template that it has not previously used for that system. 5.2.3. Create a Conference Object (Explicitly) This conference control operation is used by a client to create and reserve a conference object for that system based upon a specific blueprint. 5.2.4. Create a Conference Object (Implicitly) This conference control operation is used by a client to construct a request to create a conference without providing a conference object based on a specific blueprint. This results in the creation and reservation of an instance of the default conference object. The default conference object is specific to a conferencing system and its specification is outside the scope of this document. 5.2.5. Manipulate a Conference Object 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.). 5.2.6. Query Conference Object This conference control operation is used to retrieve the current representation of a conference object and requires the unique conference identifier be provided by the client, as discussed in Section 5.1. 5.2.7. Delete Conference Object 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 discussed in Section 5.1. Further details of these operations is provided in Section 8 Barnes & Boulton Expires December 26, 2006 [Page 6] Internet-Draft CCMP June 2006 5.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. Detail describing the protocol operations can be found in Section 8. [Editors Note: It is fully expected that the Operations will involve asynchronous transactions. This section will be expanded at a later date to allow synchronous transactions. ]. 6. 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 & Boulton Expires December 26, 2006 [Page 7] Internet-Draft CCMP June 2006 ........................................................ . 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 & Boulton Expires December 26, 2006 [Page 8] Internet-Draft CCMP June 2006 centralized conferencing document and related documents. 7. Transaction Model The transaction model for CCMP complies fully with SOAP version 1.2 as defined by W3C in [ref]. 8. Protocol Operations This section provides descriptive text for the basic protocol operations for CCMP. 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 10 which uses HTTP operations as the transport mechanism. The following sections provide more detail on specific protocol operations. 8.1. Query Blueprints TODO - describe use in conjunction with HTTP GET. 8.2. Get Template TODO - describe use in conjunction with HTTP GET. 8.3. Create Conference Object TODO - describe use in conjunction with HTTP POST. 8.4. Manipulate Conference Object TODO - describe use in conjunction with HTTP POST. 8.5. Query Conference Object TODO - describe use in conjunction with HTTP GET. 8.6. Delete Conference Object TODO - describe use in conjunction with HTTP POST. 9. 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 Barnes & Boulton Expires December 26, 2006 [Page 9] Internet-Draft CCMP June 2006 fundamental XCON data model that is agreed.] Barnes & Boulton Expires December 26, 2006 [Page 10] Internet-Draft CCMP June 2006 Figure 2 10. WSDL Definition The following provides the WSDL definition for conference control and manipulation, using the the XML schema defined in Section 9 as a basis. Barnes & Boulton Expires December 26, 2006 [Page 11] Internet-Draft CCMP June 2006 Barnes & Boulton Expires December 26, 2006 [Page 12] Internet-Draft CCMP June 2006 Figure 3 11. Examples TODO 12. IANA Considerations TODO 13. Security Considerations TODO 14. Acknowledgments Henning Schulzrinne provided the initial impetus for this proposal. He and Orit Levin provided useful input. 15. References 15.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. Barnes & Boulton Expires December 26, 2006 [Page 13] Internet-Draft CCMP June 2006 [4] Nielsen, H., Gudgin, M., Mendelsohn, N., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium Recommendation http://www.w3.org/TR/2003/ REC-soap12-part1-20030624, June 2003. [5] Nielsen, H., Hadley, M., Moreau, J., Gudgin, M., and N. Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium Recommendation http://www.w3.org/TR/2003/ REC-soap12-part2-20030624, June 2003. 15.2. Informative References [6] Barnes, M., "A Framework and Data Model for Centralized Conferencing", draft-ietf-xcon-framework-04 (work in progress), June 2006. [7] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-12 (work in progress), July 2005. [8] Levin, O., "Centralized Conference Control Protocol", draft-levin-xcon-cccp-04 (work in progress), January 2006. [9] Novo, O., "A Common Conference Information Data Model for Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-00 (work in progress), April 2006. [10] Schulzrinne, H., "COMP: Conference Object Manipulation Protocol", draft-schulzrinne-xcon-comp-00 (work in progress), January 2006. Barnes & Boulton Expires December 26, 2006 [Page 14] Internet-Draft CCMP June 2006 Authors' Addresses Mary Barnes Nortel 2380 Performance Drive 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 & Boulton Expires December 26, 2006 [Page 15] Internet-Draft CCMP June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barnes & Boulton Expires December 26, 2006 [Page 16]