draft-ietf-xcon-ccmp-00.txt   draft-ietf-xcon-ccmp-01.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: December 18, 2008 Avaya Expires: May 7, 2009 Avaya
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
June 16, 2008 November 3, 2008
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-00 draft-ietf-xcon-ccmp-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2008. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) defined in The Centralized Conferencing Manipulation Protocol (CCMP) can create,
this document provides the mechanisms to create, change and delete retrieve, change and delete objects describing a centralized
objects related to centralized conferences, including participants, conference, such as state and capabilities of the conference,
their media and their roles. The protocol relies on web services as participants, and their roles. The conference information is
its infrastructure, but can control conferences that use any contained in XML documents and fragments conforming to the
signaling protocol to invite users. CCMP is based on the Simple centralized conferencing data model schema. CCMP is a state-less
Object Access Protocol (SOAP), with the data necessary for the client-server protocol based on a request/response model.
interactions specified via Web Services Description Language (WSDL).
Conferencing clients send requests to conference servers, which
respond to the client with the conference information.
This document also discusses options for using existing notification
protocols to inform conference client about the changes in the state
of a conference during its entire lifetime.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Rationale and Motivation . . . . . . . . . . . . . . . . . . . 5
5. System Architecture . . . . . . . . . . . . . . . . . . . . . 6 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 7
6. Conference Object and User Identifiers . . . . . . . . . . . . 8 6. Conference Object and User Identifiers . . . . . . . . . . . . 9
6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 8 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 9
6.2. Conference Users and Participants . . . . . . . . . . . . 8 6.2. Conference Users and Participants . . . . . . . . . . . . 9
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Protocol Operations on Conference Objects . . . . . . . . . . 12 8. Protocol Operations on Conference Objects . . . . . . . . . . 13
8.1. Locating a Conference Control Server . . . . . . . . . . . 13 8.1. Locating a Conference Control Server . . . . . . . . . . . 14
8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 13 8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 15
8.2.1. Options Request . . . . . . . . . . . . . . . . . . . 13 8.2.1. blueprintsRequest . . . . . . . . . . . . . . . . . . 16
8.2.2. Operations Requests . . . . . . . . . . . . . . . . . 14 8.2.2. confsRequest . . . . . . . . . . . . . . . . . . . . . 16
8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 15 8.2.3. Operations Requests . . . . . . . . . . . . . . . . . 16
8.3.1. Options Response . . . . . . . . . . . . . . . . . . . 16 8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 18
8.3.2. Operation Responses . . . . . . . . . . . . . . . . . 16 8.3.1. blueprintsResponse . . . . . . . . . . . . . . . . . . 20
9. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 8.3.2. confsResponse . . . . . . . . . . . . . . . . . . . . 20
9.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 20 8.3.3. Operation Responses . . . . . . . . . . . . . . . . . 21
9.2. Request ID Parameter . . . . . . . . . . . . . . . . . . . 20 9. Managing sidebars . . . . . . . . . . . . . . . . . . . . . . 25
9.3. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 20 9.1. Sidebars by value . . . . . . . . . . . . . . . . . . . . 25
9.4. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 20 9.2. Sidebars by reference . . . . . . . . . . . . . . . . . . 26
9.5. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 21 10. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 26
9.6. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 21 10.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 26
9.7. Conference-info Parameter . . . . . . . . . . . . . . . . 21 10.2. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 26
9.8. User Parameter . . . . . . . . . . . . . . . . . . . . . . 22 10.3. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 27
9.9. Users Parameter . . . . . . . . . . . . . . . . . . . . . 22 10.4. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 27
9.10. Sidebar Parameters . . . . . . . . . . . . . . . . . . . . 23 10.5. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 28
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.6. Conference-info Parameter . . . . . . . . . . . . . . . . 28
10.1. Creating a New Conference . . . . . . . . . . . . . . . . 23 10.7. User Parameter . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Creating a New Conference User . . . . . . . . . . . . . . 26 10.8. Users Parameter . . . . . . . . . . . . . . . . . . . . . 29
10.3. Adding a User to a Conference . . . . . . . . . . . . . . 26 10.9. Sidebar Parameters . . . . . . . . . . . . . . . . . . . . 29
11. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 28 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. HTTP methods for realizing a RESTful CCMP . . . . . . . . 30
13. WSDL Definition . . . . . . . . . . . . . . . . . . . . . . . 33 11.2. CCMP Detailed Message Body Examples . . . . . . . . . . . 33
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11.2.1. Creating a New Conference . . . . . . . . . . . . . . 33
14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 34 11.2.2. Creating a New Conference User . . . . . . . . . . . . 36
14.2. XML Schema Registration . . . . . . . . . . . . . . . . . 35 11.2.3. Adding a User to a Conference . . . . . . . . . . . . 36
14.3. MIME Media Type Registration for 'application/ccmp+xml' . 35 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.4. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 36 13. Managing notifications . . . . . . . . . . . . . . . . . . . . 45
14.4.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 36 14. Role based access control . . . . . . . . . . . . . . . . . . 46
14.4.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 37 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
15. Security Considerations . . . . . . . . . . . . . . . . . . . 38 15.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 15.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.3. MIME Media Type Registration for 'application/ccmp+xml' . 47
17.1. Normative References . . . . . . . . . . . . . . . . . . . 38 15.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 48
17.2. Informative References . . . . . . . . . . . . . . . . . . 39 15.4.1. Registration of a Location Server Application
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Service Tag . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 42 15.4.2. Registration of a Location Server Application
Protocol Tag for HELD . . . . . . . . . . . . . . . . 48
15.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 49
15.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 49
15.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 50
16. Security Considerations . . . . . . . . . . . . . . . . . . . 51
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
18. Changes since last Version . . . . . . . . . . . . . . . . . . 51
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
19.1. Normative References . . . . . . . . . . . . . . . . . . . 52
19.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 55
1. Introduction 1. Introduction
The Framework for Centralized Conferencing (XCON) The Framework for Centralized Conferencing [RFC5239] (XCON FW)
[I-D.ietf-xcon-framework]defines a signaling-agnostic framework, defines a signaling-agnostic framework, naming conventions and
naming conventions and logical entities required for constructing logical entities required for building advanced conferencing systems.
advanced conferencing systems. A primary concept introduced in the The XCON FW introduces the conference object as a logical
XCON framework is the existence of a conference object. The representation of a conference instance, representing the current
framework introduces the conference object as a logical
representation of a conference instance which represents the current
state and capabilities of a conference. state and capabilities of a conference.
The Centralized Conferencing Manipulation Protocol (CCMP) defined in The Centralized Conferencing Manipulation Protocol (CCMP) defined in
this document allows the creation, manipulation and deletion of a this document allows authenticated and authorized users to create,
conference object by authenticated and authorized clients. This manipulate and delete conference objects. Operations on conferences
includes adding and removing participants, changing their roles, as include adding and removing participants, changing their roles, as
well as adding and removing media streams and associated end points. well as adding and removing media streams and associated end points.
CCMP implements a client-server model. The server is the Conference CCMP implements the client-server model within the XCON FW, with the
Control Server defined in the XCON framework. The client is the conferencing client and conference control server acting as client
Conference and Media Control Client in the XCON framework. This and server, respectively. CCMP is an instance of conference control
document describes the protocol used by the client for conference protocol (CCP).
control.
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)
[W3C.REC-soap12-part1-20030624] and [W3C.REC-soap12-part2-20030624]
used to carry out the appropriate client-server protocol
transactions.
The common information contained in conference objects is defined CCMP can be mapped into the CRUD (Create, Read, Update, Delete)
using an XML representation based on the schema in the XCON data design pattern. The basic CRUD operations are used to manipulate
model [I-D.ietf-xcon-common-data-model]. These data structures are conference objects, which are XML documents containing the
used as the basis for the Web Services Description Language (WSDL) information characterizing a specified conference instance, be it an
[W3C.CR-wsdl20-20051215] definition and XML schema. active conference or a conference blueprint used by the conference
server to create new conference instances through a simple clone
operation.
This document first provides some background on the motivations CCMP can use a general-purpose protocol such as HTTP [RFC2616] to
associated with the design of CCMP in Section 4 followed by a brief transfer domain-specific XML-encoded data objects defined in the
discussion of the system architecture in Section 5. Conference Information Data Model for Centralized Conferencing
[I-D.ietf-xcon-common-data-model].
A discussion of the primary keys in the conference object carried in CCMP follows the well-known REST (REpresentational State Transfer)
the protocol is detailed in Section 6. An overview of the operations architectural style [REST] This document describes how the CCMP
associated with each protocol request and response is provided in specification maps onto the REST philosophy, by specifying resource
Section 7, with the practical sequence of protocol requests and URIs, resource formats, methods supported at each URI and status
responses discussed in Section 8 and examples provided in Section 10. codes that have to be returned when a certain method is invoked on a
The protocol parameters are detailed in Section 9. specific URI.
The transaction model is described in Section 11. The XML schema is Section 4 motivates the design of CCMP, followed by the system
provided in Section 12 and the corresponding WSDL information is architecture in Section 5. Section 6 discusses the primary keys in
detailed in Section 13. the conference object carried in the protocol. An overview of the
operations associated with each protocol request and response is
provided in Section 7, with the sequence of protocol requests and
responses discussed in Section 8 and examples provided in Section 11.
The protocol parameters are detailed in Section 10. Section 12
provides the XML schema.
2. Conventions 2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations. levels for compliant implementations.
3. Terminology 3. Terminology
This document reuses the terminology defined in the Framework for In additon to the terms defined in the Framework for Centralized
Centralized Conferencing [I-D.ietf-xcon-framework]. In addition, the Conferencing [RFC5239], this document uses the following terms and
following acronyms and terms are used in this document: acronyms:
SOAP: Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W CRUD: CRUD stands for Create/Read/Update/Delete and indicates a
3C.REC-soap12-part2-20030624]. design pattern supporting creating, retrieving, updating and
WSDL: Web Services Description Language[W3C.CR-wsdl20-20051215]. destroying objects.
WSDL is an XML format for describing network services as a set of REST: REpresentational State Transfer (REST) is an architectural
endpoints operating on messages containing either document- style, i.e., a coordinated set of architectural constraints. REST
oriented or procedure-oriented information. is based on the consideration that a software architecture can
W3C: World Wide Web Consortium. The organization that developed the often be specified as an appropriate configuration of components,
data and connectors, all coordinated through constraining their
mutual relationships. Coordination and constraints help achieve a
desired set of architectural properties. [REST]
SOAP: Simple Object Access Protocol defined in
[W3C.REC-soap12-part1-20030624] and
[W3C.REC-soap12-part2-20030624].
W3C: World Wide Web Consortium, the organization that developed the
SOAP and WSDL specifications referenced within this document. SOAP and WSDL specifications referenced within this document.
4. Motivation 4. Rationale and Motivation
SOAP is chosen as the RPC mechanism due to its compatibility with the This document specifies the basic operations that can create,
requirements for the conference control protocol as introduced in the retrieve, modify and delete conference-related information in a
framework for centralized conferencing. SOAP is a lightweight centralized conference. The core set of objects includes conference
protocol for exchange of information in a decentralized, distributed blueprints, the conference itself, users, and sidebars.
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 The operations on these objects can be implemented in at least two
endpoints operating on messages containing either document-oriented different ways, namely as remote procedure calls and by defining
or procedure-oriented information. The operations and messages are resources. A remote procedure call (RPC) mechanism could use SOAP
described abstractly, and then bound to a concrete network protocol (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC
and message format to define an endpoint. Related concrete endpoints -soap12-part2-20030624]), where conferences and the other objects are
are combined into abstract endpoints (services). WSDL is extensible modeled as services with associated operations. Conferences and
to allow description of endpoints and their messages regardless of other objects are selected by their own local identifiers, such as
what message formats or network protocols are used to communicate, email-like names for users. This approach has the advantage that it
however, the only bindings included in this document describe how to can easily define atomic operations that have well-defined error
use WSDL in conjunction with SOAP. conditions.
Alternatively, conference objects can be modeled as resources
identified by URIs, with the basic CRUD operations mapped to the HTTP
methods POST/PUT for creating objects, GET for reading objects,
PATCH/POST/PUT for changing objects and DELETE for deleting them.
Many of the objects, such as conferences, already have a natural
URIs.
In both approaches, servers will have to recreate their internal
state representation of the object with each update request, checking
parameters and triggering function invocations. In the SOAP
approach, it would be possible to describe a separate operation for
each atomic element, but that would greatly increase the complexity
of the protocol. The coarser-grained approach in CCMP does require
that the server process XML elements in updates that have not changed
and that there can be multiple changes in one update.
We assume that each update operation is atomic and either succeeds or
fails as a whole. Thus, a server has to first check all parameters,
before making any changes to the internal representation of the
conference object. For example, it would be undesirable to change
the <subject> of the conference, but then detect an invalid URI in
one of the <service-uris> and abort the remaining updates.
Because multiple clients can modify the same conference objects,
clients need to obtain the current object and then update the whole
object.
Editor's Note: Do we need locking, using WebDAV or floor control?
Otherwise, changes made by user A could get lost when user B wants to
modify some other parameter. For example, A changes the subject, B
adds the a service URI.
In summary, a REST-style approach must ensure sure that all
operations can be mapped to HTTP operations, while all SOAP
operations would use a single HTTP verb. While the RESTful approach
requires the use of a URI for each object, SOAP can use any token.
For CCMP, the resource (REST) model appears more attractive, since
the conference operations fit the CRUD approach.
It is likely that implementations and future standardization work It is likely that implementations and future standardization work
will add more conference attributes and parameters. There are three will add more conference attributes and parameters. There are three
types of extensions. The first and simplest type of extension adds types of extensions. The first and simplest type of extension adds
elements to the overall conference description, media descriptions or elements to the overall conference description, media descriptions or
descriptions of users. The XML namespace mechanism makes such descriptions of users. The XML namespace mechanism makes such
extensions relatively easy, although implementations still have to extensions relatively easy, although implementations still have to
deal with implementations that may not understand the new namespaces. deal with implementations that may not understand the new namespaces.
The Options operation (Section 8.2.1) allows clients to determine the The CCMP "blueprintsRequest" message allows clients to determine the
capabilities of a specific server, reflected by the specific capabilities of a specific server, reflected by the specific
blueprints supported by that server. blueprints supported by that server.
A second type of extension replaces the conference, user or media A second type of extension replaces the conference, user or media
objects with completely new schema definitions, i.e., the namespaces objects with completely new schema definitions, i.e., the namespaces
for these objects themselves differ from the basic one defined in for these objects themselves differ from the basic one defined in
this document. As long as the Options request remains available and this document. As long as the OPTIONS request remains available and
keeps to a mutually-understood definition, a compatible client and keeps to a mutually-understood definition, a compatible client and
server will be able to bootstrap themselves into using these new server will be able to bootstrap themselves into using these new
objects. objects.
Finally, it is conceivable that new object types are needed beyond Finally, it is conceivable that new object types are needed beyond
the core conference, user and media objects and their children. the core conference, user and media objects and their children.
These would also be introduced by namespaces. These would also be introduced by namespaces and new URIs.
5. System Architecture 5. System Architecture
CCMP supports the framework for centralized conferencing. Figure 1 CCMP supports the framework for centralized conferencing. Figure 1
depicts a subset of the 'Conferencing System Logical Decomposition' depicts a subset of the 'Conferencing System Logical Decomposition'
architecture from the framework for centralized conferencing architecture from the framework for centralized conferencing
document. It illustrates the role that CCMP assumes within the document. It illustrates the role that CCMP assumes within the
overall centralized architecture. overall centralized architecture.
........................................................ ........................................................
skipping to change at page 9, line 18 skipping to change at page 10, line 18
If the conference is currently active, dial-out users are contacted If the conference is currently active, dial-out users are contacted
immediately; otherwise, they are contacted at the start of the immediately; otherwise, they are contacted at the start of the
conference. The conference control server assigns a unique conference. The conference control server assigns a unique
Conference User Identifier (XCON-USERID) to each user. The Conference User Identifier (XCON-USERID) to each user. The
conference control server uses the XCON-USERID to change or delete conference control server uses the XCON-USERID to change or delete
<user> elements. Depending upon policies and privileges, specific <user> elements. Depending upon policies and privileges, specific
users MAY also manipulate <user> elements. users MAY also manipulate <user> elements.
In many conferences, users can dial in if they know the XCON-URI and In many conferences, users can dial in if they know the XCON-URI and
an access code shared by all conference participants. In this case, an access code shared by all conference participants. In this case,
the system is typically not be aware of the call signaling URL. the system is typically not aware of the call signaling URL. Thus,
Thus, the initial <user> element does not have an entity attribute the initial <user> element does not have an entity attribute and the
and the default type of <dial-in> is used to support this type of default type of <dial-in> is used to support this type of user. For
user. For this case, the server assigns a locally-unique URI, such this case, the server assigns a locally-unique URI, such as a
as a locally-scoped tel URI. The conference control server assigns a locally-scoped tel URI. The conference control server assigns a
unique Conference User Identifier (XCON-USERID) to these users when unique Conference User Identifier (XCON-USERID) to these users when
they dial-in to join the conference. If the user supports the they dial-in to join the conference. If the user supports the
notification event package [I-D.ietf-xcon-event-package], they can notification event package [I-D.ietf-xcon-event-package], they can
receive their XCON-USERID, thus allowing them to also manipulate the receive their XCON-USERID, thus allowing them to also manipulate the
<user> attribute, including the entity attribute, in the conference <user> attribute, including the entity attribute, in the conference
object. object.
7. Protocol Operations 7. Protocol Operations
The primary function of the protocol defined within this document is The primary function of the protocol defined within this document is
to provide a conference control client with the ability to carry out to provide a conference control client with the ability to carry out
operations on a conference object as a whole and on specific elements operations on a conference object as a whole and on specific elements
within a conference object. This section describes the four basic within a conference object. This section describes the four basic
operations on a conference object: retrieve, create, change and operations on a conference object: retrieve, create, change and
delete. The XCON-URI as discussed in Section 6.1 is the target for delete. The recommended HTTP method for each of the basic operations
each of these operations. The normative protocol details as to the is described. The XCON-URI as discussed in Section 6.1 is the
applicability of each of the operations for the various CCMP requests primary target for each of these operations. The normative protocol
and responses are provided in Section 8 details as to the applicability of each of the operations for the
various CCMP requests and responses are provided in Section 8.
7.1. Retrieve 7.1. Retrieve
The "retrieve" operation is used by a client to query a system for a 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 specific template in the form of a blueprint prior to the creation of
a conference. In this case, the "retrieve" operation often follows a conference. In this case, the "retrieve" operation often follows a
an "options" operation, although a conferencing control client may be "blueprintsRequest" operation, although a conferencing control client
pre-configured to perform the "retrieve" operation on a specific may be pre-configured to perform the "retrieve" operation on a
blueprint. specific blueprint.
The "retrieve" operation is also used to get the current The "retrieve" operation is also used to get the current
representation of a specific conference object (or specific representation of a specific conference object (or specific
parameters in the conference object) for a conference reservation or parameters in the conference object) for a conference reservation or
an active conference. The unique conference identifier (XCON-URI) is an active conference. The unique conference identifier (XCON-URI) is
included in the CCMP request. included in the CCMP request.
The "retrieve" operation returns the XML document describing the The "retrieve" operation returns the XML document describing the
conference object in its current state including all inherited values conference object in its current state including all inherited values
or the specific parameters per the specific request type. Elements or the specific parameters per the specific request type. Elements
may be marked by attributes, in particular, whether they are specific may be marked by attributes, in particular, whether they are specific
to this instance or have been inherited from the parent node. to this instance or have been inherited from the parent node.
To simplify operations, HTTP GET can also be used directly on XCON- In the case of a RESTful implementation of the protocol, HTTP GET
URIs, so that simple systems that need to only obtain data about MUST be used on XCON-URIs, so that clients can obtain data about
conference objects do not need a full SOAP implementation. conference objects in the form of XML data model documents.
7.2. Create 7.2. Create
The "create" operation is used by a client to create and reserve a The "create" operation is used by a client to create and reserve a
conference object or a new conference user. The creation of a conference object or a new conference user. The creation of a
conference object can be explicit by requesting it to be created conference object can be explicit by requesting it to be created
based upon a specific blueprint, based on an existing conference based upon a specific blueprint, based on an existing conference
object (e.g., cloning a conference reservation or active conference object (e.g., cloning a conference reservation or active conference
object) or based on the data included in the request. In the first object) or based on the data included in the request. In the first
two cases, a specific XCON-URI MUST be included in the request. two cases, a specific XCON-URI MUST be included in the request.
When the creation of a conference object is implicit, with no When the creation of a conference object is implicit, with no
conference object for a blueprint or existing conference specified conference object for a blueprint or existing conference specified
and no data included in the request, the creation and reservation of and no data included in the request (i.e., an "empty" request sent to
the conference instance is based on the default conference object. a specific conference server), the creation and reservation of the
The default conference object is specific to a conference control conference instance is based on the default conference object. The
server and its specification is outside the scope of this document. default conference object is specific to a conference control server
and its specification is outside the scope of this document.
A client may first send a requeest with "retrieve" operation in order A client may first send a request with "retrieve" operation in order
to obtain all the data as defined in to obtain all the data as defined in
[I-D.ietf-xcon-common-data-model] for the specific blueprint or [I-D.ietf-xcon-common-data-model] for the specific blueprint or
existing conference object. This would allow the client to modify existing conference object. This would allow the client to modify
the data prior to sending the request with the "create" operation. the data prior to sending the request with the "create" operation.
In this case, the request would also include all the data. If the In this case, the request would also include all the data. If the
client wants to create the new conference by cloning the blueprint or client wants to create the new conference by cloning the blueprint or
existing conference object, there would be no data included in the existing conference object, there would be no data included in the
request. The client may later modify this data by sending a request request. The client may later modify this data by sending a request
with a "change" operation. with a "change" operation.
skipping to change at page 11, line 17 skipping to change at page 12, line 18
In addition, the conference description MAY contain a calendar In addition, the conference description MAY contain a calendar
element, in the iCal format in XML rendition defined in CPL [RFC3880] element, in the iCal format in XML rendition defined in CPL [RFC3880]
or (preferable, if available as stable reference) xCal or (preferable, if available as stable reference) xCal
[I-D.royer-calsch-xcal]. This description indicates when the [I-D.royer-calsch-xcal]. This description indicates when the
conference is active. conference is active.
The "create" operation may also be used to create a new conference The "create" operation may also be used to create a new conference
user with the "userRequest" message. In this case, the user with the "userRequest" message. In this case, the
"userResponse" to this operation includes an XCON-USERID. "userResponse" to this operation includes an XCON-USERID.
To simplify operations, HTTP PUT can also be used to create a new In the case of a RESTful implementation of the protocol, HTTP PUT
object as idenfied by the XCON-URI or XCON-USERID. MUST be used to create a new object as identified by the XCON-URI or
XCON-USERID.
7.3. Change 7.3. Change
The "change" operation updates the conference object as referenced by The "change" operation updates the conference object as referenced by
the XCON-URI included in the request. A request which attempts to the XCON-URI included in the request. A request which attempts to
change a non-existing object is an error, as is a request which change a non-existing object is an error, as is a request which
attempts to change a parameter that is inherited from a protected attempts to change a parameter that is inherited from a protected
element. element.
During the lifetime of a conference, this operation is used by a During the lifetime of a conference, this operation is used by a
skipping to change at page 11, line 41 skipping to change at page 12, line 43
conference object through element specific requests such as conference object through element specific requests such as
"userRequest" or "sideBarRequest", etc. "userRequest" or "sideBarRequest", etc.
Upon receipt of a "change" operation, the conference control server Upon receipt of a "change" operation, the conference control server
updates the specific elements in the referenced conference object. updates the specific elements in the referenced conference object.
Object properties that are not explicitly changed, remain as-is. Object properties that are not explicitly changed, remain as-is.
This approach allows a conference control client to manipulate This approach allows a conference control client to manipulate
objects created by another application even if the manipulating objects created by another application even if the manipulating
application does not understand all object properties. application does not understand all object properties.
To simplify operations, HTTP POST can also be used to change the In the case of a RESTful implementation of the protocol, either HTTP
conference object identified by the XCON-URI. PATCH or HTTP POST MUST be used to change the conference object
identified by the XCON-URI.
7.4. Delete 7.4. Delete
This conference control operation is used to delete the current This conference control operation is used to delete the current
representation of a conference object or a specific parameter in the representation of a conference object or a specific parameter in the
conference object and requires the unique conference identifier conference object and requires the unique conference identifier
(XCON-URI) be provided by the client. (XCON-URI) be provided by the client.
A request which attempts to delete a conference object that is being A request which attempts to delete a conference object that is being
referenced by a child object is an error. referenced by a child object is an error.
To simplify operations, HTTP DELETE can also be used to delete In case of a RESTful implementation of the protocol, HTTP DELETE MUST
conference objects and parameters within conference objects be used to delete conference objects and parameters within conference
identified by the XCON-URI. objects identified by the XCON-URI.
8. Protocol Operations on Conference Objects 8. Protocol Operations on Conference Objects
The primary function of CCMP is to provide a conference control The primary function of CCMP is to provide a conference control
client with the ability to carry out specific operations (Section 7) client with the ability to carry out specific operations (Section 7)
on a conference object through the protocol requests and responses. on a conference object through the protocol requests and responses.
The CCMP requests (Section 8.2)and responses (Section 8.3) are In case of a RESTful implementation of the protocol, the CCMP
enveloped in SOAP requests and responses. The basic request/response requests (Section 8.2)and responses (Section 8.3) MUST be represented
as HTTP requests and responses. The basic CCMP request/response
pairs defined in this document are: pairs defined in this document are:
optionsRequest/optionsResponse: The optionsRequest is used to blueprintsRequest/blueprintsResponse: The blueprintsRequest is used
ascertain the namespaces, conference reservations and active to ascertain the list of blueprints available at the conference
conferences supported by the server. The optionsResponse returns server. The blueprintsResponse returns a list of the requested
a list of the requested types of conference objects (e.g., blueprints, in the form of XCON URIs.
Blueprints, Conference Reservations and/or Active Confrences) confsRequest/confsResponse: The confsRequest is used to ascertain
supported by the specific conference server. conference reservations and active conferences supported by the
server. The confsResponse returns a list of the requested types
of conference objects (i.e. Conference Reservations and/or Active
Conferences) supported by the specific conference server.
blueprintRequest/blueprintResponse: The blueprintRequest is used to
request an operation on a specific blueprint.
confRequest/confResponse: The confRequest is used to request an confRequest/confResponse: The confRequest is used to request an
operation on the conference object as a whole. operation on the conference object as a whole.
userRequest/userResponse: The userRequest is used to request an userRequest/userResponse: The userRequest is used to request an
operation on the "user" element in the conference object. operation on the "user" element in the conference object.
[Editor's Note: we may want to add more discrete user requests/ [Editor's Note: we may want to add more discrete user requests/
responses as this is a very broad parameter] responses as this is a very broad parameter]
usersRequest/usersResponse: This usersRequest is used to manipulate usersRequest/usersResponse: This usersRequest is used to manipulate
the "users" element in the conference object, including parameters the "users" element in the conference object, including parameters
such as the allowed-users-list, join-handling, etc. such as the allowed-users-list, join-handling, etc.
sidebarRequest/sidebarResponse: This sidebarRequest is used to sidebarRequest/sidebarResponse: This sidebarRequest is used to
retrieve the information related to a sidebar or to create, change retrieve the information related to a sidebar or to create, change
or delete a specific sidebar. [Editor's Note: the data model or delete a specific sidebar. [Editor's Note: the data model
defines a byVal and byRef sidebar type. Rather than define two defines a byVal and byRef sidebar type. Rather than define two
root operations, the preference is to have these two types root operations, the preference is to have these two types
reflected by a parameter in the request.] reflected by a parameter in the request.]
[Editor's Note: more core requests/responses will be added to this With respect to the above mentioned operations, we remark that the
document once the WG agrees the basic protocol structure.] difference between "blueprintsRequest" and "confsRequest" only exists
at the semantic level. They both ask for a list of XCON-URIs and
they have exactly the same format. The returned XCON-URIs, though,
represent blueprints in the former case, real (i.e. either active or
reserved) conferences in the latter. The fact that blueprints and
conferences share the same representation (a conference object
compliant with the XCON data model) is a mere coincidence. The same
holds for "confRequest/blueprintRequest", which aim at managing,
respectively, a specific conference object and a specific blueprint.
To simplify operations, a conference control server treats certain To simplify operations, a conference control server treats certain
parameters as suggestions (e.g., for the "create" and "change" parameters as suggestions (e.g., for the "create" and "change"
operations), as noted in the object description. If the conference operations), as noted in the object description. If the conference
control server cannot set the parameter to the values desired, it control server cannot set the parameter to the values desired, it
picks the next best value, according to local policy and returns the picks the next best value, according to local policy and returns the
values selected in the response. If the client is not satisfied with values selected in the response. If the client is not satisfied with
these values, it simply deletes the object. these values, it simply deletes the object.
Along with the protocol requests and responses for manipulating the As illustrated above, along with the protocol requests and responses
conference object, there is also a querying mechanism for manipulating the conference object, there are also querying
("optionsRequest"/"optionsResponse") to ascertain the namespaces mechanisms ("blueprintsRequest"/"blueprintsResponse" and
understood by the server. Any elements with namespaces not "confsRequest/confsResponse") to get information about either
understood by the server are to be ignored by the server. This blueprints or scheduled/active conferences supported by the server.
allows a client to include optional elements in requests without Any elements with namespaces not understood by the server are to be
having to tailor its request to the capabilities of each server. ignored by the server. This allows a client to include optional
elements in requests without having to tailor its request to the
A conference control client and conference control server MUST fully capabilities of each server.
implement the SOAP WSDL schema defined in Section 13 which uses HTTP
operations as the transport mechanism in this specification.
Extensions MAY choose to use alternate transport mechanisms in
association with the SOAP WSDL.
A conference client must first discover the conference control server A conference client must first discover the conference control server
as described in Section 8.1. The conference control server is the as described in Section 8.1. The conference control server is the
recipient of the CCMP requests. recipient of the CCMP requests.
8.1. Locating a Conference Control Server 8.1. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server.
There are several options for discovery of the conference control This document proposes the use of DNS to locate the conferencing
server. server. U-NAPTR resolution for conferencing takes a domain name as
input and produces a URI that identifies the conferencing server.
This process also requires an Application Service tag and an
Application Protocol tag, which differentiate conferencing-related
NAPTR records from other records for that domain.
[Editor's note: need to add more detail in this section!] Section 15.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in
Section 15.4.2, is used to identify an XCON server that understands
the CCMP protocol.
The NAPTR records in the following example Figure 2 demonstrate the
use of the Application Service and Protocol tags. Iterative NAPTR
resolution is used to delegate responsibility for the conferencing
service from "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.".
zonea.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex
. ; replacement
)
Figure 2: Sample XCON:CCMP Service NAPTR Records
Details for the "XCON" Application Service tag and the "CCMP"
Application Protocol tag are included in Section 15.4.
8.2. Constructing a CCMP Request 8.2. Constructing a CCMP Request
The construction of the SOAP envelope associated with a CCMP request
message complies fully with the WSDL, as defined in Section 13.
Construction of a valid CCMP request is based upon the operations Construction of a valid CCMP request is based upon the operations
defined in Section 7, depending upon the function and associated defined in Section 7, depending upon the function and associated
information desired by the conference control client. The following information desired by the conference control client. The next two
sections provide details of the "optionsRequest" message and sections provide details of the "blueprintsRequest" and
"confsRequest" messages, which differ from the other CCMP messages in
that they are only used to ask the conference system for general
information (blueprints and conferences). Subsequent sections
summarize the CCMP requests related to the specific operations in summarize the CCMP requests related to the specific operations in
Section 7. Section 7.
8.2.1. Options Request 8.2.1. blueprintsRequest
The "optionsRequest" is used by a client to query a system for its The "blueprintsRequest" is used by a client to query a system for its
capabilities in terms of types of conferences supported and isn't capabilities in terms of types of conferences supported and isn't
targeted toward a particular conference object. The "optionsRequest targeted toward a particular conference object. Detailed information
is also used by a client with appropriate authority to query a system about a specific blueprint, can be subsequently obtained through the
for a list of the conference reservations and active conferences that blueprintRequest operation, which is used to retrieve a whole XCON
have been created on the specific conferencing system. blueprint (in the form of a conference object) available at the
server.
The "optionsResponse" returns the XML namespaces that the server The "blueprintsResponse" returns the XML namespaces that the server
understands and the namespaces to be used in responses that it understands and the namespaces to be used in responses that it
requires the client to understand. Within the conferencing system, requires the client to understand. Within the conferencing system,
the namespaces correlate with blueprints, as specified in the XCON the namespaces correlate with blueprints, as specified in the XCON
framework. The blueprints are comprised of conference information framework. The blueprints are comprised of conference information
initialized to specific values and ranges. Each blueprint has a initialized to specific values and ranges. Each blueprint has a
corresponding XCON-URI. corresponding XCON-URI.
8.2.2. Operations Requests 8.2.2. confsRequest
The "confsRequest" is used by a client to query a system for
information about reserved/active conferences and isn't targeted
toward a particular conference object. Detailed information about a
specific conference, can be subsequently obtained through the
confRequest operation, which can be used to retrieve a whole XCON
conference (in the form of a conference object) available at the
server.
The "confsResponse" returns the XCON-URIs of all reserved and active
conferences currently hosted by the server.
8.2.3. Operations Requests
Construction of other valid CCMP requests is based upon the Construction of other valid CCMP requests is based upon the
operations defined in Section 7, depending upon the function and operations defined in Section 7, depending upon the function and
associated information desired by the conference control client. The associated information desired by the conference control client. The
following table summarizes specific request type and processing for following table summarizes specific request type and processing for
each of the "operations". A value of "N/A" indicates the specific each of the "operations". A value of "N/A" indicates the specific
operation is not valid for the specific CCMP request. operation is not valid for the specific CCMP request. Following the
table examples for each of the HTTP operations for each of the
request types is provided.
Editors' Notes:
1. Sidebars need additional consideration - e.g., due to the byVal
and byRef options, it's messy. Operations approach may need
additional consideration (or we need separate request types).
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Change | Delete | | Operation | Retrieve | Create | Change | Delete |
| ------------ | | | | | | (HTTP method) | (GET) | (PUT) | (PATCH or | (DELETE) |
| ------------- | | | POST) | |
| Request Type | | | | | | Request Type | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprintsReq | Gets list | N/A | N/A | N/A |
| uest | of | | | |
| | available | | | |
| | blueprints | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest | Gets list | N/A | N/A | N/A |
| | of active | | | |
| | or | | | |
| | reserved | | | |
| | confs | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprintRequ | Gets a | Creates a | Changes a | Deletes a |
| est | specific | blueprint | blueprint | blueprint |
| | blueprint | (needs | (needs | (needs |
| | | admin | admin | admin |
| | | privileges | privileges | privileges |
| | | ) | ) | ) |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confRequest | Gets | Creates | Changes | Deletes | | confRequest | Gets | Creates | Changes | Deletes |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object or | object | object | Object as | | | object | object | object | Object as |
| | blueprint. | | | a whole. | | | | | | a whole |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Gets a | Creates | Adds or | Deletes a | | userRequest | Gets a | Creates a | Modifies | Deletes a |
| | specific | XCON-UserI | modifies | user | | | specific | user and | the | user |
| | user | D . | the | element as | | | user | associated | specified | element as |
| | element. | | specified | a whole. | | | element | XCON-UserI | user | a whole |
| | | | user | | | | | D | element | |
| | | | element. | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Gets a | N/A | Adds or | Deletes a | | usersRequest | Gets a | N/A | Modifies | Deletes a |
| | specific | | modifies | user | | | specific | | the | users |
| | users | | the | element as | | | users | | specified | element as |
| | element. | | specified | a whole. | | | element | | users | a whole |
| | | | users | | | | | | element | |
| | | | element. | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarReques | Gets a | N/A | Adds or | Removes/de | | sidebarReques | Gets a | Creates a | Modifies a | Removes/de |
| t | sidebar | | modifies a | l etes the | | t | sidebar | new | sidebar by | l etes the |
| | element. | | sidebar. | entire | | | element by | sidebar by | Val | entire |
| | | | | sidebar. | | | Val or by | Val | | sidebar b |
| | Ref | | | y Val |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 1: Request Type Operation Specific Processing
The following provides HTTP examples for each of the valid operations
for each request type in the above table Table 1
o blueprintsRequest: GET /blueprints
o confsRequest: GET /confs
o blueprintRequest
* GET /blueprint/blueprintId
* PUT /blueprint/blueprintId
* POST /blueprint/blueprintId
* DELETE /blueprint/blueprintId
o confRequest
* GET /confs/confObjId
* PUT /confs/confObjId
* POST /confs/confObjId
* DELETE /confs/confObjId
o userRequest
* GET /user/confUserId
* PUT /user/confUserId
* POST /user/confUserId
* DELETE /user/confUserId
o usersRequest
* GET /confs/confObjId/users
* POST /confs/confObjId/users
* DELETE /confs/confObjId/users
o sidebarRequest
* By val: GET /confs/confObjId/sidebars/entityAttribute
* By val: N/A (use a "confRequest" message with a "change"
operation for this)
* By val: N/A (use a "confRequest" message with a "change"
operation for this)
* By val: N/A (use a "confRequest" message with a "change"
operation for this)
* By ref: GET /sidebars/sidebarId
8.3. Handling a CCMP Response 8.3. Handling a CCMP Response
As with the CCMP request message, the CCMP response message is A response to the CCMP request MUST contain a response code and may
enclosed in a SOAP envelope. A response to the CCMP request MUST contain other elements depending upon the specific request and the
contain a response code and may contain other elements depending upon value of the response code.
the specific request and the value of the response code.
In case of a RESTful implementation, the CCMP response message MUST
be enclosed in a HTTP response message. CCMP-related error codes
will be carried in the body of the response: no mapping is proposed
in this document regarding the potential association between CCMP and
HTTP error codes. For the sake of adhering to the principle of
separation of concerns, HTTP maintains its own semantics, while
delegating to the CCMP response message (which is in the body of the
HTTP response) the task of informing the CCMP client about error
conditions. This means that, in case of a CCMP error, the client
receives a 200 OK in the HTTP response, but a CCMP-specific response
code in the body of such response.
All response codes are application-level, and MUST only be provided All response codes are application-level, and MUST only be provided
in successfully processed transport-level responses. For example in successfully processed transport-level responses. For example
where HTTP is used, CCMP Response messages MUST be accompanied by a where HTTP is used, CCMP Response messages MUST be accompanied by a
200 OK HTTP response. 200 OK HTTP response.
The set of CCMP Response codes currently contain the following The set of CCMP Response codes currently contain the following
tokens: tokens:
success: This code indicates that the request was successfully success: This code indicates that the request was successfully
skipping to change at page 15, line 34 skipping to change at page 19, line 38
differ from the request. differ from the request.
badRequest: This code indicates that the request was badly formed in badRequest: This code indicates that the request was badly formed in
some fashion. some fashion.
unauthorized: This code indicates that the user was not authorized unauthorized: This code indicates that the user was not authorized
for the specific operation on the conference object. for the specific operation on the conference object.
forbidden: This code indicates that the specific operation is not forbidden: This code indicates that the specific operation is not
valid for the target conference object. valid for the target conference object.
objectNotFound: This code indicates that the specific conference objectNotFound: This code indicates that the specific conference
object was not found. object was not found.
operationNotAllowed: This code indicates that the specific operation operationNotAllowed: This code indicates that the specific operation
is not allowed for the target conference object (e.g.., due to is not allowed for the target conference object (e.g.., when
policies, etc.) trying to make a "confRequest" operation with a request type equal
to "delete" on a conference object representing a blueprint, etc.)
deleteFailedParent: This code indicates that the conferencing system deleteFailedParent: This code indicates that the conferencing system
cannot delete the specific conference object because it is a cannot delete the specific conference object because it is a
parent for another conference object. parent for another conference object.
changeFailedProtected: This code indicates that the target changeFailedProtected: This code indicates that the target
conference object cannot be changed (e.g., due to policies, roles, conference object cannot be changed (e.g., due to policies, roles,
privileges, etc.). privileges, etc.).
requestTimeout: This code indicates that the request could not be requestTimeout: This code indicates that the request could not be
processed within a reasonable time, with the time specific to a processed within a reasonable time, with the time specific to a
conferencing system implementation. conferencing system implementation.
serverInternalError: This code indicates that the conferencing serverInternalError: This code indicates that the conferencing
system experienced some sort of internal error. system experienced some sort of internal error.
notImplemented: This code indicates that the specific operation is notImplemented: This code indicates that the specific operation is
not implemented on that conferencing system. not implemented on that conferencing system.
CCMP Response codes are defined to allow for extensibility. A CCMP Response codes are defined to allow for extensibility. A
conference control client SHOULD treat unrecognized response codes as conference control client SHOULD treat unrecognized response codes as
it handles a Response code of "notImplemented". it handles a Response code of "notImplemented".
8.3.1. Options Response 8.3.1. blueprintsResponse
An "optionsResponse" message containing a response code of "success" A "blueprintsResponse" message containing a response code of
MUST include the XML namespaces that the server understands and the "success" MUST include the XML namespaces that the server understands
namespaces to be used in subsequent responses that it requires the and the namespaces to be used in subsequent responses that it
client to understand. Future work may add more global capabilities requires the client to understand. Future work may add more global
rather than conferencing system specific. Within the conferencing capabilities rather than conferencing system specific. Within the
system, the namespaces correlate with blueprints, as specified in the conferencing system, the namespaces correlate with blueprints, as
XCON framework. The blueprints are comprised of conference specified in the XCON framework. The blueprints are comprised of
information initialized to specific values and ranges. conference information initialized to specific values and ranges.
Upon receipt of a successful "optionsResponse" message, a conference Upon receipt of a successful "blueprintsResponse" message, a
conference control client may then initiate a "blueprintRequest" with
a "retrieve" operation per Section 7.1 to get a specific conference
blueprint.
In the case of a response code of "requestTimeout", a conference
control client MAY re-attempt the request within a period of time
that would be specific to a conference control client or conference
control server.
The response codes of "modified", "deleteParentFailed" and
"changeFailedProtected" are not applicable to a "blueprintsRequest"
and should be treated as "serverInternalError", the handling of which
is specific to the conference control client.
A "blueprintsResponse" message containing any other response code is
an error and the handling is specific to the conference control
client. Typically, an error for a "blueprintsRequest" indicates a
configuration problem in the conference control server or in the
client.
8.3.2. confsResponse
A "confsResponse" message containing a response code of "success"
MUST include the list of XCON-URIs associated with reserved/active
conferences at the server.
Upon receipt of a successful "confsResponse" message, a conference
control client may then initiate a "confRequest" with a "retrieve" control client may then initiate a "confRequest" with a "retrieve"
operation per Section 7.1 to get a specific conference blueprint. operation per Section 7.1 to get a specific conference object.
In the case of a response code of "requestTimeout", a conference In the case of a response code of "requestTimeout", a conference
control client MAY re-attempt the request within a period of time control client MAY re-attempt the request within a period of time
that would be specific to a conference control client or conference that would be specific to a conference control client or conference
control server. control server.
The response codes of "modified", "deleteParentFailed" and The response codes of "modified", "deleteParentFailed" and
"changeFailedProtected" are not applicable to an "optionsRequest" and "changeFailedProtected" are not applicable to a "confsRequest" and
should be treated as "serverInternalError", the handling of which is should be treated as "serverInternalError", the handling of which is
specific to the conference control client. specific to the conference control client.
An "optionsResponse" message containing any other response code is an A "confsResponse" message containing any other response code is an
error and the handling is specific to the conference control client. error and the handling is specific to the conference control client.
Typically, an error for an "optionsRequest" indicates a configuration Typically, an error for a "blueprintsRequest" indicates a
problem in the conference control server or in the client. configuration problem in the conference control server or in the
client.
8.3.2. Operation Responses 8.3.3. Operation Responses
The following sections detail the operation specific handling of the The following sections detail the operation specific handling of the
response codes, including details associated with specific types of response codes, including details associated with specific types of
responses in the cases where the response handling is not generic. responses in the cases where the response handling is not generic.
8.3.2.1. Retrieve Operation Responses 8.3.3.1. Retrieve Operation Responses
A confResponse for a "retrieve" operation containing a response code A confResponse for a "retrieve" operation containing a response code
of "success" MUST contain the full XML document describing the of "success" MUST contain the full XML document describing the
conference object in its current state including all inherited conference object in its current state including all inherited
values. Elements may be marked by attributes, in particular, whether values. Elements may be marked by attributes, in particular, whether
they are specific to this instance or have been inherited from the they are specific to this instance or have been inherited from the
parent node. parent node.
A blueprintResponse for a "retrieve" operation containing a response
code of "success" MUST contain the full XML document describing the
conference object associated with the requested blueprint
Any other CCMP response message (e.g., userResponse, usersResponse, Any other CCMP response message (e.g., userResponse, usersResponse,
etc.) for a "retrieve" operation containing a response code of etc.) for a "retrieve" operation containing a response code of
"success" MUST contain the XML document describing the specific "success" MUST contain the XML document describing the specific
target parameter (as indicated by the specific type of Request) from target parameter (as indicated by the specific type of Request) from
the conference object. the conference object.
If a response code of "objectNotFound" is received in a If a response code of "objectNotFound" is received in a
"confResponse" message to a "confRequest" to get the initial "blueprintResponse" message to a "blueprintRequest" to get the
blueprint, it is RECOMMENDED that a conference control client attempt initial blueprint, it is RECOMMENDED that a conference control client
to retrieve another conference blueprint if more than one had been attempt to retrieve another conference blueprint if more than one had
received in the "optionsResponse" message. If there was only one been received in the "blueprintsResponse" message. If there was only
blueprint in the "optionsResponse" initially, then the client should one blueprint in the "blueprintsResponse" initially, then the client
send another "optionsRequest" message to determine if there may be should send another "blueprintsRequest" message to determine if there
new or additional blueprints for the specific conferencing system. may be new or additional blueprints for the specific conferencing
If this "optionsResponse" message contains no blueprints, the system. If this "blueprintsResponse" message contains no blueprints,
handling is specific to the conference control client. If the client the handling is specific to the conference control client. This
was retrieving an existing conference object that had been returned might indicate, for example, that something is going wrong at the
in a previous "optionsRequest", the "objectNotFound" could reflect a server, since no more blueprints are now available at it. In such
conference object that has been deleted by another user. In this case, the client MAY interpret the new answer as a
case, the client should consider another "optionsRequest" message to 'serverInternalError' and assume that no more service associated with
obtain an up-to-date list of conference objects. blueprints (e.g. creation of a new conference starting from a server-
side template) is available.
If a response code of "requestTimeout" is received in the CCMP If a response code of "requestTimeout" is received in the CCMP
response, a conference control client MAY re-attempt the request response, a conference control client MAY re-attempt the request
within a period of time that would be specific to a conference within a period of time that would be specific to a conference
control client or conference control server. control client or conference control server.
Response codes such as "notImplemented" and "forbidden" indicate that Response codes such as "notImplemented" and "forbidden" indicate that
a subsequent "retrieve" would not likely be sucessful. Handling of a subsequent "retrieve" would not likely be sucessful. Handling of
these and other response codes is specific to the conference control these and other response codes is specific to the conference control
client. For example, in the case of some clients an "options" client. For example, in the case of some clients a
operation might be performed again or another conference control "blueprintsRequest" operation might be performed again or another
server may be accessed. conference control server may be accessed.
The response codes of "modified", "deleteParentFailed" and The response codes of "modified", "deleteParentFailed" and
"changeFailedProtected" are not applicable to the "retrieve" "changeFailedProtected" are not applicable to the "retrieve"
operation and SHOULD be treated as "serverInternalError", the operation and SHOULD be treated as "serverInternalError", the
handling of which is specific to the conference control client. handling of which is specific to the conference control client.
8.3.2.2. Create Operation Responses 8.3.3.2. Create Operation Responses
The only valid responses containing a "create" operation are a The only valid responses containing a "create" operation are a
"confResponse" and the "userResponse". If the CCMP response contains "confResponse", a "blueprintResponse" and the "userResponse". The
a response code of "success", a "confResponse" message MUST contain "blueprintRequest" containing a "create" operation has to be
the XCON-URI for the conference object and a "userResponse" message considered a special operation, used by a conference server
MUST contain the XCON-USERID. administrator wishing to remotely add a new blueprint to the
conference server. The operation requires that the new blueprint is
associated with an XCON-URI. Such URI is provided by the
administrator in the request, but has to be considered as a
suggestion. The conference server MAY change such identifier and
create a new one. The new identifier MUST be returned to the client
as part of the "blueprintResponse" message. If the CCMP response
contains a response code of "success", a "confResponse" message MUST
contain the XCON-URI for the conference object and a "userResponse"
message MUST contain the XCON-USERID.
If the confResponse to a "create" operation contains a response code If the confResponse to a "create" operation contains a response code
of "modified", along with the XCON-URI for the conference object, the of "modified", along with the XCON-URI for the conference object, the
response MUST also contain the entire XML document associated with response MUST also contain the entire XML document associated with
that conference object for a "confRequest". For example, in the case that conference object for a "confRequest". For example, in the case
where the conference object contained a calendar element, the where the conference object contained a calendar element, the
conference server may only offer a subset of the dates requested, conference server may only offer a subset of the dates requested,
thus the updated dates are included in the returned XML document. thus the updated dates are included in the returned XML document.
In the case of a response code of "requestTimeout", a conference In the case of a response code of "requestTimeout", a conference
skipping to change at page 18, line 30 skipping to change at page 23, line 31
The response codes of "deleteParentFailed" and The response codes of "deleteParentFailed" and
"changeFailedProtected" are not applicable to the "create" operation "changeFailedProtected" are not applicable to the "create" operation
and SHOULD be treated as "serverInternalError", the handling of which and SHOULD be treated as "serverInternalError", the handling of which
is specific to the conference control client. is specific to the conference control client.
Any other response code indicates an error in the client or Any other response code indicates an error in the client or
conference control server (e.g., "forbidden", "badRequest") and the conference control server (e.g., "forbidden", "badRequest") and the
handling is specific to the conference control client. handling is specific to the conference control client.
8.3.2.3. Change Operation Responses 8.3.3.3. Change Operation Responses
If the CCMP response to the "change" operation contains a response If the CCMP response to the "change" operation contains a response
code of "success", the response SHOULD also contain the XCON-URI for code of "success", the response SHOULD also contain the XCON-URI for
the conference object that was changed. the conference object that was changed.
The "blueprintRequest" containing a "change" operation has to be
considered a special operation, used by a conference server
administrator wishing to remotely an existing blueprint in the
conference server.
If the CCMP response to the "change" operation contains a response If the CCMP response to the "change" operation contains a response
code of "modified", the response MUST contain the XCON-URI for the code of "modified", the response MUST contain the XCON-URI for the
conference object and the appropriate XML document (either the full conference object and the appropriate XML document (either the full
XML document for a confResponse or specific paramaters for the other XML document for a confResponse or specific paramaters for the other
CCMP request types) associated with that conference object. For CCMP request types) associated with that conference object. For
example, a conferencing system may not have the resources to support example, a conferencing system may not have the resources to support
specific capabilities that were changed, such as <codecs> in the specific capabilities that were changed, such as <codecs> in the
<available-media>, thus the <codecs> supported are included in the <available-media>, thus the <codecs> supported are included in the
returned XML document. returned XML document.
skipping to change at page 19, line 18 skipping to change at page 24, line 25
request would likely not succeed. request would likely not succeed.
The response code of "deleteParentFailed" is not applicable to the The response code of "deleteParentFailed" is not applicable to the
"change" operation and SHOULD be treated as "serverInternalError", "change" operation and SHOULD be treated as "serverInternalError",
the handling of which is specific to the conference control client. the handling of which is specific to the conference control client.
Any other response code indicates an error in the client or Any other response code indicates an error in the client or
conference control server (e.g., "forbidden", "badRequest") and the conference control server (e.g., "forbidden", "badRequest") and the
handling is specific to the conference control client. handling is specific to the conference control client.
8.3.2.4. Delete Operation Responses [Note by spromano: In case of "change" with a userRequest, the server
first has to change the user's information stored; then, it has to
update all conference objects which include that user. The
association between the user and the conferences in which she/he is
participating is guaranteed through the "entity" attribute of the
<user> element. IMO, after doing all that, the server just answers
with a userResponse message; then, if it is also using notifications,
it might raise events towards the interested subscribers, to notify
them about the changes in the updated conference objects. Is this
right??]
8.3.3.4. Delete Operation Responses
If the CCMP response to the "delete" operation contains a response If the CCMP response to the "delete" operation contains a response
code of "success", the response MUST contain the XCON-URI for the code of "success", the response MUST contain the XCON-URI for the
conference object that was deleted for a "confResponse" or whose data conference object that was deleted for a "confResponse" or whose data
element(s) were deleted for the other response types. element(s) were deleted for the other response types.
The "blueprintRequest" containing a "delete" operation has to be
considered a special operation, used by a conference server
administrator wishing to remotely remove a blueprint from the
conference server.
The response code of "deleteParentFailed" indicates that the The response code of "deleteParentFailed" indicates that the
conference object could not be deleted because it is the Parent of conference object could not be deleted because it is the Parent of
another conference object that is in use. In this case, the response another conference object that is in use. In this case, the response
also includes the XCON-URI for the conference object and is only also includes the XCON-URI for the conference object and is only
applicable to a "confResponse". If this response code is received applicable to a "confResponse". If this response code is received
for any other type of CCMP response, it should be treated as for any other type of CCMP response, it should be treated as
"serverInternalError", the handling of which is specific to the "serverInternalError", the handling of which is specific to the
conference control client. conference control client.
If a response code of "requestTimeout" is received, a conference If a response code of "requestTimeout" is received, a conference
control client MAY re-attempt the request within a period of time control client MAY re-attempt the request within a period of time
that would be specific to a conference control client or conference that would be specific to a conference control client or conference
control server. control server.
Response codes such as "unauthorized", "forbidden" and Response codes such as "unauthorized", "forbidden" and
"operationNotAllowed" indicate the client does not have the "operationNotAllowed" indicate the client does not have the
appropriate permissions, the conference is locked, there is an error appropriate permissions, the conference is locked, the object that
in the permissions, or there is a system error in the client or the client is trying to delete is actually a blueprint, there is an
error in the permissions, or there is a system error in the client or
conference control server, thus re-attempting the request would conference control server, thus re-attempting the request would
likely not succeed. likely not succeed.
The response code of "changeFailedProtected" is not applicable to the The response code of "changeFailedProtected" is not applicable to the
"delete" operation and SHOULD be treated as "serverInternalError", "delete" operation and SHOULD be treated as "serverInternalError",
the handling of which is specific to the conference control client. the handling of which is specific to the conference control client.
Any other response code indicates an error in the client or Any other response code indicates an error in the client or
conference control server (e.g., "forbidden", "badRequest") and the conference control server (e.g., "forbidden", "badRequest") and the
handling is specific to the conference control client. handling is specific to the conference control client.
9. Protocol Parameters [Note by spromano (same comment as for "change"): In case of "delete"
with a userRequest, the server first has to delete the user's
information stored; then, it has to update all conference objects
which include that user. The association between the user and the
conferences in which she/he is participating is guaranteed through
the "entity" attribute of the <user> element. IMO, after doing all
that, the server just answers with a userResponse message; then, if
it is also using notifications, it might raise events towards the
interested subscribers, to notify them about the changes in the
updated conference objects. Is this right??]
9. Managing sidebars
Sidebars can be either "by reference" or "by value". The management
of sidebars differs in the two cases, as discussed below
9.1. Sidebars by value
Sidebars by value represent an inner part of the conference object
associated with the root conference from which they stem. One or
more sidebars by value are then created by using the "confRequest"
message with an operation of "change". The conference description
provided in the request MUST contain the desired sidebars
information, in the form of a sequence of one or more <entry>
elements under the <sidebars-by-val> element. Information about a
sidebar by value can be accessed directly through a "sidebarRequest"
message containing the identifier of the required sidebar (i.e. its
"entity" attribute value).
9.2. Sidebars by reference
Sidebars by reference represent semi-independent conference objects,
i.e. objects that exist on their own, but which are strictly coupled
to the conference object from which they stem. A sidebar by
reference is then created by using the "confRequest" message with an
operation of "create".
Editor's Note: should we have a means to indicate that the object we
are creating is actually a sidebar? This would go in the
confRequest/create message. Otherwise, we might add a
sidebarRequest/create operation which basically does a conference
creation, but, e.g., stores it in a different repository (/sidebars
rather than /confs).
Once the sidebar has been created, you can add it to a conference by
issuing a "confRequest" message with a "change" operation on the
conference object which the sidebar belongs to. Information about a
sidebar by reference can be accessed directly through a
"sidebarRequest" message containing the identifier of the required
sidebar (i.e. the value of its <uri> element).
10. Protocol Parameters
This section describes in detail the parameters that are used for the This section describes in detail the parameters that are used for the
CCMP protocol. CCMP protocol.
9.1. Operation Parameter 10.1. Operation Parameter
The "operation" attribute is a mandatory token included in all CCMP The "operation" attribute is a mandatory token included in all CCMP
request and response messages except the "optionsRequest" and request and response messages. This document defines four possible
"optionsResponse". This document defines four possible values for values for this parameter: "retrieve", "create", "change" and
this parameter: "retrieve", "create", "change" and "delete". "delete".
9.2. Request ID Parameter
The "requestID" attribute is a mandatory token included in all CCMP
request and response messages. The "requestID" is used to correlate
the requests with the appropriate response.
9.3. ConfObjID Parameter 10.2. ConfObjID Parameter
The "confObjID" attribute is an optional URI included in the CCMP The "confObjID" attribute is an optional URI included in the CCMP
request and response messages. This attribute is required in the request and response messages. This attribute is required in the
case of an "operation" of "retrieve", "change", and "delete" in the case of an "operation" of "retrieve", "change", and "delete" in the
CCMP request and response messages. The attribute is optional for an CCMP request and response messages. The attribute is optional for an
"operation" of "create" in the "confRequest" message. The "create" "operation" of "create" in the "confRequest" message. The "create"
cases for which this parameter is REQUIRED are described in cases for which this parameter is REQUIRED are described in
Section 7.2. This attribute is the XCON-URI which is the target for Section 7.2. This attribute is the XCON-URI which is the target for
the specific operation. [Editor's Note: it might be good to re- the specific operation. [Editor's Note: it might be good to re-
iterate the normative text here.] iterate the normative text here.]
This attribute is not included in the "userRequest" message for an This attribute is not included in the "userRequest" message for an
operation of "create". In this case, the conference control client operation of "create". In this case, the conference control client
is requesting the creation of a new conference user, as detailed in is requesting the creation of a new conference user, as detailed in
Section 9.4. Section 10.3.
In the cases where the "conference-info" parameter Section 9.7 is In the cases where the "conference-info" parameter Section 10.6 is
also included in the requests and responses, the "confObjID" MUST also included in the requests and responses, the "confObjID" MUST
match the XCON-URI in the "entity" attribute. match the XCON-URI in the "entity" attribute.
9.4. ConfUserID Parameter 10.3. ConfUserID Parameter
The "confUserID" attribute is optional URI included in the CCMP The "confUserID" attribute is optional URI included in the CCMP
request and response messages. This is the XCON-USERID for the request and response messages. This is the XCON-USERID for the
conference control client initiating the request. The attribute is conference control client initiating the request. The attribute is
required in the CCMP request and response messages with the exception required in the CCMP request and response messages with the exception
of the "userRequest" message. The "confUserID" parameter is used to of the "userRequest" message. The "confUserID" parameter is used to
determine if the conference control client has the authority to determine if the conference control client has the authority to
perform the operation. Note that the details for authorization and perform the operation. Note that the details for authorization and
related policy are specified in a separate document [TBD]. related policy are specified in a separate document [TBD].
skipping to change at page 21, line 25 skipping to change at page 27, line 46
if the allocation of a new XCON-USERID is succesful. if the allocation of a new XCON-USERID is succesful.
In the case where there is a confUserID in the request that has In the case where there is a confUserID in the request that has
already been allocated, this request may be the creation of a already been allocated, this request may be the creation of a
confUserID for the conference control client to take on an additional confUserID for the conference control client to take on an additional
role. role.
This attribute is required in the "userResponse" message in the case This attribute is required in the "userResponse" message in the case
of an "operation" of "create" and for all other responses. of an "operation" of "create" and for all other responses.
9.5. ResponseCode Parameter 10.4. ResponseCode Parameter
The "responseCode" attribute is a mandatory parameter in all CCMP The "responseCode" attribute is a mandatory parameter in all CCMP
response messages. The values for each of the "responseCode" values response messages. The values for each of the "responseCode" values
are detailed in Section 8.3 with the associated processing described are detailed in Section 8.3 with the associated processing described
in Section 8.3.2. in Section 8.3.3.
9.6. Blueprints Parameter 10.5. Blueprints Parameter
The "blueprints" attribute is an optional parameter in the CCMP The "blueprints" attribute is an optional parameter in the CCMP
optionsResponse and confRequest messages. blueprintsResponse message. In the case of a "blueprintsRequest"
message, the "blueprintsResponse" message with a "responseCode" of
In the case of an "optionsRequest" message, the "optionsResponse" "success" SHOULD include the "blueprints" supported by the conference
message with a "responseCode" of "success" SHOULD include the control server. The "blueprints" attribute is comprised of a list of
"blueprints" supported by the conference control server. The blueprints supported by the specific conference server and includes a
"blueprints" attribute is comprised of a list of blueprints supported conference system specific "blueprintName" and a "confObjID" in the
by the specific conference server and includes a conference system form of an XCON-URI for each of the blueprints.
specific "blueprintName" and a "confObjID" in the form of an XCON-URI
for each of the blueprints.
The "blueprints" attribute is optional for a confRequest with an
operation of "retrieve".
9.7. Conference-info Parameter 10.6. Conference-info Parameter
The "conference-info" element is optional in the CCMP confRequest and The "conference-info" element is optional in the CCMP confRequest and
confResponse messages. confResponse messages.
The "conference-info" element contains the data for the conference The "conference-info" element contains the data for the conference
object that is the target for the "confRequest" operations for object that is the target for the "confRequest" operations for
"create", "change" and "delete" operations. It is returned in a "create", "change" and "delete" operations. It is returned in a
"confResponse" if the "confResponse" contains a responseCode of "confResponse" if the "confResponse" contains a responseCode of
"modified" or if the original CCMP request for the "create" operation "modified" or if the original CCMP request for the "create" operation
did not contain a "conference-info" element. The latter case occurs did not contain a "conference-info" element. The latter case occurs
when a conference control client sends a "confRequest" containing any when a conference control client sends a "confRequest" containing any
of the following: - a "confObjID" associated with a specific of the following: - a "confObjID" associated with a specific
blueprint - a "confObjID associated with a specific active conference blueprint - a "confObjID associated with a specific active conference
or conference reservation that was included in an "optionsResponse" or conference reservation that was included in a "confsResponse"
message - no "confObjID" (or "conference-info") element, in which message - no "confObjID" (or "conference-info") element, in which
case the request is to create a conference object based on a default case the request is to create a conference object based on a default
provided by a conferencing system. provided by a conferencing system.
The "conference-info" element is also returned in a "userResponse"
message, in the case of a "change" operation. In such case, in fact,
the request contains the <user> element to be added to the conference
indicated in the <confObjID> parameter; the associated answer SHOULD
carry the updated conference object in its body.
The details on the information that may be included in the The details on the information that may be included in the
"conference-info" element MUST follow the rules as specified in the "conference-info" element MUST follow the rules as specified in the
XCON Data Model document [I-D.ietf-xcon-common-data-model]. The XCON Data Model document [I-D.ietf-xcon-common-data-model]. The
conference control client and conference control server MUST follow conference control client and conference control server MUST follow
those rules in generating the "conference-info" in any of the CCMP those rules in generating the "conference-info" in any of the CCMP
request and response messages. request and response messages.
Note that the "conference-info" element is not explicitly shown in Note that the "conference-info" element is not explicitly shown in
the XML schema (Section 12) due to XML schema constraints. the XML schema (Section 12) due to XML schema constraints.
9.8. User Parameter 10.7. User Parameter
The "user" element contains the data for the conference user that is The "user" element contains the data for the conference user that is
the target for the CCMP request operations. It is REQUIRED for all the target for the CCMP request operations. It is REQUIRED for all
"userRequest" messages. "userRequest" messages.
The details on the information that may be included in the "user" The details on the information that may be included in the "user"
element MUST follow the rules as specified in the XCON Data Model element MUST follow the rules as specified in the XCON Data Model
document [I-D.ietf-xcon-common-data-model]. The conference control document [I-D.ietf-xcon-common-data-model]. The conference control
client and conference control server MUST follow those rules in client and conference control server MUST follow those rules in
generating the "user" in any of the CCMP request and response generating the "user" in any of the CCMP request and response
messages. messages.
Note that the "user" element is not explicitly shown in the XML Note that the "user" element is not explicitly shown in the XML
schema Section 12 due to XML schema constraints. schema Section 12 due to XML schema constraints.
9.9. Users Parameter 10.8. Users Parameter
The "users" element contains the data for the conference users that The "users" element contains the data for the conference users that
are the target for the CCMP request operations. It is REQUIRED for are the target for the CCMP request operations. It is REQUIRED for
all "usersRequest" messages. all "usersRequest" messages.
The details on the information that may be included in the "users" The details on the information that may be included in the "users"
element MUST follow the rules as specified in the XCON Data Model element MUST follow the rules as specified in the XCON Data Model
document [I-D.ietf-xcon-common-data-model]. The conference control document [I-D.ietf-xcon-common-data-model]. The conference control
client and conference control server MUST follow those rules in client and conference control server MUST follow those rules in
generating the "users" in any of the CCMP request and response generating the "users" in any of the CCMP request and response
messages. messages.
Note that the "users" element is not explicitly shown in the XML Note that the "users" element is not explicitly shown in the XML
schema Section 12 due to XML schema constraints. schema Section 12 due to XML schema constraints.
9.10. Sidebar Parameters 10.9. Sidebar Parameters
The "sidebar" parameter contains the data for the sidebar that is the The "sidebar" parameter contains the data for the sidebar that is the
target for the CCMP request operations. It is REQUIRED for all target for the CCMP request operations. It is REQUIRED for all
"sidebarRequest" messages. There are two elements associated with a "sidebarRequest" messages. There are two elements associated with a
sidebar: "sidebar-by-val" and "sidebar-by-ref". The elements relate sidebar: "sidebar-by-val" and "sidebar-by-ref". The elements relate
to whether the data for the sidebar is in the same conference object to whether the data for the sidebar is in the same conference object
for which it serves as a sidebar or whether a new conference object for which it serves as a sidebar or whether a new conference object
is created for the sidebar. is created for the sidebar.
The details on the information that may be included in the "sidebar- The details on the information that may be included in the "sidebar-
by-val" or "sidebar-by-ref" element MUST follow the rules as by-val" or "sidebar-by-ref" element MUST follow the rules as
specified in the XCON Data Model document specified in the XCON Data Model document
[I-D.ietf-xcon-common-data-model]. The conference control client and [I-D.ietf-xcon-common-data-model]. The conference control client and
conference control server MUST follow those rules in generating the conference control server MUST follow those rules in generating the
"sidebar-by-val" or "sidebar-by-ref" element in any of the CCMP "sidebar-by-val" or "sidebar-by-ref" element in any of the CCMP
request and response messages. request and response messages.
10. Examples 11. Examples
The examples below omits the standard SOAP header and wrappers, i.e., Examples on the use of HTTP as the CCP based on a RESTful
the examples below contain simply the <body> of the requests and implementation are provided in Section 11.1. The body of the HTTP
responses. methods contains the CCMP operations and data. Examples of the CCMP
operations and related data are provided in section Section 11.2
10.1. Creating a New Conference 11.1. HTTP methods for realizing a RESTful CCMP
This section provides a series of examples using the HTTP methods for
realization of the CCMP. The examples provide a sequence of
operations that a typical user might invoke in activating a
conference, adding users to a conference, retrieving conference data
and then deleting an active conference. Note, the examples do not
include any details beyond the basic operation. For example, the
"Host" that would be the result of discovery of the conference server
per Section 8.1 would be included in the HTTP messages.
Alice retrieves info about active/scheduled CCMP 'conferences':
CCMP client "Alice" ConfS
| |
| GET /confs |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ conf info
|<---------------------------------------------| (list of
| | conf objs)
Figure 3: Getting a List of Active Coferences
Alice is now able to retrieve info about a specific conference:
CCMP client "Alice" ConfS
| |
| GET /confs/confid-34fg67h |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ XML info
|<---------------------------------------------|
| |
Figure 4: Getting a Specific Coference
Alice decides to add a new user to this conference:
CCMP client "Alice" ConfS
| |
| PUT /confs/confid-34fg67h/users/pippo876 |
| (w/ body=new user info) |
|--------------------------------------------->|
| |--+ Add new user
| | | to data model
| 200 OK (w/ body) |<-+ and update
|<---------------------------------------------| user in system
| |
| | (event triggered
| | e.g. RFC4575)
| |---------------->
| |
Figure 5: Adding a New User to an Active Conference
Subsequent GETs on both the conference object as a whole and the
users portion reflect the addition of the New User:
CCMP client "Alice" ConfS
| |
| GET /confs/confid-34fg67h/users/pippo876 |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ XML info
|<---------------------------------------------|
| |
| GET /users/pippo876 |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ XML info
|<---------------------------------------------|
| |
Figure 6: Getting a Specific Conference Object after Changes
Alice updates some info related to the same user:
CCMP client "Alice" ConfS
| |
| POST /confs/confid-34fg67h/users/pippo876 |
| (w/ body=updated user info) |
|--------------------------------------------->|
| |--+ Update user
| | | in data
| 200 OK (w/ body) |<-+ and in
|<---------------------------------------------| system
| |
| |Event trigger
| |e.g. RFC4575
| |------------->
| |
Figure 7: Updating a User's Information
Alice destroys the running conference: when trying to access it, the
server returns an error:
CCMP client "Alice" ConfS
| |
| DELETE /confs/confid-34fg67h |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ XML info
|<---------------------------------------------|
| |
| GET /confs/confid-34fg67h |
|--------------------------------------------->|
| |--+ ConfS can't
| | | find the
| 200 OK (w/body: |<-+ conference
|<---------------------------------------------|
| responseCode=objectNotFound |
| |
Figure 8: Deleting an Active Coference
11.2. CCMP Detailed Message Body Examples
The examples below contain simply the <body> of the requests and
responses. In the case that HTTP serves as the transport, the HTTP
methods as identified in Table 1 (and per the examples in
Section 11.1) would include the CCMP requests and Responses as the
body of the HTTP methods.
11.2.1. Creating a New Conference
The first example creates a new conference. The first example creates a new conference.
<confRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <confRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
<requestID> 99 </requestID>
<operation>create</operation> <operation>create</operation>
<confUserID> userA-confxyz987 </confUserID> <confUserID> userA-confxyz987 </confUserID>
<conference-info <conference-info
xmlns="urn:ietf:params:xml:ns:conference-info" xmlns="urn:ietf:params:xml:ns:conference-info"
version="1"> version="1">
<conference-description> <conference-description>
<parent>http://example.com/conf200</parent> <parent>http://example.com/conf200</parent>
<subject>Agenda: This month's goals</subject> <subject>Agenda: This month's goals</subject>
<conf-uris> <conf-uris>
skipping to change at page 24, line 37 skipping to change at page 34, line 36
<entry> <entry>
<uri>http://example.com/conf233</uri> <uri>http://example.com/conf233</uri>
<purpose>control</purpose> <purpose>control</purpose>
</entry> </entry>
</service-uris> </service-uris>
</conference-description> </conference-description>
</conference-info> </conference-info>
</confRequest> </confRequest>
Figure 2: Create Request Example Figure 9: Create Request Example
The response to this request is shown below; it returns the object The response to this request is shown below; it returns the object
identifier as a URL and the final conference description, which may identifier as a URL and the final conference description, which may
modify the description offered by the user. modify the description offered by the user.
<confResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <confResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"
<requestID> 99 </requestID>
<operation>create</operation> <operation>create</operation>
<responseCode> modified </responseCode> <responseCode> modified </responseCode>
<confObjID> xcon:confxyz987@example.com </confObjID> <confObjID> xcon:confxyz987@example.com </confObjID>
<confUserID> userA-confxyz987 </confUserID> <confUserID> userA-confxyz987 </confUserID>
<conference-info <conference-info
xmlns="urn:ietf:params:xml:ns:conference-info" xmlns="urn:ietf:params:xml:ns:conference-info"
version="1"> version="1">
<entity> xcon:confxyz987@example.com </entity> <entity> xcon:confxyz987@example.com </entity>
<conference-description> <conference-description>
skipping to change at page 25, line 50 skipping to change at page 35, line 49
<target uri="sip:alice@example.com" method="dial-out"/> <target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:bob@example.com" method="dial-out"/> <target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:userA@example.com" method="dial-in"/> <target uri="sip:userA@example.com" method="dial-in"/>
</allowed-users-list> </allowed-users-list>
</conference-description> </conference-description>
</conference-info> </conference-info>
</confResponse> </confResponse>
Figure 3: Create Response Example Figure 10: Create Response Example
10.2. Creating a New Conference User 11.2.2. Creating a New Conference User
The request below creates a new conference user, independent of a The request below creates a new conference user, independent of a
specific conference object. specific conference object.
<userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
<requestID> 101 </requestID>
<operation>create</operation> <operation>create</operation>
<user entity="sip:bob@example.com"> <user entity="sip:bob@example.com">
<role>observer</role> <role>observer</role>
</user> </user>
</userRequest> </userRequest>
Figure 4: Create User Example Figure 11: Create User Example
The response to this request is shown below; it returns the The response to this request is shown below; it returns the
conference user identifier. conference user identifier.
<userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
<requestID> 101 </requestID>
<operation>create</operation> <operation>create</operation>
<responseCode> success </responseCode> <responseCode> success </responseCode>
<confUserID> userC-confxyz987 </confUserID> <confUserID> userC-confxyz987 </confUserID>
</userResponse> </userResponse>
Figure 5: Create Response Example Figure 12: Create Response Example
10.3. Adding a User to a Conference 11.2.3. Adding a User to a Conference
The request below adds a user to the conference identified by the The request below adds a user to the conference identified by the
XCON-URI. Note that the user in "confUserID" element is the user XCON-URI. Note that the user in "confUserID" element is the user
requesting that the user "sip:claire@example.com" be added to the requesting that the user "sip:claire@example.com" be added to the
conference. The user may or may not be "claire" (i.e., a user, such conference. The user may or may not be "claire" (i.e., a user, such
as the moderator, can add another user to the conference. as the moderator, can add another user to the conference.
Editor's note: Do we need to consider users adding users OBO of other
users or in that case do we just change the conference object as a
whole?
<userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
<requestID> 100 </requestID>
<operation>change</operation> <operation>change</operation>
<confObjID> xcon:confxyz987@example.com </confObjID> <confObjID> xcon:confxyz987@example.com </confObjID>
<confUserID> userC-confxyz987 </confUserID> <confUserID> userC-confxyz987 </confUserID>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
version="1">
<entity> xcon:confxyz987@example.com </entity>
<conference-description>
<user entity="sip:claire@example.com"> <user entity="sip:claire@example.com">
<role>participant</role> <role>participant</role>
<type>dial-out</type> <type>dial-out</type>
</user> </user>
</conference-description>
</conference-info>
</userRequest> </userRequest>
Figure 6: Add User Example Figure 13: Add User Example
The response to this request is shown below; it returns the The response to this request is shown below.
conference user identifier.
<userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
<requestID> 100 </requestID> <operation>change</operation>
<operation>create</operation>
<responseCode> success </responseCode> <responseCode> success </responseCode>
<confObjID> xcon:confxyz987@example.com </confObjID> <confObjID> xcon:confxyz987@example.com </confObjID>
<confUserID> userC-confxyz987 </confUserID> <confUserID> userC-confxyz987 </confUserID>
<!-- Note that additional conference-info may also be
returned depending upon Bob's privileges. I
In this case, the response code would be "modified". -->
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
version="1">
<entity> xcon:confxyz987@example.com </entity>
<conference-description>
<user entity="sip:claire@example.com"> <user entity="sip:claire@example.com">
<role>participant</role> <role>participant</role>
<type><dial-out/></type> <type><dial-out/></type>
</user> </user>
</conference-description> </users>
</conference-info> </conference-info>
</userResponse> </userResponse>
Figure 7: Add User Response Example Figure 14: Add User Response Example
11. Transaction Model
The transaction model for CCMP complies fully with SOAP version 1.2
as defined by W3C in [W3C.REC-soap12-part1-20030624] and
[W3C.REC-soap12-part2-20030624].
12. XML Schema 12. XML Schema
This section provides the XML schema definition of the "application/ This section provides the XML schema definition of the "application/
ccmp+xml" format. ccmp+xml" format.
Editor's Note: the schema currently matches the prototype - it needs
updating to include changes/additions to request names (e.g.,
optionsRequest -> blueprintsRequest, addition of blueprintRequest and
confsRequest.
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp" targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ccmp" type="ccmp-request-response-type" /> <!-- Import data model schema (as per the latest draft) -->
<xs:import
namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel-11.xsd"/>
<xs:complexType name="ccmp-request-response-type"> <xs:element name="ccmpRequest"
type="ccmp-request-type" />
<xs:element name="ccmpResponse"
type="ccmp-response-type" />
<!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:element name="ccmpRequest"
<xs:element name="ccmpRequest" type="ccmp-message-type" /> type="ccmp-request-message-type" />
<xs:element name="ccmpResponse" type="ccmp-message-type" />
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xs:choice>
</xs:sequence> </xs:sequence>
<xs:attribute name="xconURI" type="xs:anyURI" use="optional"/> <xs:attribute name="xconURI" type="xs:string"
<xs:anyAttribute namespace="##other" processContents="lax" /> use="optional" />
</xs:complexType> </xs:complexType>
<xs:complexType name="ccmp-message-type"> <!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
<xs:attribute name="xconURI" type="xs:string"
use="optional" />
</xs:complexType>
<!-- Definition of ccmp-request-message-type as an
abstract complex type -->
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<!-- blueprintsRequest -->
<xs:complexType
name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:choice>
<xs:element ref="optionsRequest" />
<xs:element ref="optionsResponse" />
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
<xs:element ref="confResponse" /> </xs:sequence>
<xs:element ref="userRequest" /> </xs:extension>
<xs:element ref="userResponse" /> </xs:complexContent>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="usersRequest" /> <xs:element ref="usersRequest" />
<xs:element ref="usersResponse" /> </xs:sequence>
<xs:element ref="sidebarRequest" /> </xs:extension>
<xs:element ref="sidebarResponse" /> </xs:complexContent>
<xs:any namespace="##other" minOccurs="0" </xs:complexType>
maxOccurs="unbounded" processContents="lax" />
</xs:choice> <!-- userRequest -->
<xs:element name="requestID" type="xs:string" <xs:complexType name="ccmp-user-request-message-type">
minOccurs="1" maxOccurs="1" use="required"/> <xs:complexContent>
<xs:element name="confObjID" type="xs:anyURI" <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- [TODO: sidebarRequest -->
<!-- Definition of ccmp-response-message-type -->
<xs:complexType abstract="true"
name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:anyURI" <xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element ref="response-code" <xs:element ref="response-code" minOccurs="1"
minOccurs="1" maxOccurs="1" use="optional" /> maxOccurs="1" />
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType> </xs:complexType>
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="userResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- [TODO: sidebarResponse -->
<!-- response-code --> <!-- response-code -->
<xs:element name="response-code" type="response-codeType" /> <xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType"> <xs:simpleType name="response-codeType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="success"/> <xs:enumeration value="success"/>
<xs:enumeration value="pending"/>
<xs:enumeration value="modified"/> <xs:enumeration value="modified"/>
<xs:enumeration value="badRequest"/> <xs:enumeration value="badRequest"/>
<xs:enumeration value="unauthorized"/> <xs:enumeration value="unauthorized"/>
<xs:enumeration value="forbidden"/> <xs:enumeration value="forbidden"/>
<xs:enumeration value="objectNotFound"/> <xs:enumeration value="objectNotFound"/>
<xs:enumeration value="operationNotAllowed"/> <xs:enumeration value="operationNotAllowed"/>
<xs:enumeration value="deleteFailedParent"/> <xs:enumeration value="deleteFailedParent"/>
<xs:enumeration value="changeFailedProtected"/> <xs:enumeration value="modifyFailedProtected"/>
<xs:enumeration value="requestTimeout"/> <xs:enumeration value="requestTimeout"/>
<xs:enumeration value="serverInternalError"/> <xs:enumeration value="serverInternalError"/>
<xs:enumeration value="notImplemented"/> <xs:enumeration value="notImplemented"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- optionsRequest --> <!-- blueprintsResponse -->
<xs:element name="optionsRequest" type="optionsRequestType" /> <xs:element name="blueprintsResponse"
type="blueprintsResponseType" />
<xs:complexType name="optionsRequestType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element ref="namespace"
minOccurs="1" maxOccurs="1" /> minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- optionsResponse --> <xs:element name="namespace">
<xs:simpleType>
<xs:restriction base="xs:string" />
</xs:simpleType>
</xs:element>
<xs:element name="optionsResponse" type="optionsResponseType" /> <!-- confsResponse -->
<xs:complexType name="optionsResponseType"> <xs:element name="confsResponse"
type="confsResponseType" />
<xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element ref="namespace" <xs:element ref="namespace"
minOccurs="1" maxOccurs="unbounded" /> minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:simpleType name="namespace">
<xs:restriction base="xs:anyURI" />
</xs:simpleType>
<!-- confRequest --> <!-- confRequest -->
<xs:element name="confRequest" type="confRequestType" /> <xs:element name="confRequest"
type="confRequestType" />
<xs:complexType name="confRequestType"> <xs:complexType name="confRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="conference-info" type="dm:conference-info" minOccurs="1"
maxOccurs="1" />
<xs:element name="confInfo"
type="dm:conference-info"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- confResponse -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponsetType"> <xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="conference-info" type="dm:conference-info" minOccurs="1"
maxOccurs="1" />
<xs:element name="confInfo"
type="dm:conference-info"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- userRequest --> <!-- userRequest -->
<xs:element name="userRequest" type="userRequestType" /> <xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType"> <xs:complexType name="userRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="user" type="dm:user" minOccurs="1"
maxOccurs="1" />
<xs:element name="userInfo"
type="dm:user"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- userResponse --> <!-- userResponse -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse"
type="userResponseType" />
<xs:complexType name="userResponsetType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="user" type="dm:user" minOccurs="1"
axOccurs="1" />
<xs:element name="userInfo"
type="dm:conference-info"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- usersRequest --> <!-- usersRequest -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersRequest"
type="usersRequestType" />
<xs:complexType name="usersRequestType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="users" type="dm:users" minOccurs="0"/> minOccurs="1"
maxOccurs="1" />
<xs:element name="usersInfo"
type="dm:users"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- confResponse -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse"
type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation"
minOccurs="1" maxOccurs="1" /> type="operationType"
<xs:element name="users" type="dm:users" minOccurs="0"/> minOccurs="1"
maxOccurs="1" />
<xs:element name="usersInfo"
type="dm:users"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- operationType --> <!-- operationType -->
<xs:simpleType name="operationType"> <xs:simpleType name="operationType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/> <xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/> <xs:enumeration value="create"/>
<xs:enumeration value="change"/> <xs:enumeration value="change"/>
<xs:enumeration value="delete"/> <xs:enumeration value="delete"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Figure 8 Figure 15
13. WSDL Definition
The following provides the WSDL definition for conference control and
manipulation, using the the XML schema defined in Section 12 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:ccmp="urn:ietf:params:xml:ns:ccmp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp">
<xs:import 13. Managing notifications
namespace="urn:ietf:params:xml:ns:xcon:ccmp"
schemaLocation="ccmp.xsd"/>
<message name="CCMPRequestMessage"> This section is still "Under Construction" and currently contains
<part name="body" element="ccmp:request"/> some views on handling notifications.
</message>
<message name="CCMPReponseMessage">
<part name="body" element="ccmp:response"/>
</message>
<wsdl:portType name="CCMPPortType"> One proposal is to stick with SIP notification. Another alternative,
<wsdl:operation name="confOperation" parameterOrder="body"> which is commonly done in other web-based systems, is a "call back",
<wsdl:input message="tns:CCMPRequestMessage"/> i.e., the CCMP client provides the conference server with an HTTP URL
<wsdl:output message="tns:CCMPResponseMessage"/> which is invoked when a change occurs. This is apparently how most
</wsdl:operation> credit card shopping cards work, having implemented one. This works
</wsdl:portType> well for our scenario since a CCMP "client" is likely to be a web
server that provides the graphical HTML user interface and uses CCMP
as the backend to talk to the conference server. In that particular
case, there doesn't seem to be a problem of having both models. PC-
based clients behind NATs would provide a SIP event URI, web servers
would probably find the HTTP model much easier to program with.
<wsdl:binding name="ccpSoapBinding" type="tns:CCMPPortType"> Another option being considered is BOSH
<wsdlsoap:binding style="rpc" (http://xmpp.org/extensions/xep-0124.html), which is basically an
transport="http://schemas.xmlsoap.org/soap/http"/> extension to XMPP designed with the following aim: "...a transport
<wsdl:operation name="confOperation"> protocol that emulates a bidirectional stream between two entities
<wsdlsoap:operation soapAction=""/> (such as a client and a server) by efficiently using multiple
<wsdl:input> synchronous HTTP request/response pairs without requiring the use of
<wsdlsoap:body polling or asynchronous chunking."
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"> A final consideration (under discussion only) is basic XMPP.
<wsdl:port binding="tns:ccpSoapBinding" name="CCMPPortType">
<wsdlsoap:address location="http://www.example.com"/>
</wsdl:port>
</wsdl:service>
</definitions> 14. Role based access control
Figure 9 Editors' Note: this section is also under construction. This topic
is planned to be described in a separate document that will be
reference here. XACML is the current proposed direction for which
the authors would like feedback.
14. IANA Considerations 15. IANA Considerations
This document registers a new XML namespace, a new XML schema, and This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema. This document also defines registries the MIME type for the schema. This document also registers the
for the CCMP operation types and response codes. "XCON" Application Service tag and the "CCMP" Application Protocol
tag. This document also defines registries for the CCMP operation
types and response codes.
14.1. URN Sub-Namespace Registration 15.1. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
""urn:ietf:params:xml:ns:xcon:ccmp"". ""urn:ietf:params:xml:ns:xcon:ccmp"".
URI: "urn:ietf:params:xml:ns:xcon:ccmp" URI: "urn:ietf:params:xml:ns:xcon:ccmp"
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Registrant Contact: IETF, XCON working group, (xcon@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
skipping to change at page 35, line 23 skipping to change at page 47, line 5
<body> <body>
<h1>Namespace for CCMP Messages</h1> <h1>Namespace for CCMP Messages</h1>
<h2>urn:ietf:params:xml:ns:xcon:ccmp</h2> <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
14.2. XML Schema Registration 15.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon:ccmp
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 12 of this document. Section 12 of this document.
14.3. MIME Media Type Registration for 'application/ccmp+xml' 15.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type. This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: ccmp+xml MIME subtype name: ccmp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
skipping to change at page 36, line 25 skipping to change at page 48, line 5
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml. described there also apply to application/ccmp+xml.
14.4. CCMP Protocol Registry 15.4. DNS Registrations
Section 15.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in
Section 15.4.2, is used to identify an XCON server that understands
the CCMP protocol.
15.4.1. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag
for XCON, as mandated by [RFC3958].
Application Service Tag: XCON
Intended usage: Identifies a server that supports centralized
conferencing.
Defining publication: RFCXXXX
Contact information: The authors of this document
Author/Change controller: The IESG
15.4.2. Registration of a Location Server Application Protocol Tag for
HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol.
Applicable Service Tag(s): XCON
Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX
Contact Information: The authors of this document
Author/Change Controller: The IESG
15.5. CCMP Protocol Registry
This document requests that the IANA create a new registry for the This document requests that the IANA create a new registry for the
CCMP protocol including an initial registry for operation types and CCMP protocol including an initial registry for operation types and
response codes. response codes.
14.4.1. CCMP Message Types 15.5.1. CCMP Message Types
The CCMP messages are described in Section 8 and defined in the XML The CCMP messages are described in Section 8 and defined in the XML
schema in Section 12. The following summarizes the requested schema in Section 12. The following summarizes the requested
registry: registry:
Related Registry: CCMP Message Types Registry Related Registry: CCMP Message Types Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New CCMP message types are Registration/Assignment Procedures: New CCMP message types are
allocated on a specification required basis. allocated on a specification required basis.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following initial CCMP message types: This section pre-registers the following initial CCMP message types:
optionsRequest: Used by a conference control client to query a blueprintsRequest: Used by a conference control client to query a
conferencing system for its capabilities. conferencing system for its capabilities, in terms of available
conference blueprints.
optionsResponse: The optionsResponse returns a list of Blueprints blueprintsResponse: The optionsResponse returns a list of Blueprints
supported by the specific conference server. supported by the specific conference server.
confsRequest: Used by a conference control client to query a
conferencing system for its scheduled/active conferences.
confsResponse: The confsResponse returns the list of the currently
activated/scheduled conferences at the server.
confRequest: The confRequest is used to create a conference object confRequest: The confRequest is used to create a conference object
and/or to request an operation on the conference object as a and/or to request an operation on the conference object as a
whole. whole.
confResponse: The confResponse indicates the result of the operation confResponse: The confResponse indicates the result of the operation
on the conference object as a whole. on the conference object as a whole.
userRequest: The userRequest is used to request an operation on the userRequest: The userRequest is used to request an operation on the
"user" element in the conference object. "user" element in the conference object.
userResponse: The userResponse indicates the result of the requested userResponse: The userResponse indicates the result of the requested
operation on the "user" element in the conference object. operation on the "user" element in the conference object.
usersRequest This usersRequest is used to manipulate the "users" usersRequest This usersRequest is used to manipulate the "users"
skipping to change at page 37, line 22 skipping to change at page 50, line 4
userRequest: The userRequest is used to request an operation on the userRequest: The userRequest is used to request an operation on the
"user" element in the conference object. "user" element in the conference object.
userResponse: The userResponse indicates the result of the requested userResponse: The userResponse indicates the result of the requested
operation on the "user" element in the conference object. operation on the "user" element in the conference object.
usersRequest This usersRequest is used to manipulate the "users" usersRequest This usersRequest is used to manipulate the "users"
element in the conference object, including parameters such as the element in the conference object, including parameters such as the
allowed-users-list, join-handling, etc. allowed-users-list, join-handling, etc.
usersResponse: This usersResponse indicates the result of the usersResponse: This usersResponse indicates the result of the
request to manipulate the "users" element in the conference request to manipulate the "users" element in the conference
object. object.
sidebarRequest: This sidebarRequest is used to retrieve the sidebarRequest: This sidebarRequest is used to retrieve the
information related to a sidebar or to create, change or delete a information related to a sidebar or to create, change or delete a
specific sidebar. specific sidebar.
sidebarResponse: This sidebarResponse indicates the result of the sidebarResponse: This sidebarResponse indicates the result of the
sidebarRequest. sidebarRequest.
14.4.2. CCMP Response Codes 15.5.2. CCMP Response Codes
The following summarizes the requested registry for CCMP Response The following summarizes the requested registry for CCMP Response
codes: codes:
Related Registry: CCMP Response Code Registry Related Registry: CCMP Response Code Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New response codes are allocated Registration/Assignment Procedures: New response codes are allocated
on a first-come/first-serve basis with specification required. on a first-come/first-serve basis with specification required.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
skipping to change at page 38, line 23 skipping to change at page 51, line 4
policies, etc.) policies, etc.)
deleteFailedParent: This code indicates that the conferencing system deleteFailedParent: This code indicates that the conferencing system
cannot delete the specific conference object because it is a cannot delete the specific conference object because it is a
parent for another conference object. parent for another conference object.
changeFailedProtected: This code indicates that the target changeFailedProtected: This code indicates that the target
conference object cannot be changed (e.g., due to policies, roles, conference object cannot be changed (e.g., due to policies, roles,
privileges, etc.). privileges, etc.).
requestTimeout: This code indicates that the request could not be requestTimeout: This code indicates that the request could not be
processed within a reasonable time, with the time specific to a processed within a reasonable time, with the time specific to a
conferencing system implementation. conferencing system implementation.
serverInternalError: This code indicates that the conferencing serverInternalError: This code indicates that the conferencing
system experienced some sort of internal error. system experienced some sort of internal error.
notImplemented: This code indicates that the specific operation is notImplemented: This code indicates that the specific operation is
not implemented on that conferencing system. not implemented on that conferencing system.
15. Security Considerations 16. Security Considerations
Access to conference control functionality needs to be tightly Access to conference control functionality needs to be tightly
controlled to keep attackers from disrupting conferences, adding controlled to keep attackers from disrupting conferences, adding
themselves to conferences or engaging in theft of services. themselves to conferences or engaging in theft of services. In the
Implementors need to deploy standard HTTP and SOAP authentication and case of a RESTful implementation of the CCMP, implementors need to
authorization mechanisms. Since conference information may contain deploy standard HTTP authentication and authorization mechanisms.
secrets such as participant lists and dial-in codes, all conference Since conference information may contain secrets such as participant
control information SHOULD be carried over TLS (HTTPS). lists and dial-in codes, all conference control information SHOULD be
carried over TLS (HTTPS).
16. Acknowledgments 17. Acknowledgments
The authors appreciate the feedback provided by Dave Morgan and The authors appreciate the feedback provided by Dave Morgan, Pierre
Pierre Tane. Tane, Lorenzo Miniero and Tobia Castaldi
17. References 18. Changes since last Version
17.1. Normative References NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
The following summarizes the changes between the WG 00 and the 01:
1. Changed the basic approach from using SOAP to REST - the
fundamentals are the same in terms of schema, basic operations.
This impacted most sections, in particular introduction and
motivation.
2. Added new request types - blueprintsRequest, blueprintRequest and
confsRequest. The first replaces the optionsRequest and the
latter allows the client to get a list of all active conferences.
3. Merged all requests into the basic operations table. Added
summary of RESTful examples (referenced by the basic operations
table.
4. Added examples showing RESTful approach - i.e., HTTP methods for
message exchange.
5. Removed requestID from the schema (it should be handle by the
transport - e.g., HTTP). Updated schema (based on current
prototype - it still needs another revision.
6. Added placeholders for Notifications and Role Based Access
Control.
7. Added some text for discovery using DNS (including IANA
registrations)
8. Updated References: updated XCON FW RFC, SOAP/W3C moved to
informational section.
19. References
19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[W3C.CR-wsdl20-20051215] [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Centralized Conferencing", RFC 5239, June 2008.
"Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005.
[W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Hadley, M., Moreau, J., 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>.
[W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Moreau, J., Nielsen, H., Hadley, M., and
M. Gudgin, "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>.
[I-D.ietf-xcon-framework]
Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-11
(work in progress), April 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and R. Even, Novo, O., Camarillo, G., Morgan, D., Even, R., and J.
"Conference Information Data Model for Centralized Urpalainen, "Conference Information Data Model for
Conferencing (XCON)", draft-ietf-xcon-common-data-model-11 Centralized Conferencing (XCON)",
(work in progress), June 2008. draft-ietf-xcon-common-data-model-12 (work in progress),
October 2008.
17.2. Informative References 19.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004. Telephony Services", RFC 3880, October 2004.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-00 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
February 2008. September 2008.
[I-D.royer-calsch-xcal] [I-D.royer-calsch-xcal]
Royer, D., "iCalendar in XML Format (xCal-Basic)", Royer, D., "iCalendar in XML Format (xCal-Basic)",
draft-royer-calsch-xcal-03 (work in progress), draft-royer-calsch-xcal-03 (work in progress),
October 2005. October 2005.
[W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., 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>.
[W3C.REC-soap12-part2-20030624]
Moreau, J., Mendelsohn, N., Hadley, M., Nielsen, H., and
M. Gudgin, "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>.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
Avaya Avaya
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: cboulton@avaya.com
Simon Pietro Romano Simon Pietro Romano
 End of changes. 188 change blocks. 
543 lines changed or deleted 1169 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/