One document matched: draft-barnes-xcon-ccmp-03.txt
Differences from draft-barnes-xcon-ccmp-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:46:41 |