One document matched: draft-barnes-xcon-ccmp-02.txt
Differences from draft-barnes-xcon-ccmp-01.txt
XCON Working Group M. Barnes
Internet-Draft Nortel
Expires: August 9, 2007 C. Boulton
Ubiquity Software Corporation
H. Schulzrinne
Columbia University
February 5, 2007
Centralized Conferencing Manipulation Protocol
draft-barnes-xcon-ccmp-02
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 August 9, 2007.
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 August 9, 2007 [Page 1]
Internet-Draft CCMP February 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. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Conference Objects . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Conference Object Definition . . . . . . . . . . . . . . . 9
7.2. Conference Users and Participants . . . . . . . . . . . . 10
7.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Media Groups . . . . . . . . . . . . . . . . . . . . . . . 12
8. Protocol Operations on Conference Objects . . . . . . . . . . 12
8.1. Identifying a Conference Instance . . . . . . . . . . . . 12
8.2. Constructing a CCMP request . . . . . . . . . . . . . . . 13
8.3. Sending a CCMP Request . . . . . . . . . . . . . . . . . . 13
8.4. Handling Responses and Error Conditions . . . . . . . . . 13
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 16
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 18
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Barnes, et al. Expires August 9, 2007 [Page 2]
Internet-Draft CCMP February 2007
1. Introduction
The Framework and Data Model for Centralized Conferencing [6] defines
a signaling agnostic data model, naming conventions and logical
entities required for constructing advanced conferencing systems. A
primary concept introduced in the framework and data model for
centralized conferencing is the existence of a conference object.
The conference object is a logical representation of a conference
instance, which represents the current state and capabilities of a
conference.
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 and
privileges, 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 framework [6], while clients can either
be signaling end points, such as 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) 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 Conference
Package [11] and 'A Common Conference Information Data Model for
Centralized Conferencing' [12]. 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 6, with a discussion of the
key elements in the conference object in Section 7. 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 August 9, 2007 [Page 3]
Internet-Draft CCMP February 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 and
Data Model for Centralized Conferencing [6] and High-Level
Requirements for Tightly Coupled SIP Conferencing [9]. In addition,
the following acronyms and terms are used in this document:
SOAP: Simple Object Access Protocol.
WSDL: Web Services Description Language. WSDL is an XML format for
describing network services as a set of endpoints operating on
messages containing either document-oriented or procedure-oriented
information.
W3C: World Wide Web Consortium. The organization that developed the
SOAP and WSDL specifications referenced within this document.
4. Motivation
SOAP is chosen as the RPC mechanism due to its compatibility with the
requirements for the conference control protocol as introduced in the
framework and data model for centralized conferencing. SOAP is a
lightweight protocol for exchange of information in a decentralized,
distributed environment. It is an XML based protocol that consists
of three parts: an envelope that defines a framework for describing
what is in a message and how to process it, a set of encoding rules
for expressing instances of application-defined datatypes, and a
convention for representing remote procedure calls and responses.
SOAP 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).
SOAP can be used with a variety of transport protocols. For the
purposes of its role in providing the basis for the conference
control protocol, HTTP is the chosen transport. The advantages of
the use of SOAP as the basis for the conference control protocol are
deemed to be the re-use of existing standards, the ease of software
development, the availability of tools, and the ease of integration
with deployed systems.
Barnes, et al. Expires August 9, 2007 [Page 4]
Internet-Draft CCMP February 2007
WSDL is an XML format for describing network services as a set of
endpoints operating on messages containing either document-oriented
or procedure-oriented information. The operations and messages are
described abstractly, and then bound to a concrete network protocol
and message format to define an endpoint. Related concrete endpoints
are combined into abstract endpoints (services). WSDL is extensible
to allow description of endpoints and their messages regardless of
what message formats or network protocols are used to communicate,
however, the only bindings described in this document describe how to
use WSDL in conjunction with SOAP.
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 6.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 and data model for centralized
conferencing [6]. Figure 1 depicts a subset of the 'Conferencing
System Logical Decomposition' architecture from the framework and
data model for centralized conferencing document. It illustrates the
role that CCMP assumes within the overall centralized architecture.
Barnes, et al. Expires August 9, 2007 [Page 5]
Internet-Draft CCMP February 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 August 9, 2007 [Page 6]
Internet-Draft CCMP February 2007
centralized conferencing document and related documents.
6. 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 four core operations on conference
objects. These operations should operate in the same manner for new
objects that might be defined later. There is also a querying
mechanism to ascertain the namespaces understood by the server, thus
any elements with namespaces not understood by the server are to be
ignored by the 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.
6.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 or
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 [6]. The blueprints are comprised
of common conference information initialized to specific values and
ranges. [TBD: Should this also be made available via an HTTP OPTIONS
request?]
6.2. Get
The "get" operation returns the full XML document describing the
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 "get" 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 "get" operation is also used to retrieve 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 be provided by
Barnes, et al. Expires August 9, 2007 [Page 7]
Internet-Draft CCMP February 2007
the client as defined by [13]
To simplify operations, the HTTP/SOAP "get" method 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.
6.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.
The default conference object is specific to a conferencing system
and its specification is outside the scope of this document.
The "create" operation may also be used to create a new conference
user.
To simplify operations, the HTTP/SOAP PUT can also be used to create
a new objects.
6.4. Change
The "change" operation updates the object identified. 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 along with relevant operation
types (add, delete, modify, etc.).
To simplify operations, the HTTP/SOAP POST can also be used to change
objects.
6.5. Delete
This conference control operation is used to delete the current
representation of a conference object and requires the unique
conference identifier be provided by the client, as as defined by
[13]. A request which attempts to delete a conference object that is
being referenced by a child object is an error.
Barnes, et al. Expires August 9, 2007 [Page 8]
Internet-Draft CCMP February 2007
7. Conference Objects
This section describes some of the key elements in the conference
object manipulated by the conference control protocol. Conference
objects are referenced by unique identifiers as defined in [6] and
[13]
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.
Each object has four basic operations: create, change, delete and
get, as described in Section 6. Object properties that are not
explicitly replaced, remain as-is. This approach makes it possible
to manipulate objects created by another application even if the
manipulating application does not understand all object properties.
To simplify operations, a server treats certain parameters as
suggestions, as noted in the object description. If the 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.
7.1. Conference Object Definition
Conferences use the conference object as defined by the schema in
[12]. A client MAY add a parent element that indicates the parent
from which the conference is to inherit values. When creating
conferences, the conference URIs are only suggestions by the client.
To avoid identifier collisions and to conform to local server policy,
the server MAY choose different identifiers. These identifiers are
returned in the response.
In addition, the conference description MAY contain a calendar
element, in the iCal format in XML rendition defined in CPL [7] or
(preferable, if available as stable reference) xCal [15]. This
description indicates when the conference is active. As discussed
above, the conference server may be only offer a subset of the dates,
indicated by the 203 response.
Barnes, et al. Expires August 9, 2007 [Page 9]
Internet-Draft CCMP February 2007
7.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.
A variety of elements defined in the common conference information as
specified in [12] are used to determine how a specific user expects
and is allowed to join a conference. Many of the attributes are
based on those defined in Section 5.6.4 of [11], such as the
<language> element. The <type> element defines how the caller is to
be reached, with a set of defined XML elements, namely <dial-in> for
users that are allowed to dial in and <dial-out> for users that the
conference focus will be trying to reach. If the conference is
currently active, dial-out users are contacted immediately;
otherwise, they are contacted at the start of the conference.
<dial-in> is the default.
In many conferences, users dial in if they know the conference URI
and an access code shared by all conference participants. We
represent this user by a <user> element without entity attribute.
Only the (default) type of <dial-in>is permitted for this type of
user. The Conference Control Server then creates individual users as
users dial in, identified, in the entity attribute, by their call
signaling URL, such as their SIP URL, tel URI [8] or similar. 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 system uses the entity identifier or access code to change or
delete user elements.
Three examples for user elements are shown below; the second user
element is a dial-in user with access code and only listen
capability, while the other access code allows full participant
access.
Barnes, et al. Expires August 9, 2007 [Page 10]
Internet-Draft CCMP February 2007
<user entity="sip:alice@example.com">
<roles>moderator sending receiving</roles>
<languages>en</languages>
<type><dial-in/></type>
<media>
<mediagroup status="sendonly">questions</mediagroup>
<mediagroup status="recvonly">lecture</mediagroup>
</media>
</user>
<user access-code="12345">
<roles>passiveParticipant</roles>
</user>
<user access-code="23456">
<roles>activeParticipant</roles>
</user>
Figure 2: User Element Examples
7.3. Roles
While the conference package allows the association of a role with
each user, it does not offer a mechanism to define those roles. This
document provides an initial mechanism to associate roles with a set
of associated permitted activities, i.e., rights. An empty list
designates no permissions. The set of rights is defined by the
<privileges-control-list> in [12]
Roles cannot be changed by normal users and are likely to be media-
specific. Thus, we use the concept of media groups instead. In
addition, there is a media permission list for each role, identified
by the media bus or label per Section 7.4
Active participants can always subscribe to conference events and see
their own status.
It is expected that the conference roles are defined in conference
documents that are then inherited by most locally-defined conferences
so that conferences would typically not have to define new roles.
<role id="moderator">
<rights>getUsers moderator addUser</rights>
</role>
Barnes, et al. Expires August 9, 2007 [Page 11]
Internet-Draft CCMP February 2007
Figure 3: Role Example
7.4. Media Groups
The concept of a media bus/floor describes all the media sources that
are controlled together and mixed together. If the conference has
floor control such as via BFCP, read and write permission are
governed by the floor control protocol. If not, the static
configuration modified via CCMP can be used to control read and write
access to media groups. SDP labels [11]are used to identify media
streams.
In addition to the name, the media group may also designate rendering
properties of the floor. Initially, we designate the grid (e.g.,
4x4) for video streams and how many squares the active speaker
occupies. For audio streams, the stereo position is expressed as a
number from -1 (leftmost) to +1 (rightmost). Additional properties
can be added later by extensions from additional namespaces.
<mediagroup label="lecture">
<media>
<audio max-bandwidth="100">pcmu l16 dvi</audio>
<video max-bandwidth="200" picture="3x3"
speaker="4">mjpeg</video>
</media>
</mediagroup>
Figure 4: Media Group Example
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
For any operation that is to be carried out on an existing conference
object, a unique identifier is required. The framework and data
model for centralized conferencing [6] defines a conference object
identifier with the details provided in [13].
Barnes, et al. Expires August 9, 2007 [Page 12]
Internet-Draft CCMP February 2007
Operations can be initiated from a conference control client for the
purpose of creating a conference object. To achieve this, an
operation is executed without specifying a unique conference object
identifier. If the operation is successful, the unique conference
object identifier be included in the SOAP response transaction.
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 6, depending
upon the function and associated information desired by the
conference control client.
8.3. Sending a CCMP Request
A constructed CCMP message that is compliant to the SOAP WSDL is then
ready to be executed using appropriate protocol operations as
described in Section 6.
[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. ].
8.4. Handling Responses and Error Conditions
Specific error conditions 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.
Barnes, et al. Expires August 9, 2007 [Page 13]
Internet-Draft CCMP February 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 5: 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 August 9, 2007 [Page 14]
Internet-Draft CCMP February 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 6: Create 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 7: Create Response
Barnes, et al. Expires August 9, 2007 [Page 15]
Internet-Draft CCMP February 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 8: Add User Example
10. Transaction Model
The transaction model for CCMP complies fully with SOAP version 1.2
as defined by W3C in [ref].
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:ccp"
xmlns:tns="urn:ietf:params:xml:ns:ccp"
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="get"
type="tns:get-type"/>
Barnes, et al. Expires August 9, 2007 [Page 16]
Internet-Draft CCMP February 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="getResponse"
type="tns:get-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 -->
<xs:attribute name="to" type="xs:anyURI" use="required"/>
Barnes, et al. Expires August 9, 2007 [Page 17]
Internet-Draft CCMP February 2007
<xs:attribute name="responseCode"
type="tns:response-code-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--Yes, there's lots more to do here!!!! -->
</xs:schema>
Figure 9
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/"
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:ccp"
schemaLocation="ccp.xsd"/>
<message name="CCMPRequestMessage">
<part name="body" element="ccp:request"/>
</message>
<message name="CCMPReponseMessage">
<part name="body" element="ccp:response"/>
</message>
<wsdl:portType name="CCMPPortType">
<wsdl:operation name="confOperation" parameterOrder="body">
<wsdl:input message="tns:CCMPRequestMessage"/>
<wsdl:output message="tns:CCMPResponseMessage"/>
Barnes, et al. Expires August 9, 2007 [Page 18]
Internet-Draft CCMP February 2007
</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>
</definitions>
Figure 10
13. IANA Considerations
TODO
14. Security Considerations
Access to conference control functionality needs to be tightly
controlled to avoid attackers disrupting conferences, adding
themselves to conferences or engaging in theft of services.
Implementors needs 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).
Barnes, et al. Expires August 9, 2007 [Page 19]
Internet-Draft CCMP February 2007
15. Acknowledgments
This document incorporates Henning's original "COMP: Conference
Object Manipulation Protocol" proposal.
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] Moreau, J., Gudgin, M., Nielsen, H., Hadley, M., and N.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium Recommendation REC-soap12-part1-
20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[5] Hadley, M., Mendelsohn, N., Moreau, J., Gudgin, M., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
Consortium Recommendation REC-soap12-part2-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
16.2. Informative References
[6] Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-07 (work in progress),
January 2007.
[7] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004.
[8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[9] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
Barnes, et al. Expires August 9, 2007 [Page 20]
Internet-Draft CCMP February 2007
[10] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006.
[11] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[12] Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-03 (work in progress),
October 2006.
[13] Boulton, C. and M. Barnes, "A Universal Resource Identifier
(URI) for Centralized Conferencing (XCON)",
draft-boulton-xcon-uri-00 (work in progress), October 2006.
[14] Boulton, C. and M. Barnes, "A User Identifier for Centralized
Conferencing (XCON)", draft-boulton-xcon-userid-00 (work in
progress), October 2006.
[15] 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
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com
Barnes, et al. Expires August 9, 2007 [Page 21]
Internet-Draft CCMP February 2007
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 August 9, 2007 [Page 22]
Internet-Draft CCMP February 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 August 9, 2007 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 01:40:52 |