XCON Working Group C. Boulton Internet-Draft Ubiquity Software Corporation Expires: April 30, 2006 H. Schulzrinne Columbia University O. Levin Microsoft Corporation M. Barnes Nortel October 27, 2005 Centralized Conference Manipulation Protocol draft-schulzrinne-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 April 30, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A Conference, as defined by the Centralized Conferencing Working Group (XCON) in the IETF, requires client side protocol interactions for creation, deletion, manipulation and querying of Conference Boulton, et al. Expires April 30, 2006 [Page 1] Internet-Draft CCMP October 2005 state. The Centralized Conference Manipulation Protocol (CCMP) defined in this document provides the appropriate mechanisms for achieving the previously stated objectives. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 4. System Architecture . . . . . . . . . . . . . . . . . . . . . 5 5. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 7 6.1. Create Conference Object . . . . . . . . . . . . . . . . . 7 6.2. Manipulate Conference Object . . . . . . . . . . . . . . . 7 6.3. Delete Conference Object . . . . . . . . . . . . . . . . . 7 6.4. Query Conference Object . . . . . . . . . . . . . . . . . 7 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 7 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Boulton, et al. Expires April 30, 2006 [Page 2] Internet-Draft CCMP October 2005 1. Introduction The XCON Framework Document[2] provides a signaling agnostic data model, naming conventions and logical entities required for constructing advanced conferencing systems. The XCON Conference Framework's primary concept is the existence of a Conference Object. The Conference Object is a logical representation of a Conference Instance (as defined in the XCON Conference Framework) which represents the current state and capabilities of a Conference. It is the purpose of this document to allow the manipulation of an XCON 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 [3] and 'A Common Conference Information Data Model for Centralized Conferencing' [5]. These data structures will be used as the basis for the WSDL definition and XML schema. The document comprises of details relating to general Overview and System Architecture in Section 3 and Section 4. It is also provides detailed Protocol Operation information in Section 6, WSDL information in Section 8 and some Example interactions in Section 9. 2. Conventions and Terminology 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. SOAP: TODO. WSDL: TODO. W3C: TODO. 3. 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 will be used as the the XML RPC mechanism to fulfill such operations. Boulton, et al. Expires April 30, 2006 [Page 3] Internet-Draft CCMP October 2005 A Conference Control Client wishing to carry out operations on a particular Conference Object will follow the steps below: Identify Conference Instance: For any operation that is to be carried out on an existing Conference Object, a unique identifier will be required. The Conference Framework[2] 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 will be included in the SOAP response transaction. [Editors Note: More detail to be provided. Again, need to discuss inclusion of XCON conference identifier] Construct CCMP request: The construction of the SOAP envelope associated with a Conference Control request message will comply fully with the WSDL, as defined in Section 8. It is expected that constructing a valid Conference Control message will incorporate the following alternatives:- Create Conference Object (Explicitly): The Conference Control Operation can explicitly specify the Common Conference Part and Templates (as specified in [2]) Create Conference Object (Implicitly): The Conference Control Operation can construct a create request that does not contain a Conference Object. This will result in the creation of an instance of the default Conference Object specified for the Conference System (which is implementation specific). Manipulate a Conference Object: During the lifetime of a Conference, a Conference Control Client will be able to manipulate a Conference Object. This will include the ability to pass relevant fragments of the Conference Object along with relevant operation types (add, delete, modify). Get a Conference Object: It will be possible, using the unique Conference Identifier (discussed earlier), to retrieve the current representation of a Conference Object. Delete a Conference Object: It will be possible, using the unique Conference Identifier (discussed earlier), to delete the current representation of a Conference Object. Send CCMP request to Conference System: 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 6. Boulton, et al. Expires April 30, 2006 [Page 4] Internet-Draft CCMP October 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. It will likely make use of transaction identifiers contained in CCCP]. 4. System Architecture CCMP has been written in full accordance with the XCON Conference Framework document[2]. Figure 1 depicts a subset of the 'Conferencing System Logical Decomposition' architecture from the Conference Framework document. It illustrates the role that CCMP will assume in the overall XCON architecture. Boulton, et al. Expires April 30, 2006 [Page 5] Internet-Draft CCMP October 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 | . . +-------------------+ . . ^ . .........................|.............................. | |(1)Conference |Control |Protocol | | .........................|.............................. . V . . +----------------+ . . | Conference | . . | Control | . . | Client | . . +----------------+ . . . . Conferencing Client . ........................................................ Figure 1: Conference Client Interaction CCMP is represented in Figure 1 by (1). Conference Control functionality provides one component required by an XCON compliant client. Boulton, et al. Expires April 30, 2006 [Page 6] Internet-Draft CCMP October 2005 5. Transaction Model The transaction model for CCMP complies fully with SOAP version 1.2 as defined by W3C in [ref]. 6. Protocol Operations This section provides descriptive text for the basic protocol operations for CCMP. An XCON compliant 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 8 which uses HTTP operations as the transport mechanism. The following list provides more detail on specific protocol operations: 6.1. Create Conference Object TODO - describe use in conjunction with HTTP POST. 6.2. Manipulate Conference Object TODO - describe use in conjunction with HTTP POST. 6.3. Delete Conference Object TODO - describe use in conjunction with HTTP POST. 6.4. Query Conference Object TODO - describe use in conjunction with HTTP GET. 7. XML Schema Current proposal is to use the schema definition in CCCP[4]. If discussion agrees then this will be included in the next version of this document. 8. WSDL Definition This version of the document assumes that the CCCP schema us used. Boulton, et al. Expires April 30, 2006 [Page 8] Internet-Draft CCMP October 2005 Figure 2 9. Examples TODO 10. IANA Considerations TODO 11. Security Considerations TODO 12. Acknowledgments 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 13.2. Informative References [2] Barnes, M., "A Framework and Data Model for Centralized Conferencing", draft-ietf-xcon-framework-02 (work in progress), October 2005. [3] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-12 (work in progress), July 2005. [4] Levin, O., "Centralized Conference Control Protocol (CCCP)", draft-levin-xcon-cccp-03 (work in progress), October 2005. Boulton, et al. Expires April 30, 2006 [Page 9] Internet-Draft CCMP October 2005 [5] 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, et al. Expires April 30, 2006 [Page 10] Internet-Draft CCMP October 2005 Authors' Addresses Chris Boulton Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027, US Email: hgs@cs.columbia.edu Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: oritl@microsoft.com Mary Barnes Nortel 2380 Performance Drive Richardson, TX Email: mary.barnes@nortel.com Boulton, et al. Expires April 30, 2006 [Page 11] Internet-Draft CCMP October 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, et al. Expires April 30, 2006 [Page 12]