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 © 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 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
2.  Conventions and Terminology
3.  Overview of Operation
4.  System Architecture
5.  Transaction Model
6.  Protocol Operations
    6.1.  Create Conference Object
    6.2.  Manipulate Conference Object
    6.3.  Delete Conference Object
    6.4.  Query Conference Object
7.  XML Schema
8.  WSDL Definition
9.  Examples
10.  IANA Considerations
11.  Security Considerations
12.  Acknowledgments
13.  References
    13.1.  Normative References
    13.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Introduction

The XCON Framework Document[2] (Barnes, M., “A Framework and Data Model for Centralized Conferencing,” October 2005.) 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] (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Conference State,” July 2005.) and 'A Common Conference Information Data Model for Centralized Conferencing' (Novo, O., “A Common Conference Information Data Model for Centralized Conferencing (XCON),” September 2005.) [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 (Overview of Operation) and Section 4 (System Architecture). It is also provides detailed Protocol Operation information in Section 6 (Protocol Operations), WSDL information in Section 8 (WSDL Definition) and some Example interactions in Section 9 (Examples).

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.

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] (Barnes, M., “A Framework and Data Model for Centralized Conferencing,” October 2005.) 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 (WSDL Definition). 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] (Barnes, M., “A Framework and Data Model for Centralized Conferencing,” October 2005.))

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 (Protocol Operations).

[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] (Barnes, M., “A Framework and Data Model for Centralized Conferencing,” October 2005.). Figure 1 (Conference Client Interaction) 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.

........................................................
.  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                                 .
........................................................

CCMP is represented in Figure 1 (Conference Client Interaction) by (1). Conference Control functionality provides one component required by an XCON compliant client.

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 (WSDL Definition) 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] (Levin, O., “Centralized Conference Control Protocol (CCCP),” October 2005.). 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.

<?xml version="1.0" encoding="UTF-8"?>
   <definitions name="CCMP"
     xmlns="http://schemas.xmlsoap.org/wsdl/"
     xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
     xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:cccp="urn:ietf:params:xml:ns:cccp"
     xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
     xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
     xmlns:tns="urn:ietf:params:xml:ns:ccmp"
     targetNamespace="urn:ietf:params:xml:ns:ccmp:proto">

     <xs:import
        namespace="urn:ietf:params:xml:ns:cccp"
        schemaLocation="cccp.xsd"/>

     <message name="CCMPRequestMessage">
       <part name="body" element="cccp:request"/>
     </message>
     <message name="CCMPReponseMessage">
       <part name="body" element="cccp:response"/>
     </message>

     <wsdl:portType name="CCMPPortType">
       <wsdl:operation name="confOperation" parameterOrder="body">
         <wsdl:input message="tns:CCMPRequestMessage"/>
         <wsdl:output message="tns:CCMPResponseMessage"/>
       </wsdl:operation>
     </wsdl:portType>

     <wsdl:binding name="cccpSoapBinding" type="tns:CCMPPortType">
         <wsdlsoap:binding style="rpc"
           transport="http://schemas.xmlsoap.org/soap/http"/>
         <wsdl:operation name="confOperation">
            <wsdlsoap:operation soapAction=""/>
            <wsdl:input>
               <wsdlsoap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               use="encoded"/>
            </wsdl:input>
            <wsdl:output>
               <wsdlsoap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               use="encoded"/>
            </wsdl:output>
         </wsdl:operation>
     </wsdl:binding>

     <wsdl:service name="CCMP">
       <wsdl:port binding="tns:cccpSoapBinding" name="CCMPPortType">
        <wsdlsoap:address location="http://www.example.com"/>
       </wsdl:port>
     </wsdl:service>

   </definitions>

9. Examples

TODO

10. IANA Considerations

TODO

11. Security Considerations

TODO

12. Acknowledgments

13. References

13.1. Normative References

13.2. Informative References

Authors' Addresses

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 © 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.