XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Intended status: Standards Track                              C. Boulton
Expires: May 22, 2008                                              Avaya
                                                          H. Schulzrinne
                                                     Columbia University
                                                       November 19, 2007


             Centralized Conferencing Manipulation Protocol
                       draft-barnes-xcon-ccmp-03

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 May 22, 2008.

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 May 22, 2008                  [Page 1]


Internet-Draft                    CCMP                     November 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.  Conference Object, Users and Identifiers . . . . . . . . . . .  7
     6.1.  Conference Object  . . . . . . . . . . . . . . . . . . . .  7
     6.2.  Conference Users and Participants  . . . . . . . . . . . .  7
   7.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Options  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.2.  Retrieve . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.3.  Create . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.4.  Change . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.5.  Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Protocol Operations on Conference Objects  . . . . . . . . . . 11
     8.1.  Identifying a Conference Instance  . . . . . . . . . . . . 11
     8.2.  Constructing a CCMP request  . . . . . . . . . . . . . . . 11
     8.3.  Handling Responses and Error Conditions  . . . . . . . . . 12
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10. Transaction Model  . . . . . . . . . . . . . . . . . . . . . . 15
   11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   12. WSDL Definition  . . . . . . . . . . . . . . . . . . . . . . . 17
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     16.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22













Barnes, et al.            Expires May 22, 2008                  [Page 2]


Internet-Draft                    CCMP                     November 2007


1.  Introduction

   The Framework for Centralized Conferencing defines a signaling-
   agnostic framework, naming conventions and logical entities required
   for constructing advanced conferencing systems.  A primary concept
   introduced in the framework and 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, 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 XCON framework , while clients can
   either be signaling end points, such as Session Initiation Protocol
   (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) [4] and [5] 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 the
   Conference Package [10] and the XCON data model.  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 7, with a discussion of the
   key elements in the conference object in Section 6.  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 May 22, 2008                  [Page 3]


Internet-Draft                    CCMP                     November 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 for
   Centralized Conferencing and High-Level Requirements for Tightly
   Coupled SIP Conferencing [8].  In addition, the following acronyms
   and terms are used in this document:

   SOAP:  Simple Object Access Protocol.[4][5]
   WSDL:  Web Services Description Language.[3] 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 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).

   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,



Barnes, et al.            Expires May 22, 2008                  [Page 4]


Internet-Draft                    CCMP                     November 2007


   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 7.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 for centralized conferencing .  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 May 22, 2008                  [Page 5]


Internet-Draft                    CCMP                     November 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 May 22, 2008                  [Page 6]


Internet-Draft                    CCMP                     November 2007


   centralized conferencing document and related documents.


6.  Conference Object, Users and Identifiers

   This section provides an overview of the conference object and
   conference users in relation to the CCMP protocol.  The identifiers
   used in CCMP for the conference object (XCON_URI) and conference user
   (XCON_USERID) are introduced in the XCON framework and defined in the
   XCON data model.

6.1.  Conference Object

   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.

   The schema for the conference object is defined in the XCON data
   model.  Conference objects are uniquely identified by the XCON_URI.
   A client MAY add a parent element that indicates the parent from
   which the conference is to inherit values.  When creating
   conferences, the XCON_URI included by the client is only a
   suggestion.  To avoid identifier collisions and to conform to local
   server policy, the conference control server MAY choose a different
   identifier.

6.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.  The Conference
   Control Server creates individual users, assigning them a unique
   Conference User Identifier (XCON_URI).

   A variety of elements defined in the common conference information as
   specified in the XCON data model. are used to determine how a
   specific user expects and is allowed to join a conference as
   participants, or users with specific privileges (e.g., observer).
   For example, the <method> attribute in the defines how the caller
   joins the conference, with a set of defined XML elements, namely



Barnes, et al.            Expires May 22, 2008                  [Page 7]


Internet-Draft                    CCMP                     November 2007


   <dial-in> for users that are allowed to dial in and <dial-out> for
   users that the conference focus will be trying to reach,
   etc.<dial-in> is the default.

   If the conference is currently active, dial-out users are contacted
   immediately; otherwise, they are contacted at the start of the
   conference.  The conference control server assigns a unique
   Conference User Identifier (XCON_USERID) to each user.  The
   conference control server uses the XCON_USERID to change or delete
   <user> elements.  Depending upon policies and privileges, specific
   users MAY also manipulate <user> elements.

   In many conferences, users dial in if they know the XCON_URI and an
   access code shared by all conference participants.  This user is
   initially represented in the data by a <user> element without an
   entity attribute.  Only the (default) type of <dial-in> is permitted
   for this type of user.  The users are identified, in the entity
   attribute, by their call signaling URL, such as their SIP URL, tel
   URI [7] , etc.  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 conference
   control server assigns a unique Conference User Identifier
   (XCON_USERID) to these users when they dial in to join the
   conference.  If the user supports the notification event package
   [11], they can receive their XCON_USERID, thus allowing them to also
   manipulate the <user> attribute in the conference object.


7.  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 core protocol operations on conference
   objects.  Each object has four basic operations: retrieve, create,
   change and delete.  The XCON_URI as discussed in Section 6.1 is the
   target for each of these operations.

   To simplify operations, a conference control server treats certain
   parameters as suggestions, as noted in the object description.  If
   the conference control 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.

   There is also a querying mechanism ("options") to ascertain the
   namespaces understood by the server, thus any elements with
   namespaces not understood by the server are to be ignored by the



Barnes, et al.            Expires May 22, 2008                  [Page 8]


Internet-Draft                    CCMP                     November 2007


   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.

7.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 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 the XCON framework.  The blueprints are comprised of
   common conference information initialized to specific values and
   ranges.

7.2.  Retrieve

   The "retrieve" operation returns the full XML document describing the
   conference 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 "retrieve" 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 "retrieve" operation is also used
   to get 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 (XCON_URI) be
   provided by the client.

   To simplify operations HTTP GET 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.

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



Barnes, et al.            Expires May 22, 2008                  [Page 9]


Internet-Draft                    CCMP                     November 2007


   The default conference object is specific to a conferencing system
   and its specification is outside the scope of this document.

   When creating conferences, any XCON_URI included by the client is
   considered as input.  To avoid identifier collisions and to conform
   to local server policy, the conference control server MAY choose a
   different identifier.  The identifier is returned in the response.

   In addition, the conference description MAY contain a calendar
   element, in the iCal format in XML rendition defined in CPL [6] or
   (preferable, if available as stable reference) xCal [12].  This
   description indicates when the conference is active.  The conference
   server may only offer a subset of the dates, indicated by the 203
   response.

   The "create" operation may also be used to create a new conference
   user.  The response to this operation includes the XCON_USERID.

   To simplify operations HTTP PUT can also be used to create a new
   objects.

7.4.  Change

   The "change" operation updates the conference object as referenced by
   the XCON_URI included in the.  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, to manipulate specific elements
   in the conference object, along with relevant operation types (add,
   delete, modify, etc.).

   Upon receipt of a "change" operation, the conference control serve
   updates the specific elements in the referenced conference object.
   Object properties that are not explicitly changed, remain as-is.
   This approach allows a conference control client to manipulate
   objects created by another application even if the manipulating
   application does not understand all object properties.  [Editor's
   note: the mechanism for manipulation of specific elements in the
   conference object requires further detail.]

   To simplify operations HTTP POST can also be used to change objects.






Barnes, et al.            Expires May 22, 2008                 [Page 10]


Internet-Draft                    CCMP                     November 2007


7.5.  Delete

   This conference control operation is used to delete the current
   representation of a conference object and requires the unique
   conference identifier (XCON_URI) be provided by the client.

   A request which attempts to delete a conference object that is being
   referenced by a child object is an error.


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

   Typically, for any operation that is to be carried out on a
   conference object, the XCON_URI is required.

   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 is 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 7, depending
   upon the function and associated information desired by the
   conference control client.

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







Barnes, et al.            Expires May 22, 2008                 [Page 11]


Internet-Draft                    CCMP                     November 2007


8.3.  Handling Responses and Error Conditions

   Error conditions specific to individual operations 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.  [Editor's Note: Alternatively, should we define
   XML tokens for errors rather than following this SIP/HTTP model? ]







































Barnes, et al.            Expires May 22, 2008                 [Page 12]


Internet-Draft                    CCMP                     November 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 2: Response Codes


9.  Examples

   The examples below omits the standard SOAP header and wrappers, i.e.,
   the part below is simply the <body> 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 May 22, 2008                 [Page 13]


Internet-Draft                    CCMP                     November 2007


   decision as to whether it will honor those requests.

      <method>create</method>

      <object>
        <conference-info
          xmlns="urn:ietf:params:xml:ns:conference-info"
          version="1">
          <conference-description>
           <parent>http://example.com/conf200</parent>
           <subject>Agenda: This month's goals</subject>
           <conf-uris>
             <entry>
               <uri>sips:conf223@example.com</uri>
               <purpose>participation</purpose>
             </entry>
           </conf-uris>
           <service-uris>
             <entry>
              <uri>http://sharep/salesgroup/</uri>
              <purpose>web-page</purpose>
             </entry>
             <entry>
              <uri>http://example.com/conf233</uri>
              <purpose>control</purpose>
             </entry>
            </service-uris>
           </conference-description>
        </conference>
      </object>


                     Figure 3: Create Request 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.

      <result>
        <status>200</status>
        <reason>OK</status>
      </result>
      <response>
      [... modified conference description ...]
      </response>


                     Figure 4: Create Response Example



Barnes, et al.            Expires May 22, 2008                 [Page 14]


Internet-Draft                    CCMP                     November 2007


   The request below adds a user to the conference identified by the
   conference URI.


      <method conference="http://example.com/conf233">create</method>
      <user entity="sip:bob@example.com">
       <roles>receiving</roles>
       <type><dial-out/></type>
      </user>


                        Figure 5: Add User Example


10.  Transaction Model

   The transaction model for CCMP complies fully with SOAP version 1.2
   as defined by W3C in [4] and [5].


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



   <?xml version="1.0" encoding="utf-8" ?>
   <xs:schema
       targetNamespace="urn:ietf:params:xml:ns:ccmp"
       xmlns:tns="urn:ietf:params:xml:ns:ccmp"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"

       <!-- CONF-CTL-REQUEST-TYPE element -->
       <xs:element name="request" type="tns:conf-ctl-request-type"/>

        <!-- CONF-CTL-RESPONSE-TYPE element-->
       <xs:element name="response" type="tns:conf-ctl-response-type"/>

       <!-- CONF-CTL-REQUEST-TYPE definition-->
       <xs:complexType name="conf-ctl-request-type">
           <xs:sequence maxOccurs="unbounded">
               <xs:choice>
                   <xs:element name="options"
                    type="tns:options-type"/>
                   <xs:element name="retrieve"
                    type="tns:retrieve-type"/>



Barnes, et al.            Expires May 22, 2008                 [Page 15]


Internet-Draft                    CCMP                     November 2007


                   <xs:element name="create"
                    type="tns:create-type"/
                    <xs:element name="change"
                    type="tns:change-type"/>
                   <xs:element name="delete"
                    type="tns:delete-type"/>
                   <xs:any namespace="##other" processContents="lax"
                    minOccurs="0"
                    maxOccurs="unbounded"/>
               </xs:choice>
           </xs:sequence>
           <xs:attribute name="requestId"
            type="xs:string" use="required"/>
           <!--  The  URI of the conference control client sending the request -->
           <xs:attribute name="from" type="xs:anyURI" use="required"/>
           <!--The URI of the conference control server the request is being sent to -->
           <xs:attribute name="to" type="xs:anyURI" use="required"/>

       </xs:complexType>


      <!-- CONF-CTL-RESPONSE-TYPE definition -->
       <xs:complexType name="conf-ctl-response-type">
           <xs:sequence minOccurs="0" maxOccurs="unbounded">
               <xs:choice>
                   <xs:element name="optionsResponse"
                    type="tns:options-response-type"/>
                   <xs:element name="retrieveResponse"
                    type="tns:retrieve-response-type"/>
                   <xs:element name="createResponse"
                    type="tns:create-response-type"/
                    <xs:element name="changeResponse"
                    type="tns:change-type"/>
                   <xs:element name="deleteResponse"
                    type="tns:delete-response-type"/>
                   <xs:any namespace="##other" processContents="lax"
                    minOccurs="0"
                    maxOccurs="unbounded"/>
               </xs:choice>
           </xs:sequence>
           <xs:attribute name="requestId"
            type="xs:string" use="required"/>

           <!--The URI of the conference control server that processed the original request
               and is sending the response -->
           <xs:attribute name="from" type="xs:anyURI" use="required"/>
           <!--  The  URI of the conference control client that initiated the original
                request and is receiving the response -->



Barnes, et al.            Expires May 22, 2008                 [Page 16]


Internet-Draft                    CCMP                     November 2007


           <xs:attribute name="to" type="xs:anyURI" use="required"/>

           <xs:attribute name="responseCode"
            type="tns:response-code-type" use="required"/>

           <xs:anyAttribute namespace="##other" processContents="lax"/>
       </xs:complexType>

       <!-- Response code Type -->
         <xs:simpleType name="code-type">
           <xs:restriction base="xs:nonNegativeInteger">
           <xs:pattern value="[0-5][0-9][0-9]"/>
           </xs:restriction>
         </xs:simpleType>

         <xs:complexType name="response-code-type">
           <xs:complexContent>
             <xs:restriction base="xs:anyType">
               <xs:sequence/>
                 <xs:attribute name="code" type="ccmp:code-type"
                      use="required"/>
                 <xs:attribute name="reasonPhrase" type="xs:token"
                      use="optional"/>
             </xs:restriction>
           </xs:complexContent>
         </xs:complexType>


       <!--Yes, there's lots more to do here!!!! -->

    </xs:schema>


                                 Figure 6


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.


<?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/"



Barnes, et al.            Expires May 22, 2008                 [Page 17]


Internet-Draft                    CCMP                     November 2007


     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:cccp="urn:ietf:params:xml:ns:ccp"
     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:ccmp"
        schemaLocation="ccmp.xsd"/>

     <message name="CCMPRequestMessage">
       <part name="body" element="ccmp:request"/>
     </message>
     <message name="CCMPReponseMessage">
       <part name="body" element="ccmp: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="ccpSoapBinding" 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:ccpSoapBinding" name="CCMPPortType">
        <wsdlsoap:address location="http://www.example.com"/>
       </wsdl:port>
     </wsdl:service>



Barnes, et al.            Expires May 22, 2008                 [Page 18]


Internet-Draft                    CCMP                     November 2007


   </definitions>


                                 Figure 7


13.  IANA Considerations

   TODO


14.  Security Considerations

   Access to conference control functionality needs to be tightly
   controlled to keep attackers from disrupting conferences, adding
   themselves to conferences or engaging in theft of services.
   Implementors need 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).


15.  Acknowledgments

   The authors appreciate the feedback provided by Simon Pietro Romano
   and Dave Morgan.


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]   Gudgin, M., Moreau, J., Mendelsohn, N., Hadley, M., and H.
         Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World
         Wide Web Consortium FirstEdition REC-soap12-part1-20030624,
         June 2003,
         <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.



Barnes, et al.            Expires May 22, 2008                 [Page 19]


Internet-Draft                    CCMP                     November 2007


   [5]   Mendelsohn, N., Gudgin, M., Hadley, M., Nielsen, H., and J.
         Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
         Consortium FirstEdition REC-soap12-part2-20030624, June 2003,
         <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.

16.2.  Informative References

   [6]   Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
         Language (CPL): A Language for User Control of Internet
         Telephony Services", RFC 3880, October 2004.

   [7]   Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [8]   Levin, O. and R. Even, "High-Level Requirements for Tightly
         Coupled SIP Conferencing", RFC 4245, November 2005.

   [9]   Levin, O. and G. Camarillo, "The Session Description Protocol
         (SDP) Label Attribute", RFC 4574, August 2006.

   [10]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
         Initiation Protocol (SIP) Event Package for Conference State",
         RFC 4575, August 2006.

   [11]  Srinivasan, S. and R. Even, "Conference event package data
         format extension for centralized  conferencing",
         draft-srinivasan-xcon-eventpkg-extensions-02 (work in
         progress), August 2007.

   [12]  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










Barnes, et al.            Expires May 22, 2008                 [Page 20]


Internet-Draft                    CCMP                     November 2007


   Chris Boulton
   Avaya
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@avaya.com


   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 May 22, 2008                 [Page 21]


Internet-Draft                    CCMP                     November 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 May 22, 2008                 [Page 22]