XCON                                                            O. Levin
Internet-Draft                                     Microsoft Corporation
Expires: August 24, 2005                                         R. Even
                                                                 Polycom
                                                            P. Hagendorf
                                                               RADVISION
                                                       February 20, 2005


                   Centralized Conference Data Model
                        draft-levin-xcon-cccp-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is a part of a suite of protocols being developed in
   the XCON Working Group and defines a client-server Centralized
   Conferencing Control Protocol (CCCP) for query, creation, and



Levin, et al.            Expires August 24, 2005                [Page 1]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   manipulation of both the XCON system information (e.g.  supported
   templates) and a particular conference information during the
   conference lifetime cycle (e.g.  reservation and state).  An XCON
   server, which implements a CCCP server, provides the means for
   authorized CCCP clients (e.g.  conference participants) to affect the
   behavior of a conference in the XCON system.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  General  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Transaction Model and Operations . . . . . . . . . . . . . . .  5
   5.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Primitives . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1   System Primitives  . . . . . . . . . . . . . . . . . . . .  7
       6.1.1   getTemplates . . . . . . . . . . . . . . . . . . . . .  7
       6.1.2   getReservedConferences . . . . . . . . . . . . . . . .  7
       6.1.3   getActiveConferences . . . . . . . . . . . . . . . . .  7
     6.2   Conference Primitives  . . . . . . . . . . . . . . . . . .  7
       6.2.1   addConference  . . . . . . . . . . . . . . . . . . . .  7
       6.2.2   getConference  . . . . . . . . . . . . . . . . . . . .  7
       6.2.3   deleteConference . . . . . . . . . . . . . . . . . . .  7
     6.3   User Primitives  . . . . . . . . . . . . . . . . . . . . .  7
       6.3.1   addUser  . . . . . . . . . . . . . . . . . . . . . . .  7
       6.3.2   getUser  . . . . . . . . . . . . . . . . . . . . . . .  8
       6.3.3   deleteUser . . . . . . . . . . . . . . . . . . . . . .  8
     6.4   Endpoint Primitives  . . . . . . . . . . . . . . . . . . .  8
       6.4.1   addEndpoint  . . . . . . . . . . . . . . . . . . . . .  8
       6.4.2   getEndpoint  . . . . . . . . . . . . . . . . . . . . .  8
       6.4.3   deleteEndpoint . . . . . . . . . . . . . . . . . . . .  8
     6.5   Media Primitives . . . . . . . . . . . . . . . . . . . . .  8
       6.5.1   addMedia . . . . . . . . . . . . . . . . . . . . . . .  8
       6.5.2   getMedia . . . . . . . . . . . . . . . . . . . . . . .  8
       6.5.3   deleteMedia  . . . . . . . . . . . . . . . . . . . . .  9
       6.5.4   modifyMediaStatus  . . . . . . . . . . . . . . . . . .  9
     6.6   Stimulus Primitives  . . . . . . . . . . . . . . . . . . .  9
   7.  The XML  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1   Request  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.2   Response . . . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 26
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
     12.1  Normative References . . . . . . . . . . . . . . . . . . . 26
     12.2  Informative References . . . . . . . . . . . . . . . . . . 27
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27



Levin, et al.            Expires August 24, 2005                [Page 2]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


       Intellectual Property and Copyright Statements . . . . . . . . 28


















































Levin, et al.            Expires August 24, 2005                [Page 3]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


1.  Introduction

   General centralized conferencing architecture is described in the
   SIPPING Conference Framework [3].  The XCON Framework [4] defines how
   this architecture can be realized by an XCON compliant system.  The
   XCON framework defines the concepts of the conference policy and the
   conference information as the top data objects for representing a
   conference.

   This document is a part of a suite of protocols being developed in
   the XCON Working Group and defines a client-server Centralized
   Conferencing Control Protocol (CCCP) for query, creation, and
   manipulation of both the XCON system information (e.g.  supported
   templates) and a particular conference information during the
   conference lifetime cycle (e.g.  reservation and state).  An XCON
   server, which implements a CCCP server, provides the means for
   authorized CCCP clients (e.g.  conference participants) to affect the
   behavior of a conference in the XCON system.

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

3.  General

   CCCP can be used to modify any of the conference information objects
   defined in the XCON Framework document [5].  These include the
   conference template, reservation, and state.  Whenever reasonable,
   same CCCP primitives are used to access conference information during
   different stages of the conference life cycle.  In order to
   distinguish between reservation and possible multiple instances of
   the same conference different URIs are used for each.

   Editor's Note: URI conventions or parameters TBD in the XCON
   Framework [4].

   CCCP uses the conference information schema type and its sub-types
   (as defined in the SIPPING Conference Package [2]) for construction
   of the CCCP data objects.  It is expected that additional sub-types
   will be introduced by XCON in order to express extended conferencing
   information relevant to XCON-compliant systems.






Levin, et al.            Expires August 24, 2005                [Page 4]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


4.  Transaction Model and Operations

   CCCP MUST run over a reliable transport protocol.

   CCCP is agnostic to the details of the transport protocol being used
   beneath and does not rely on any information being conveyed on the
   transport level.

   CCCP is a transaction client-server protocol.  Two types of
   operations are defined with CCCP : request and response.

   A client issues requests to a server.  The server MAY reply with
   multiple provisional responses before replying with the final
   response.  Currently a single provisional response "pending" is
   defined.

   Editor's Note: Timeout behavior TBD.

   The server MUST reply with a single final response.  Two final
   responses are defined: "failure" and "success".

   The following reasons for failure are defined:

   serverBusy with optional retryAfter
   timeout performing operation
   unauthorized
   requestMalformed
   requestTooLarge

   Each CCCP response and each CCCP request carries the following
   attributes: 'requestId', 'from', and 'to'.

   The combination of the 'requestId', 'from' and 'to' attributes in the
   request and in the response constitutes the CCCP transaction ID:

   requestId: A string generated by the CCCP client and unique for each
      CCCP request generated by the client.
   from: A URI which identifies the CCCP client.
   to: A URI which identifies the CCCP server.

   Note that 'to' is mandatory but is not used in order to uniquely
   identify a particular transaction.

   Multiple primitives can be included in a single CCCP operation (i.e.
   in a request and a corresponding response).  The primitives within
   the request operation MUST be performed by the CCCP server one-by-one
   in the order they appear in the request body.  The corresponding
   response operation MUST include the response primitive for each of



Levin, et al.            Expires August 24, 2005                [Page 5]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   the issued primitives in the exact same order.  Note, that for this
   reason, the primitives inside the operation bodies are not numbered.

   Multiple primitives within the same request MUST be executed as an
   atomic operation.  It means that if one primitive fails, the state of
   the object MUST be rolled back to its previous state, i.e.  before
   the request had been processed.

5.  Data Model

   The CCCP operations can be issued on the conference template,
   conference reservation, and any of the conference instance data
   objects.  All these data objects are expressed in terms of
   conference-info-type defined in SIPPING Conference Package [2].
   Consequently, CCCP requests are expressed using the same
   conference-info type and its sub-types whenever it makes sense.  The
   information included in the request expresses the desired data object
   state to be achieved after the operation is successfully completed.

   The considerations listed below MUST be taken into account when using
   the schema with CCCP.

   Attributes 'state' and 'version' of the conference-info-type and its
   sub-types are never used with CCCP.

   The primitives' definition allows for inclusion of any element
   defined by the conference-info-type and its sub-types.  Note that it
   is optional to include these elements by both the client and the
   server and their processing is optional by the receiving side, unless
   explicitly stated otherwise in the normative description of the CCCP
   primitives in Section 6.

   For example, when adding or creating objects (e.g.  a conference, a
   user, an endpoint, a media, etc.) the client MUST include only the
   information that is required for the object creation.  The client
   MUST assume that the Server MAY return new dynamically generated
   information in a successful response.

   On the other hand, the Server MAY return minimum information in the
   response or even an empty element corresponding to a successful
   request.  CCCP allows the inclusion of richer information that can be
   displayed to a user or be logged in by the system, but doesn't
   mandate to always include this information in the response.

6.  Primitives






Levin, et al.            Expires August 24, 2005                [Page 6]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


6.1  System Primitives

6.1.1  getTemplates

   Get the list of template identifiers supported by the system.

   XML TBD.

6.1.2  getReservedConferences

   Get the list of reservation identifiers allocated by the system.

   XML TBD.

6.1.3  getActiveConferences

   Get the list of conference identifiers of active instances running in
   the system.

   XML TBD.

6.2  Conference Primitives

6.2.1  addConference

   Create a conference.  The conference can be a new conference
   "blueprint", new reservation, or a new ad-hoc instance.

   For XML definition see Section 7.

   The 'conferenceEntity' value in the request is a client's suggestion
   only.  The CCCP server can replace the suggested value with a
   different 'conferenceEntity' value in the corresponding response.

6.2.2  getConference

   For XML definition see Section 7.

6.2.3  deleteConference

   For XML definition see Section 7.

6.3  User Primitives

6.3.1  addUser

   For XML definition see Section 7.




Levin, et al.            Expires August 24, 2005                [Page 7]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   The Client MUST provide the 'userEntity' value in the request.  If
   the client doesn't care (and/or) doesn't know the 'endpointEntity'
   value, it must populate it with the value equal to the 'userEntity'.
   The client MUST expect to receive in the successful response a real
   value of the 'endpointEntity'.

6.3.2  getUser

   For XML definition see Section 7.

6.3.3  deleteUser

   For XML definition see Section 7.

6.4  Endpoint Primitives

6.4.1  addEndpoint

   For XML definition see Section 7.

   The Client MUST provide a valid 'endpointEntity' value in the
   request.

6.4.2  getEndpoint

   For XML definition see Section 7.

6.4.3  deleteEndpoint

   For XML definition see Section 7.

6.5  Media Primitives

6.5.1  addMedia

   The 'mediaId' value in the request is ignored by the CCCP server.
   The CCCP server MUST replace the value with the real 'media-id' value
   in the corresponding response.

6.5.2  getMedia

   This operation is used to get the description of a media stream of a
   participant in the conference.

   For XML definition see Section 7.






Levin, et al.            Expires August 24, 2005                [Page 8]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


6.5.3  deleteMedia

   This operation is used to remove a media stream from a participant in
   the conference.

   For XML definition see Section 7.

6.5.4  modifyMediaStatus

   This operation can be used for muting and un-muting media streams.

   For XML definition see Section 7.

6.6  Stimulus Primitives

   This operation is used to convey opaque pre-defined requests from a
   CCCP client to a CCCP server.

   XML TBD.

7.  The XML

   <?xml version="1.0" encoding="UTF-8" ?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:cccp" xmlns:tns="urn:ietf:params:xml:ns:cccp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:cccp" elementFormDefault="qualified" attributeFormDefault="unqualified">
   <!--
          This import brings in the XML language attribute xml:lang
   -->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" />

   <!--
   	CONFERENCE REQUEST ELEMENT
   -->
   	<xs:element name="request" type="request-type"/>
   	<!--
   	CONFERENCE RESPONSE ELEMENT
   -->
   	<xs:element name="response" type="response-type"/>

   	<!--
   	CONFERENCE REQUEST TYPE
   -->
   	<xs:complexType name="request-type">
   		<xs:sequence maxOccurs="unbounded">
   			<xs:choice>
   				<xs:element name="getMcu" type="get-mcu-type"/>
   				<xs:element name="addConference" type="add-conference-type"/>
   				<xs:element name="getConference" type="get-conference-type"/>
   				<xs:element name="deleteConference" type="delete-conference-type"/>



Levin, et al.            Expires August 24, 2005                [Page 9]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   				<xs:element name="addUser" type="add-user-type"/>
   				<xs:element name="modifyUser" type="add-user-type"/>
   				<xs:element name="getUser" type="get-user-type"/>
   				<xs:element name="deleteUser" type="delete-user-type"/>
   				<xs:element name="addEndpoint" type="add-endpoint-type"/>
   				<xs:element name="getEndpoint" type="get-endpoint-type"/>
   				<xs:element name="deleteEndpoint" type="delete-endpoint-type"/>
   				<xs:element name="addMedia" type="add-media-type"/>
   				<xs:element name="modifyMedia" type="add-media-type"/>
   				<xs:element name="getMedia" type="get-media-type"/>
   				<xs:element name="deleteMedia" type="delete-media-type"/>
   				<xs:element name="modifyMediaStatus" type="modify-media-status-type"/>
   				<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   			</xs:choice>
   		</xs:sequence>
   		<xs:attribute name="requestId" type="xs:string"/>
   		<xs:attribute name="from" type="xs:anyURI"/>
   		<xs:attribute name="to" type="xs:anyURI"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  CONFERENCE RESPONSE TYPE
   	-->
   	<xs:complexType name="response-type">
   		<xs:sequence maxOccurs="unbounded">
   			<xs:choice>
   				<xs:element name="getMcu" type="get-mcu-response-type"/>
   				<xs:element name="addConference" type="add-conference-response-type"/>
   				<xs:element name="getConference" type="get-conference-response-type"/>
   				<xs:element name="deleteConference" type="delete-conference-response-type"/>
   				<xs:element name="addUser" type="add-user-response-type"/>
   				<xs:element name="modifyUser" type="add-user-response-type"/>
   				<xs:element name="getUser" type="get-user-response-type"/>
   				<xs:element name="deleteUser" type="delete-user-response-type"/>
   				<xs:element name="addEndpoint" type="add-endpoint-response-type"/>
   				<xs:element name="getEndpoint" type="get-endpoint-response-type"/>
   				<xs:element name="deleteEndpoint" type="delete-endpoint-response-type"/>
   				<xs:element name="addMedia" type="add-media-response-type"/>
   				<xs:element name="modifyMedia" type="add-media-response-type"/>
   				<xs:element name="getMedia" type="get-media-response-type"/>
   				<xs:element name="deleteMedia" type="delete-media-response-type"/>
   				<xs:element name="modifyMediaStatus" type="modify-media-status-response-type"/>
   				<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   			</xs:choice>
   		</xs:sequence>
   		<xs:attribute name="requestId" type="xs:string"/>
   		<xs:attribute name="from" type="xs:anyURI"/>
   		<xs:attribute name="to" type="xs:anyURI"/>



Levin, et al.            Expires August 24, 2005               [Page 10]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   		<xs:attribute name="code" type="response-code-type"/>
   		<xs:attribute name="reason" type="reason-code-type" use="optional"/>
   		<xs:attribute name="displayString" type="xs:string" use="optional"/>
   		<xs:attribute name="timeOut" type="xs:nonNegativeInteger" use="optional"/>
   		<xs:attribute name="retryAfter" type="xs:nonNegativeInteger" use="optional"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	RESPONSE CODE TYPE
   	-->
   	<xs:simpleType name="response-code-type">
   		<xs:restriction base="xs:string">
   			<xs:enumeration value="success"/>
   			<xs:enumeration value="pending"/>
   			<xs:enumeration value="failure"/>
   		</xs:restriction>
   	</xs:simpleType>

   	<!--
   	REASON CODE TYPE
   	-->
   	<xs:simpleType name="reason-code-type">
   		<xs:restriction base="xs:string">
   			<xs:enumeration value="serverBusy"/>
   			<xs:enumeration value="timeout"/>
   			<xs:enumeration value="unauthorized"/>
   			<xs:enumeration value="requestMalformed"/>
   			<xs:enumeration value="requestTooLarge"/>
   			<xs:enumeration value="other"/>
   		</xs:restriction>
   	</xs:simpleType>
   	<!--
   	  CONFERENCE KEYS TYPE
   	-->
   	<xs:complexType name="conference-keys-type">
   		<xs:attribute name="confEntity" type="xs:anyURI"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  USER KEYS TYPE
   	-->
   	<xs:complexType name="user-keys-type">
   		<xs:attribute name="confEntity" type="xs:anyURI"/>
   		<xs:attribute name="userEntity" type="xs:anyURI"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ENDPOINT KEYS TYPE



Levin, et al.            Expires August 24, 2005               [Page 11]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   	-->
   	<xs:complexType name="endpoint-keys-type">
   		<xs:attribute name="confEntity" type="xs:anyURI"/>
   		<xs:attribute name="userEntity" type="xs:anyURI"/>
   		<xs:attribute name="endpointEntity" type="xs:anyURI"/>
   		 <xs:attribute name="callId" type="xs:string" use="optional"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  MEDIA KEYS TYPE
   	-->
   	<xs:complexType name="media-keys-type">
   		<xs:attribute name="confEntity" type="xs:anyURI"/>
   		<xs:attribute name="userEntity" type="xs:anyURI"/>
   		<xs:attribute name="endpointEntity" type="xs:anyURI"/>
   		<xs:attribute name="callId" type="xs:string" use="optional"/>
   		<xs:attribute name="mediaId" type="xs:string"/>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET MCU TYPE
   	-->
   	<xs:complexType name="get-mcu-type">
   		<xs:sequence>
   			<xs:element name="conference" type="conference-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET MCU RESPONSE TYPE
   	-->
   	<xs:complexType name="get-mcu-response-type">
   		<xs:sequence>
   			<xs:element name="mcu" type="xs:anyURI" maxOccurs="unbounded"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>

   	<!--
   	  ADD CONFERENCE TYPE
   	-->
   	<xs:complexType name="add-conference-type">
   		<xs:sequence>
   			<xs:element name="conference" type="conference-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>



Levin, et al.            Expires August 24, 2005               [Page 12]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD CONFERENCE RESPONSE TYPE
   	-->
   	<xs:complexType name="add-conference-response-type">
   		<xs:sequence>
   			<xs:element name="conference" type="conference-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET CONFERENCE TYPE
   	-->
   	<xs:complexType name="get-conference-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET CONFERENCE RESPONSE TYPE
   	-->
   	<xs:complexType name="get-conference-response-type">
   		<xs:sequence>
   			<xs:element name="conference" type="conference-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE CONFERENCE TYPE
   	-->
   	<xs:complexType name="delete-conference-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE CONFERENCE RESPONSE TYPE
   	-->
   	<xs:complexType name="delete-conference-response-type">
   		<xs:sequence>
   			<xs:element name="conference" type="conference-type" minOccurs="0"/>



Levin, et al.            Expires August 24, 2005               [Page 13]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD USER TYPE
   	-->
   	<xs:complexType name="add-user-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type"/>
   			<xs:element name="user" type="user-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD USER RESPONSE TYPE
   	-->
   	<xs:complexType name="add-user-response-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
   			<xs:element name="user" type="user-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET USER TYPE
   	-->
   	<xs:complexType name="get-user-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET USER RESPONSE TYPE
   	-->
   	<xs:complexType name="get-user-response-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
   			<xs:element name="user" type="user-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--



Levin, et al.            Expires August 24, 2005               [Page 14]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   	  DELETE USER TYPE
   	-->
   	<xs:complexType name="delete-user-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE USER RESPONSE TYPE
   	-->
   	<xs:complexType name="delete-user-response-type">
   		<xs:sequence>
   			<xs:element name="conferenceKeys" type="conference-keys-type" minOccurs="0"/>
   			<xs:element name="user" type="user-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD ENDPOINT TYPE
   	-->
   	<xs:complexType name="add-endpoint-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type"/>
   			<xs:element name="endpoint" type="endpoint-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD ENDPOINT RESPONSE TYPE
   	-->
   	<xs:complexType name="add-endpoint-response-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
   			<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET ENDPOINT TYPE
   	-->
   	<xs:complexType name="get-endpoint-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type"/>



Levin, et al.            Expires August 24, 2005               [Page 15]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET ENDPOINT RESPONSE TYPE
   	-->
   	<xs:complexType name="get-endpoint-response-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
   			<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE ENDPOINT TYPE
   	-->
   	<xs:complexType name="delete-endpoint-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE ENDPOINT RESPONSE TYPE
   	-->
   	<xs:complexType name="delete-endpoint-response-type">
   		<xs:sequence>
   			<xs:element name="userKeys" type="user-keys-type" minOccurs="0"/>
   			<xs:element name="endpoint" type="endpoint-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  ADD MEDIA TYPE
   	-->
   	<xs:complexType name="add-media-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type"/>
   			<xs:element name="media" type="media-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--



Levin, et al.            Expires August 24, 2005               [Page 16]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   	  ADD MEDIA RESPONSE TYPE
   	-->
   	<xs:complexType name="add-media-response-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
   			<xs:element name="media" type="media-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET MEDIA TYPE
   	-->
   	<xs:complexType name="get-media-type">
   		<xs:sequence>
   			<xs:element name="mediaKeys" type="media-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  GET MEDIA RESPONSE TYPE
   	-->
   	<xs:complexType name="get-media-response-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
   			<xs:element name="media" type="media-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE MEDIA TYPE
   	-->
   	<xs:complexType name="delete-media-type">
   		<xs:sequence>
   			<xs:element name="mediaKeys" type="media-keys-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  DELETE MEDIA RESPONSE TYPE
   	-->
   	<xs:complexType name="delete-media-response-type">
   		<xs:sequence>
   			<xs:element name="endpointKeys" type="endpoint-keys-type" minOccurs="0"/>
   			<xs:element name="media" type="media-type" minOccurs="0"/>



Levin, et al.            Expires August 24, 2005               [Page 17]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>

   	<!--
   	  MODIFY MEDIA STATUS TYPE
   	-->
   	<xs:complexType name="modify-media-status-type">
   		<xs:sequence>
   			<xs:element name="mediaKeys" type="media-keys-type"/>
   			<xs:element name="mediaStatus" type="media-status-type"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>
   	<!--
   	  MODIFY MEDIA STATUS RESPONSE TYPE
   	-->
   	<xs:complexType name="modify-media-status-response-type">
   		<xs:sequence>
   			<xs:element name="mediaKeys" type="media-keys-type" minOccurs="0"/>
   			<xs:element name="mediaStatus" type="media-status-type" minOccurs="0"/>
   			<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   		</xs:sequence>
   		<xs:anyAttribute namespace="##other"/>
   	</xs:complexType>


8.  Example

   In order to illustrate the CCCP syntax, the example below shows all
   possible primitives issued in a single request and the corresponding
   answers are included in a single response.  In this case all the
   primitives are executed as a single atomic operation.

   Editor's Note: In the next version of this document the example will
   be split into separate operations with clear semantics for each.

8.1  Request


   <request requestId="1" from="sip:someone@example.com" to="conf1@mcu.example.com" aaId="ANBDSJ">
   <getMcu>
      <conference entity="sip:conf233@example.com">
      <!--
   	CONFERENCE INFO
      -->



Levin, et al.            Expires August 24, 2005               [Page 18]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   	<conference-description>
   		<maximum-user-count>
   			<entry role="any">
   					<count>100</count>
   			</entry>
   		</maximum-user-count>
   		<available-media>
   			<entry id="1">
   				<type>audio</type>
   			</entry>
   			<entry id="2">
   				<type>video</type>
   			</entry>
   		</available-media>
   	</conference-description>
    </conference>
    </getMcu>

   <addConference>
      <conference entity="sip:conf233@example.com">
      <!--
   	CONFERENCE INFO
      -->
   	<conference-description>
   		<subject>Agenda: This month's goals</subject>
   		<conf-uris>
   			<entry>
   				<uri>tel:+18005671234</uri>
   				<display-text>TTI Bridge</display-text>
   			</entry>
   		</conf-uris>
   		<service-uris>
   			<entry>
   				<uri>http://sharepoint/salesgroup/</uri>
   				<purpose>web-page</purpose>
   			</entry>
   		</service-uris>
   		<maximum-user-count>
   			<entry role="any">
   					<count>52</count>
   			</entry>
   			<entry role="participant">
   					<count>50</count>
   			</entry>
   		</maximum-user-count>
   		<available-media>
   			<entry id="1">
   				<display-text>main audio</display-text>



Levin, et al.            Expires August 24, 2005               [Page 19]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   				<type>audio</type>
   			</entry>
   			<entry id="2">
   				<display-text>main video</display-text>
   				<type>video</type>
   			</entry>
   		</available-media>
   	</conference-description>
    </conference>
     </addConference>

   <getConference>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
    </getConference>

    <deleteConference>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
    </deleteConference>

    <addUser>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
     	<user entity="sip:bob@example.com">
   			<display-text>Bob Hoskins</display-text>
   	<!--
   	  ENDPOINTS
   	-->
   		<endpoint entity="sip:bob@pc4.example.com">
   			<display-text>Bob's Laptop</display-text>
   			<joining-method>dialed-out</joining-method>

   	<!--
   	  MEDIA
   	-->
   			<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   			</media>
   		</endpoint>
   	</user>
     </addUser>

     <modifyUser>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
     	<user entity="sip:bob@example.com">
   			<roles>
   			<entry>participant</entry>
   			</roles>
   	</user>



Levin, et al.            Expires August 24, 2005               [Page 20]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


     </modifyUser>

   <getUser>
      <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
    </getUser>

    <deleteUser>
      <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
    </deleteUser>

    <addEndpoint>
      <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
     		<endpoint entity="sip:bob@pc4.example.com">
   			<display-text>Bob's Laptop</display-text>
   			<joining-method>dialed-out</joining-method>

   	<!--
   	  MEDIA
   	-->
   			<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   			</media>
   		</endpoint>
   </addEndpoint>

   <getEndpoint>
      <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    </getEndpoint>

    <deleteEndpoint>
       <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    </deleteEndpoint>

    <addMedia>
      <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
     			<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   			</media>
    </addMedia>

    <!--
   	  MODIFY MEDIA
   	-->
   <modifyMedia>
    <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
     			<media id="1">



Levin, et al.            Expires August 24, 2005               [Page 21]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   				<status>recvonly</status>
   			</media>
     </modifyMedia>

   <getMedia>
      <mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
    </getMedia>

    <deleteMedia>
       <mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
    </deleteMedia>

   	<!--
   	  MODIFY MEDIA STATUS
   	-->
   <modifyMediaStatus>
      <mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
   	<mediaStatus>recvonly</mediaStatus>
     </modifyMediaStatus>

   </request>


8.2  Response


   <response requestId="1" from="sip:someone@example.com" to="conf1@mcu.example.com" aaId="ANBDSJ" code="success">
   <addConference>
      <conference entity="sip:conf233@example.com">
      <!--
   	CONFERENCE INFO
      -->
   	<conference-description>
   		<subject>Agenda: This month's goals</subject>
   		<conf-uris>
   			<entry>
   				<uri>tel:+18005671234</uri>
   				<display-text>TTI Bridge</display-text>
   			</entry>
   		</conf-uris>
   		<service-uris>
   			<entry>
   				<uri>http://sharepoint/salesgroup/</uri>
   				<purpose>web-page</purpose>
   			</entry>
   		</service-uris>
   		<maximum-user-count>
   			<entry role="any">



Levin, et al.            Expires August 24, 2005               [Page 22]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   				 <count>52</count>
   			</entry>
   			<entry role="participant">
   				<count>50</count>
   			</entry>
   		</maximum-user-count>
   		<available-media>
   			<entry id="1">
   				<type>audio</type>
   			</entry>
   			<entry id="2">
   				<type>video</type>
   			</entry>
   		</available-media>
   	</conference-description>
    </conference>
     </addConference>

     <getConference>
         <conference entity="sip:conf233@example.com">
      <!--
   	CONFERENCE INFO
      -->
   	<conference-description>
   		<subject>Agenda: This month's goals</subject>
   		<conf-uris>
   			<entry>
   				<uri>tel:+18005671234</uri>
   				<display-text>TTI Bridge</display-text>
   			</entry>
   		</conf-uris>
   		<service-uris>
   			<entry>
   				<uri>http://sharepoint/salesgroup/</uri>
   				<purpose>web-page</purpose>
   			</entry>
   		</service-uris>
   		<maximum-user-count>
   			<entry role="any">
   				<count>52</count>
   			</entry>
   			<entry role="participant">
   				<count>50</count>
   			</entry>
   		</maximum-user-count>
   		<available-media>
   			<entry id="1">
   				<type>audio</type>



Levin, et al.            Expires August 24, 2005               [Page 23]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


   			</entry>
   			<entry id="2">
   				<type>video</type>
   			</entry>
   		</available-media>
   	</conference-description>
    </conference>
    </getConference>

    <deleteConference>
      <conference entity="sip:conf233@example.com"/>
    </deleteConference>

    <addUser>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
     	<user entity="sip:bob@example.com"></user>
     </addUser>

     <ModifyUser>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
     	<user entity="sip:bob@example.com"></user>
     </ModifyUser>

   <getUser>
      <conferenceKeys confEntity="sip:conf233@example.com"/>
      <user entity="sip:bob@example.com">
   			<display-text>Bob Hoskins</display-text>
   	<!--
   	  ENDPOINTS
   	-->
   		<endpoint entity="sip:bob@pc4.example.com">
   			<display-text>Bob's Laptop</display-text>
   			<joining-method>dialed-out</joining-method>

   	<!--
   	  MEDIA
   	-->
   			<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   			</media>
   		</endpoint>
   	</user>
    </getUser>

    <deleteUser>
       <conferenceKeys confEntity="sip:conf233@example.com"/>
     	<user entity="sip:bob@example.com"></user>



Levin, et al.            Expires August 24, 2005               [Page 24]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


    </deleteUser>

    <addEndpoint>
       <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
     	<endpoint entity="sip:bob@pc4.example.com"></endpoint>
     </addEndpoint>

   <getEndpoint>
       <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
   		<endpoint entity="sip:bob@pc4.example.com">
   			<display-text>Bob's Laptop</display-text>
   			<joining-method>dialed-out</joining-method>

   	<!--
   	  MEDIA
   	-->
   			<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   			</media>
   		</endpoint>
    </getEndpoint>

    <deleteEndpoint>
        <userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>
     	<endpoint entity="sip:bob@pc4example.com"></endpoint>
    </deleteEndpoint>

    <addMedia>
       <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    	<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   	</media>
     </addMedia>

     <ModifyMedia>
       <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    	<media id="1"> </media>
     </ModifyMedia>

   <getMedia>
      <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    	<media id="1">
   			<display-text>main audio</display-text>
   			<type>audio</type>
   	</media>
    </getMedia>



Levin, et al.            Expires August 24, 2005               [Page 25]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


    <deleteMedia>
       <endpointKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com"/>
    	<media id="1">
   				<display-text>main audio</display-text>
   				<type>audio</type>
   	</media>
    </deleteMedia>

   	<!--
   	  MODIFY MEDIA STATUS RESPONSE
   	-->
   <modifyMediaStatus>
      <mediaKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com" endpointEntity="sip:bob@pc33.example.com" mediaId="1"/>
   	<mediaStatus>recvonly</mediaStatus>
     </modifyMediaStatus>


   </response>



9.  IANA Considerations

   TBD.

10.  Security Considerations

   TBD.

11.  Acknowledgements

   The author would like to thank Gur Kimchi for his earlier work that
   served as the starting point for this specification.

12.  References

12.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
        Package for Conference State",
        Internet-Draft draft-ietf-sipping-conference-package-08,
        December 2004.






Levin, et al.            Expires August 24, 2005               [Page 26]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 2005


12.2  Informative References

   [3]  Rosenberg, J., "A Framework for Conferencing with the Session
        Initiation Protocol",
        Internet-Draft draft-ietf-sipping-conferencing-framework-03,
        October 2004.

   [4]  Barnes, M. and C. Boulton, "A Framework and Data Model for
        Centralized Conferencing",
        Internet-Draft draft-barnes-xcon-framework-02, February 2005.


Authors' Addresses

   Orit Levin
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: oritl@microsoft.com


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva,   49130
   Israel

   Email: roni.even@polycom.co.il


   Pierre Hagendorf
   RADVISION
   24, Raul Wallenberg St.
   Tel-Aviv,   69719
   Israel

   Email: pierre@radvision.com












Levin, et al.            Expires August 24, 2005               [Page 27]


Internet-Draft    Centralized Conference Control Protocol (CCCP)          February 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.




Levin, et al.            Expires August 24, 2005               [Page 28]