XCON Working Group C. Boulton Internet-Draft Ubiquity Software Corporation Expires: July 3, 2006 M. Barnes Nortel December 30, 2005 Centralized Conferencing Manipulation Protocol draft-barnes-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 July 3, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 Boulton & Barnes Expires July 3, 2006 [Page 1] Internet-Draft CCMP December 2005 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6 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 Boulton & Barnes Expires July 3, 2006 [Page 2] Internet-Draft CCMP December 2005 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. The document comprises of details relating to general Overview and System Architecture in Section 5 and Section 6. It is also provides detailed Protocol Operation information in Section 8, WSDL information 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: Boulton & Barnes Expires July 3, 2006 [Page 3] Internet-Draft CCMP December 2005 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. 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. Boulton & Barnes Expires July 3, 2006 [Page 4] Internet-Draft CCMP December 2005 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 XCON 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 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 Boulton & Barnes Expires July 3, 2006 [Page 5] Internet-Draft CCMP December 2005 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 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. Boulton & Barnes Expires July 3, 2006 [Page 6] Internet-Draft CCMP December 2005 [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. Boulton & Barnes Expires July 3, 2006 [Page 7] Internet-Draft CCMP December 2005 ........................................................ . 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 Boulton & Barnes Expires July 3, 2006 [Page 8] Internet-Draft CCMP December 2005 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 Boulton & Barnes Expires July 3, 2006 [Page 9] Internet-Draft CCMP December 2005 fundamental XCON data model that is agreed.] Boulton & Barnes Expires July 3, 2006 [Page 10] Internet-Draft CCMP December 2005 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. Boulton & Barnes Expires July 3, 2006 [Page 11] Internet-Draft CCMP December 2005 Boulton & Barnes Expires July 3, 2006 [Page 12] Internet-Draft CCMP December 2005 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. Boulton & Barnes Expires July 3, 2006 [Page 13] Internet-Draft CCMP December 2005 [4] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003. [5] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC 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-02 (work in progress), October 2005. [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 (CCCP)", draft-levin-xcon-cccp-03 (work in progress), October 2005. [9] Novo, O., "A Common Conference Information Data Model for Centralized Conferencing (XCON)", draft-novo-xcon-common-data-model-00 (work in progress), September 2005. Boulton & Barnes Expires July 3, 2006 [Page 14] Internet-Draft CCMP December 2005 Authors' Addresses Chris Boulton Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Mary Barnes Nortel 2380 Performance Drive Richardson, TX Email: mary.barnes@nortel.com Boulton & Barnes Expires July 3, 2006 [Page 15] Internet-Draft CCMP December 2005 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 (2005). 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. Boulton & Barnes Expires July 3, 2006 [Page 16]