draft-ietf-xcon-ccmp-01.txt   draft-ietf-xcon-ccmp-02.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: May 7, 2009 Avaya Expires: September 11, 2009 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
November 3, 2008 March 10, 2009
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-01 draft-ietf-xcon-ccmp-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 7, 2009. This Internet-Draft will expire on September 11, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) can create, The Centralized Conferencing Manipulation Protocol (CCMP) can create,
retrieve, change and delete objects describing a centralized retrieve, change and delete objects describing a centralized
conference, such as state and capabilities of the conference, conference, such as state and capabilities of the conference,
participants, and their roles. The conference information is participants, and their roles. The conference information is
contained in XML documents and fragments conforming to the contained in XML documents and fragments conforming to the
centralized conferencing data model schema. CCMP is a state-less centralized conferencing data model schema. CCMP is a state-less
client-server protocol based on a request/response model. client-server protocol based on a request/response model.
skipping to change at page 2, line 16 skipping to change at page 2, line 25
respond to the client with the conference information. respond to the client with the conference information.
This document also discusses options for using existing notification This document also discusses options for using existing notification
protocols to inform conference client about the changes in the state protocols to inform conference client about the changes in the state
of a conference during its entire lifetime. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Rationale and Motivation . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. System Architecture . . . . . . . . . . . . . . . . . . . . . 7 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 8
6. Conference Object and User Identifiers . . . . . . . . . . . . 9 6. Conference Object and User Identifiers . . . . . . . . . . . . 10
6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 9 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 10
6.2. Conference Users and Participants . . . . . . . . . . . . 9 6.2. Conference Users and Participants . . . . . . . . . . . . 10
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 10 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 12
7.1. Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Implementation Approach . . . . . . . . . . . . . . . . . 13
7.2. Create . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. CCMP protocol messages . . . . . . . . . . . . . . . . . . 13
7.3. Change . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.1. CCMP Request Message . . . . . . . . . . . . . . . . . 13
7.4. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.2. CCMP Response Message . . . . . . . . . . . . . . . . 14
8. Protocol Operations on Conference Objects . . . . . . . . . . 13 7.2.2.1. CCMP Response Codes . . . . . . . . . . . . . . . 15
8.1. Locating a Conference Control Server . . . . . . . . . . . 14 7.2.3. Detailed CCMP Messages . . . . . . . . . . . . . . . . 16
8.2. Constructing a CCMP Request . . . . . . . . . . . . . . . 15 7.2.3.1. blueprintsRequest and blueprintsResponse
8.2.1. blueprintsRequest . . . . . . . . . . . . . . . . . . 16 messages . . . . . . . . . . . . . . . . . . . . . 20
8.2.2. confsRequest . . . . . . . . . . . . . . . . . . . . . 16 7.2.3.2. confsRequest and confsResponse messages . . . . . 21
8.2.3. Operations Requests . . . . . . . . . . . . . . . . . 16 7.2.3.3. blueprintRequest and blueprintResponse messages . 22
8.3. Handling a CCMP Response . . . . . . . . . . . . . . . . . 18 7.2.3.4. confRequest and confResponse messages . . . . . . 25
8.3.1. blueprintsResponse . . . . . . . . . . . . . . . . . . 20 7.2.3.5. usersRequest and usersResponse messages . . . . . 28
8.3.2. confsResponse . . . . . . . . . . . . . . . . . . . . 20 7.2.3.6. userRequest and userResponse messages . . . . . . 31
8.3.3. Operation Responses . . . . . . . . . . . . . . . . . 21 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse
9. Managing sidebars . . . . . . . . . . . . . . . . . . . . . . 25 messages . . . . . . . . . . . . . . . . . . . . . 33
9.1. Sidebars by value . . . . . . . . . . . . . . . . . . . . 25 7.2.3.8. sidebarByValRequest and sidebarByValResponse
9.2. Sidebars by reference . . . . . . . . . . . . . . . . . . 26 messages . . . . . . . . . . . . . . . . . . . . . 34
10. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 26 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse
10.1. Operation Parameter . . . . . . . . . . . . . . . . . . . 26 messages . . . . . . . . . . . . . . . . . . . . . 36
10.2. ConfObjID Parameter . . . . . . . . . . . . . . . . . . . 26 7.2.3.10. sidebarByRefRequest and sidebarByRefResponse
10.3. ConfUserID Parameter . . . . . . . . . . . . . . . . . . . 27 messages . . . . . . . . . . . . . . . . . . . . . 37
10.4. ResponseCode Parameter . . . . . . . . . . . . . . . . . . 27 8. A complete example of the CCMP in action . . . . . . . . . . . 40
10.5. Blueprints Parameter . . . . . . . . . . . . . . . . . . . 28 8.1. Alice retrieves the available blueprints . . . . . . . . . 40
10.6. Conference-info Parameter . . . . . . . . . . . . . . . . 28 8.2. Alice gets detailed information about a specific
10.7. User Parameter . . . . . . . . . . . . . . . . . . . . . . 29 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 43
10.8. Users Parameter . . . . . . . . . . . . . . . . . . . . . 29 8.3. Alice creates a new conference through a cloning
10.9. Sidebar Parameters . . . . . . . . . . . . . . . . . . . . 29 operation . . . . . . . . . . . . . . . . . . . . . . . . 45
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. Alice updates conference information . . . . . . . . . . . 47
11.1. HTTP methods for realizing a RESTful CCMP . . . . . . . . 30 8.5. Alice inserts a list of users in the conference object . . 49
11.2. CCMP Detailed Message Body Examples . . . . . . . . . . . 33 8.6. Alice joins the conference . . . . . . . . . . . . . . . . 51
11.2.1. Creating a New Conference . . . . . . . . . . . . . . 33 8.7. Alice adds a new user to the conference . . . . . . . . . 52
11.2.2. Creating a New Conference User . . . . . . . . . . . . 36 9. Locating a Conference Control Server . . . . . . . . . . . . . 55
11.2.3. Adding a User to a Conference . . . . . . . . . . . . 36 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Managing notifications . . . . . . . . . . . . . . . . . . . . 69
13. Managing notifications . . . . . . . . . . . . . . . . . . . . 45 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
14. Role based access control . . . . . . . . . . . . . . . . . . 46 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 70
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 70
15.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 71
15.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 72
15.3. MIME Media Type Registration for 'application/ccmp+xml' . 47 12.4.1. Registration of a Location Server Application
15.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 48 Service Tag . . . . . . . . . . . . . . . . . . . . . 72
15.4.1. Registration of a Location Server Application 12.4.2. Registration of a Location Server Application
Service Tag . . . . . . . . . . . . . . . . . . . . . 48 Protocol Tag for HELD . . . . . . . . . . . . . . . . 72
15.4.2. Registration of a Location Server Application 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 73
Protocol Tag for HELD . . . . . . . . . . . . . . . . 48 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 73
15.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 49 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 74
15.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 49 13. Security Considerations . . . . . . . . . . . . . . . . . . . 76
15.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 50 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
16. Security Considerations . . . . . . . . . . . . . . . . . . . 51 15. Changes since last Version . . . . . . . . . . . . . . . . . . 78
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
18. Changes since last Version . . . . . . . . . . . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . . 79
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . . 79
19.1. Normative References . . . . . . . . . . . . . . . . . . . 52 Appendix A. Appendix A: Other protocol models and transports
19.2. Informative References . . . . . . . . . . . . . . . . . . 52 considered for CCMP . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 81
Intellectual Property and Copyright Statements . . . . . . . . . . 55 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 83
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON FW) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON FW introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing 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 authenticated and authorized users to create, this document allows authenticated and authorized users to create,
manipulate and delete conference objects. Operations on conferences manipulate and delete conference objects. Operations on conferences
include 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 the client-server model within the XCON FW, with the The CCMP implements the client-server model within the XCON
conferencing client and conference control server acting as client Framework, with the conferencing client and conference control server
and server, respectively. CCMP is an instance of conference control acting as client and server, respectively. The CCMP uses HTTP
protocol (CCP). [RFC2616] as the protocol to transfer the CCMP requests and
responses, which contain the domain-specific XML-encoded data objects
CCMP can be mapped into the CRUD (Create, Read, Update, Delete) defined in the Conference Information Data Model for Centralized
design pattern. The basic CRUD operations are used to manipulate Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model].
conference objects, which are XML documents containing the Other protocol models such as the use of a REST (REpresentational
information characterizing a specified conference instance, be it an State Transfer) architectural style [REST] were considered. However,
active conference or a conference blueprint used by the conference the CCMP is a request/response protocol with new or updated data
server to create new conference instances through a simple clone relevant to the specific conference object returned in the response.
operation. Whereas, a REST approach involves singular/monolithic operations on
data, with the response typically indicating either success or
CCMP can use a general-purpose protocol such as HTTP [RFC2616] to failure, rather than providing updated data based on a specific
transfer domain-specific XML-encoded data objects defined in the operation, thus, it was not considered a good choice. Details of the
Conference Information Data Model for Centralized Conferencing use of REST for the CCMP, as well as other protocols considered
[I-D.ietf-xcon-common-data-model]. (e.g., SOAP) are provided in Appendix A.
CCMP follows the well-known REST (REpresentational State Transfer)
architectural style [REST] This document describes how the CCMP
specification maps onto the REST philosophy, by specifying resource
URIs, resource formats, methods supported at each URI and status
codes that have to be returned when a certain method is invoked on a
specific URI.
Section 4 motivates the design of CCMP, followed by the system Section 4 provides an overview of the design of the CCMP, followed by
architecture in Section 5. Section 6 discusses the primary keys in the system architecture in Section 5. Section 6 discusses the
the conference object carried in the protocol. An overview of the primary keys in the conference object carried in the protocol. An
operations associated with each protocol request and response is overview of the operations associated with each protocol request and
provided in Section 7, with the sequence of protocol requests and response is provided in Section 7. A complete example of the
responses discussed in Section 8 and examples provided in Section 11. operation of the CCMP, describing a typical call flow associated with
The protocol parameters are detailed in Section 10. Section 12 conference creation and manipulation, is provided in Section 8.
provides the XML schema. Section 10 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
skipping to change at page 5, line 22 skipping to change at page 6, line 14
3. Terminology 3. Terminology
In additon to the terms defined in the Framework for Centralized In additon to the terms defined in the Framework for Centralized
Conferencing [RFC5239], this document uses the following terms and Conferencing [RFC5239], this document uses the following terms and
acronyms: acronyms:
CRUD: CRUD stands for Create/Read/Update/Delete and indicates a CRUD: CRUD stands for Create/Read/Update/Delete and indicates a
design pattern supporting creating, retrieving, updating and design pattern supporting creating, retrieving, updating and
destroying objects. destroying objects.
REST: REpresentational State Transfer (REST) is an architectural REST: REpresentational State Transfer (REST) is an architectural
style, i.e., a coordinated set of architectural constraints. REST style, i.e., a coordinated set of architectural constraints. REST
is based on the consideration that a software architecture can is based on the consideration that a software architecture can
often be specified as an appropriate configuration of components, often be specified as an appropriate configuration of components,
data and connectors, all coordinated through constraining their data and connectors, all coordinated through constraining their
mutual relationships. Coordination and constraints help achieve a mutual relationships. Coordination and constraints help achieve a
desired set of architectural properties. [REST] desired set of architectural properties. [REST]
SOAP: Simple Object Access Protocol defined in SOAP: Simple Object Access Protocol defined in
[W3C.REC-soap12-part1-20030624] and [W3C.REC-soap12-part1-20030624] and
[W3C.REC-soap12-part2-20030624]. [W3C.REC-soap12-part2-20030624].
W3C: World Wide Web Consortium, the organization that developed the
SOAP and WSDL specifications referenced within this document.
4. Rationale and Motivation 4. Protocol Overview
This document specifies the basic operations that can create, This document specifies the basic operations that can create,
retrieve, modify and delete conference-related information in a retrieve, modify and delete conference-related information in a
centralized conference. The core set of objects includes conference centralized conference. The core set of objects includes conference
blueprints, the conference itself, users, and sidebars. blueprints, the conference itself, users, and sidebars.
The operations on these objects can be implemented in at least two Each update operation in the protocol model is atomic and either
different ways, namely as remote procedure calls and by defining succeeds or fails as a whole. Thus, a server has to first check all
resources. A remote procedure call (RPC) mechanism could use SOAP parameters, before making any changes to the internal representation
(Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC of the conference object. For example, it would be undesirable to
-soap12-part2-20030624]), where conferences and the other objects are change the <subject> of the conference, but then detect an invalid
modeled as services with associated operations. Conferences and URI in one of the <service-uris> and abort the remaining updates.
other objects are selected by their own local identifiers, such as
email-like names for users. This approach has the advantage that it
can easily define atomic operations that have well-defined error
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, Because multiple clients can modify the same conference objects,
clients need to obtain the current object and then update the whole clients need to obtain the current object and then update the whole
object. object.
Editor's Note: Do we need locking, using WebDAV or floor control? 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 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 modify some other parameter. For example, A changes the subject, B
adds the a service URI. 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 CCMP "blueprintsRequest" message 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.
skipping to change at page 7, line 23 skipping to change at page 8, line 7
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 and new URIs. 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 XCON framework . Figure 1 depicts a subset of the
depicts a subset of the 'Conferencing System Logical Decomposition' 'Conferencing System Logical Decomposition' architecture from the
architecture from the framework for centralized conferencing XCON framework document. It illustrates the role that CCMP assumes
document. It illustrates the role that CCMP assumes within the within the overall centralized architecture.
overall centralized architecture.
........................................................ ........................................................
. Conferencing System . . Conferencing System .
. . . .
. +---------------------------------------+ . . +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | . . | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | . . +-+-------------------------------------+ | .
. | C O N F E R E N C E O B J E C T | | . . | C O N F E R E N C E O B J E C T | | .
. +-+-------------------------------------+ | | . . +-+-------------------------------------+ | | .
. | C O N F E R E N C E O B J E C T | | | . . | C O N F E R E N C E O B J E C T | | | .
skipping to change at page 8, line 30 skipping to change at page 8, line 37
. v . . v .
. +-------------------+ . . +-------------------+ .
. | Conference Control| . . | Conference Control| .
. | Server | . . | Server | .
. +-------------------+ . . +-------------------+ .
. ^ . . ^ .
.........................|.............................. .........................|..............................
| |
|Conference |Conference
|Control |Control
|Manipulation
|Protocol |Protocol
| |
|
.........................|.............................. .........................|..............................
. V . . V .
. +----------------+ . . +----------------+ .
. | Conference | . . | Conference | .
. | Control | . . | Control | .
. | Client | . . | Client | .
. +----------------+ . . +----------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
........................................................ ........................................................
Figure 1: Conference Client Interaction Figure 1: Conference Client Interaction
CCMP serves as the Conference Control Protocol, allowing the CCMP serves as the Conference Control Protocol, allowing the
conference control client to interface with the conference object conference control client to interface with the conference object
maintained by the conferencing system, as represented in Figure 1. maintained by the conferencing system, as represented in Figure 1.
Conference Control is one part of functionality for advanced Conference Control is one part of functionality for advanced
conferencing supported by a conferencing client. Other functions are conferencing supported by a conferencing client. Other functions are
discussed in the framework for centralized conferencing document and discussed in the XCON framework and related documents.
related documents.
6. Conference Object and User Identifiers 6. Conference Object and User Identifiers
This section provides an overview of the conference object and This section provides an overview of the conference object and
conference users which are key protocol elements for creating the conference users which are key protocol elements for creating the
CCMP requests and responses. The identifiers used in CCMP for the CCMP requests and responses. The identifiers used in CCMP for the
conference object (XCON-URI) and conference user (XCON-USERID) are conference object (XCON-URI) and conference user (XCON-USERID) are
introduced in the XCON framework and defined in the XCON data model introduced in the XCON framework and defined in the XCON data model
[I-D.ietf-xcon-common-data-model]. [I-D.ietf-xcon-common-data-model].
skipping to change at page 9, line 49 skipping to change at page 10, line 48
functions and do not contribute or receive media. Users are added functions and do not contribute or receive media. Users are added
one user at a time to simplify error reporting. Users are inherited one user at a time to simplify error reporting. Users are inherited
as well, so that it is easy to set up a conference that has the same as well, so that it is easy to set up a conference that has the same
set of participants or a common administrator. The Conference set of participants or a common administrator. The Conference
Control Server creates individual users, assigning them a unique Control Server creates individual users, assigning them a unique
Conference User Identifier (XCON-USERID). Conference User Identifier (XCON-USERID).
A variety of elements defined in the common <conference-info> element A variety of elements defined in the common <conference-info> element
as specified in the XCON data model are used to determine how a as specified in the XCON data model are used to determine how a
specific user expects and is allowed to join a conference as a specific user expects and is allowed to join a conference as a
participant, or users with specific privileges (e.g., observer). For participant or as a user with specific privileges (e.g., observer).
example, the <method> attribute defines how the caller joins the For example, the <method> attribute defines how the caller joins the
conference, with a set of defined XML elements, namely <dial-in> for conference, with a set of defined XML elements, namely <dial-in> for
users that are allowed to dial in and <dial-out> for users that the users that are allowed to dial in and <dial-out> for users that the
conference focus will be trying to reach. <dial-in> is the default. conference focus will be trying to reach. <dial-in> is the default.
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
skipping to change at page 10, line 32 skipping to change at page 12, line 7
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 CCMP is a client-server, XML-based, stateless protocol, which has
to provide a conference control client with the ability to carry out been specifically conceived to provide users with the necessary means
operations on a conference object as a whole and on specific elements for the creation, retrieval, modification and deletion of conference
within a conference object. This section describes the four basic objects. Conference-related information is encapsulated into CCMP
operations on a conference object: retrieve, create, change and messages in the form of documents or document fragments compliant
delete. The recommended HTTP method for each of the basic operations with the XCON data model representation.
is described. The XCON-URI as discussed in Section 6.1 is the
primary target for each of these operations. The normative protocol
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 The main operations provided by CCMP belong in four general
categories:
The "retrieve" operation is used by a client to query a system for a create: for the creation of a conference, a conference user, a
specific template in the form of a blueprint prior to the creation of sidebar, or a blueprint.
a conference. In this case, the "retrieve" operation often follows a
"blueprintsRequest" operation, although a conferencing control client
may be pre-configured to perform the "retrieve" operation on a
specific blueprint.
The "retrieve" operation is also used to get the current retrieve: to get information about the current state of either a
representation of a specific conference object (or specific conference object (be it an actual conference or a blueprint, or a
parameters in the conference object) for a conference reservation or sidebar) or a conference user. A retrieve operation can also be
an active conference. The unique conference identifier (XCON-URI) is used to obtain the XCON-URIs of the active conferences and/or
included in the CCMP request. blueprints available at the server.
The "retrieve" operation returns the XML document describing the update: to modify the current features of a specified conference or
conference object in its current state including all inherited values conference user.
or the specific parameters per the specific request type. Elements
may be marked by attributes, in particular, whether they are specific
to this instance or have been inherited from the parent node.
In the case of a RESTful implementation of the protocol, HTTP GET delete: to remove from the system a conference object or a
MUST be used on XCON-URIs, so that clients can obtain data about conference user.
conference objects in the form of XML data model documents.
7.2. Create Thus, the main targets of CCMP operations are:
The "create" operation is used by a client to create and reserve a o conference objects associated with either active or registered
conference object or a new conference user. The creation of a conferences,
conference object can be explicit by requesting it to be created
based upon a specific blueprint, based on an existing conference
object (e.g., cloning a conference reservation or active conference
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.
When the creation of a conference object is implicit, with no o conference objects associated with blueprints,
conference object for a blueprint or existing conference specified
and no data included in the request (i.e., an "empty" request sent to
a specific conference server), the creation and reservation of the
conference instance is based on the default conference object. The
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 request with "retrieve" operation in order o conference objects associated with sidebars, both embedded in the
to obtain all the data as defined in main conference (i.e. <sidebars-by-value> elements) and external
[I-D.ietf-xcon-common-data-model] for the specific blueprint or to it (i.e. <sidebars-by-ref> elements),
existing conference object. This would allow the client to modify
the data prior to sending the request with the "create" operation.
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
existing conference object, there would be no data included in the
request. The client may later modify this data by sending a request
with a "change" operation.
When creating conferences, any XCON-URI included by the client is o <user> elements associated with conference users,
considered as the target conference object from which the new
conference is to be created. To avoid identifier collisions and to
conform to local server policy, the conference control server
typically chooses a different identifier for the newly created
conference object. The identifier is returned in the response.
In addition, the conference description MAY contain a calendar o the list of XCON-URIs related to conferences and blueprints
element, in the iCal format in XML rendition defined in CPL [RFC3880] available at the server, for which only retrieval operations are
or (preferable, if available as stable reference) xCal allowed.
[I-D.royer-calsch-xcal]. This description indicates when the
conference is active.
The "create" operation may also be used to create a new conference 7.1. Implementation Approach
user with the "userRequest" message. In this case, the
"userResponse" to this operation includes an XCON-USERID.
In the case of a RESTful implementation of the protocol, HTTP PUT There have been a number of different proposals as to the most
MUST be used to create a new object as identified by the XCON-URI or suitable implementation solution for the CCMP. A non-exhaustive
XCON-USERID. summary of the most interesting ones is provided in Appendix A. The
proposed solution for the CCMP is viewed as a good compromise amongst
the most notable past candidates and is referred to as 'HTTP single
verb transport plus CCMP body'. With this approach, CCMP is able to
take advantage of existing HTTP functionality. As with SOAP, the
CCMP uses a 'single HTTP verb' for transport (i.e. a single
transaction type for each request/response pair); this allows
decoupling CCMP messages from HTTP messages. Similarly, as with any
RESTful approach, CCMP messages are inserted directly in the body of
HTTP messages, thus avoiding any unnecessary processing and
communication burden associated with further intermediaries. With
this approach, no modification to the CCMP messages/operations is
required to use a different transport protocol.
7.3. Change The remainder of this document focuses on the selected approach. The
CCMP protocol inserts XML-based CCMP requests into the body of HTTP
POST operations and retrieves responses from the body of HTTP '200
OK' messages. CCMP messages have a MIME-type of "application/
ccmp+xml", which appears inside the "Content-Type" and "Accept"
fields of HTTP requests and responses.
The "change" operation updates the conference object as referenced by 7.2. CCMP protocol messages
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
attempts to change a parameter that is inherited from a protected
element.
During the lifetime of a conference, this operation is used by a CCMP messages are either requests or responses. The general CCMP
conference control client to manipulate a conference object. This request message is defined in Section 7.2.1. The general CCMP
includes the ability to manipulate specific elements in the response message is defined in Section 7.2.2. The details of the
conference object through element specific requests such as specific message type which is carried in the CCMP request and
"userRequest" or "sideBarRequest", etc. response messages are described in Section 7.2.3.
Upon receipt of a "change" operation, the conference control server 7.2.1. CCMP Request Message
updates the specific elements in the referenced conference object.
Object properties that are not explicitly changed, remain as-is.
This approach allows a conference control client to manipulate
objects created by another application even if the manipulating
application does not understand all object properties.
In the case of a RESTful implementation of the protocol, either HTTP A CCMP request message is comprised of the following parameters:
PATCH or HTTP POST MUST be used to change the conference object
identified by the XCON-URI.
7.4. Delete confUserId: A mandatory parameter containing the XCON-URI of the
client. This parameter is REQUIRED by the conferencing server for
system specific Authorization, Authentication and Accounting (AAA)
procedures.
This conference control operation is used to delete the current confObjId: an optional parameter containing, whenever necessary, the
representation of a conference object or a specific parameter in the XCON-URI of the target conference object;
conference object and requires the unique conference identifier specialized request message: this is specialization of the generic
(XCON-URI) be provided by the client. request message (e.g., blueprintsRequest), containing parameters
that are dependent on the specific request sent to the server, the
details of which are provided in Section 7.2.3
A request which attempts to delete a conference object that is being <xs:element name="ccmpRequest" type="ccmp-request-type" />
referenced by a child object is an error.
In case of a RESTful implementation of the protocol, HTTP DELETE MUST <!-- CCMP request definition -->
be used to delete conference objects and parameters within conference
objects identified by the XCON-URI.
8. Protocol Operations on Conference Objects <xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
The primary function of CCMP is to provide a conference control <!-- Definition of ccmp-request-message-type -->
client with the ability to carry out specific operations (Section 7)
on a conference object through the protocol requests and responses.
In case of a RESTful implementation of the protocol, the CCMP
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:
blueprintsRequest/blueprintsResponse: The blueprintsRequest is used <xs:complexType abstract="true"
to ascertain the list of blueprints available at the conference name="ccmp-request-message-type">
server. The blueprintsResponse returns a list of the requested <xs:sequence>
blueprints, in the form of XCON URIs. <xs:element name="confUserID" type="xs:string"
confsRequest/confsResponse: The confsRequest is used to ascertain minOccurs="1" maxOccurs="1" />
conference reservations and active conferences supported by the <xs:element name="confObjID" type="xs:string"
server. The confsResponse returns a list of the requested types minOccurs="0" maxOccurs="1" />
of conference objects (i.e. Conference Reservations and/or Active </xs:sequence>
Conferences) supported by the specific conference server. </xs:complexType>
blueprintRequest/blueprintResponse: The blueprintRequest is used to
request an operation on a specific blueprint.
confRequest/confResponse: The confRequest is used to request an
operation on the conference object as a whole.
userRequest/userResponse: The userRequest is used to request an
operation on the "user" element in the conference object.
[Editor's Note: we may want to add more discrete user requests/
responses as this is a very broad parameter]
usersRequest/usersResponse: This usersRequest is used to manipulate
the "users" element in the conference object, including parameters
such as the allowed-users-list, join-handling, etc.
sidebarRequest/sidebarResponse: This sidebarRequest is used to
retrieve the information related to a sidebar or to create, change
or delete a specific sidebar. [Editor's Note: the data model
defines a byVal and byRef sidebar type. Rather than define two
root operations, the preference is to have these two types
reflected by a parameter in the request.]
With respect to the above mentioned operations, we remark that the Figure 2: Structure of CCMP Request messages
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 7.2.2. CCMP Response Message
parameters as suggestions (e.g., for the "create" and "change"
operations), as noted in the object description. If the conference
control server cannot set the parameter to the values desired, it
picks the next best value, according to local policy and returns the
values selected in the response. If the client is not satisfied with
these values, it simply deletes the object.
As illustrated above, along with the protocol requests and responses A CCMP response message is comprised of the following parameters:
for manipulating the conference object, there are also querying
mechanisms ("blueprintsRequest"/"blueprintsResponse" and
"confsRequest/confsResponse") to get information about either
blueprints or scheduled/active conferences supported by the server.
Any elements with namespaces not understood by the server are to be
ignored by the server. This allows a client to include optional
elements in requests without having to tailor its request to the
capabilities of each server.
A conference client must first discover the conference control server confUserId: A mandatory parameter containing the XCON-URI of the
as described in Section 8.1. The conference control server is the client which issued the request
recipient of the CCMP requests.
8.1. Locating a Conference Control Server confObjId: An optional parameter containing the XCON-URI of the
target conference object
responseCode: A mandatory parameter containing the response code
associated with the request, chosen among the codes listed in
Section 7.2.2.1
If a conference control client is not pre-configured to use a specialized response message: This is specialization of the generic
specific conference control server for the requests, the client MUST response message, containing parameters that are dependent on the
first discover the conference control server before it can send any specific request sent to the server(e.g., blueprintsResponse), the
requests. The result of the discovery process, is the address of the details of which are provided in Section 7.2.3
server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server.
This document proposes the use of DNS to locate the conferencing <xs:element name="ccmpResponse" type="ccmp-response-type" />
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.
Section 15.4.1 defines an Application Service tag of "XCON", which is <!-- CCMP response definition -->
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 <xs:complexType name="ccmp-response-type">
use of the Application Service and Protocol tags. Iterative NAPTR <xs:sequence>
resolution is used to delegate responsibility for the conferencing <xs:element name="ccmpResponse"
service from "zonea.example.com." and "zoneb.example.com." to type="ccmp-response-message-type" />
"outsource.example.com.". </xs:sequence>
</xs:complexType>
zonea.example.com. <!-- Definition of ccmp-response-message-type -->
;; 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 <xs:complexType abstract="true"
name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1"
maxOccurs="1" />
</xs:sequence>
</xs:complexType>
Details for the "XCON" Application Service tag and the "CCMP" Figure 3: Structure of CCMP Response message
Application Protocol tag are included in Section 15.4.
8.2. Constructing a CCMP Request 7.2.2.1. CCMP Response Codes
Construction of a valid CCMP request is based upon the operations All CCMP response messages MUST include a "responseCode". The
defined in Section 7, depending upon the function and associated following summarizes the CCMP response codes:
information desired by the conference control client. The next two
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
Section 7.
8.2.1. blueprintsRequest success: Successful completion of the requested operation.
The "blueprintsRequest" is used by a client to query a system for its modified: Successful completion of the requested operation, with
capabilities in terms of types of conferences supported and isn't partial data returned in the confObjID having been modified from
targeted toward a particular conference object. Detailed information the data included in the confObjID included request, either for a
about a specific blueprint, can be subsequently obtained through the "create" or a "change" operation
blueprintRequest operation, which is used to retrieve a whole XCON
blueprint (in the form of a conference object) available at the
server.
The "blueprintsResponse" returns the XML namespaces that the server badRequest: Syntactically malformed request
understands and the namespaces to be used in responses that it
requires the client to understand. Within the conferencing system,
the namespaces correlate with blueprints, as specified in the XCON
framework. The blueprints are comprised of conference information
initialized to specific values and ranges. Each blueprint has a
corresponding XCON-URI.
8.2.2. confsRequest objectNotFound: Target object missing at the server
The "confsRequest" is used by a client to query a system for unauthorized: User not allowed to perform the required operation
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 forbidden: Operation not allowed (e.g., cancellation of a blueprint)
conferences currently hosted by the server.
8.2.3. Operations Requests forbiddenDeleteParent: Cancel operation failed since the target
object is a parent of child objects which depend on it, or because
it effects, based on the 'parent-enforceable' mechanism, the
corresponding element in a child object
Construction of other valid CCMP requests is based upon the forbiddenChangeProtected: Update refused by the server because the
operations defined in Section 7, depending upon the function and target element cannot be modified due to its implicit dependence
associated information desired by the conference control client. The on the value of a parent object ('parent-enforceable' mechanism)
following table summarizes specific request type and processing for
each of the "operations". A value of "N/A" indicates the specific
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: requestTimeout: The time required to serve the request has exceeded
the envisaged service threshold
1. Sidebars need additional consideration - e.g., due to the byVal serverInternalError: The server cannot complete the required service
and byRef options, it's messy. Operations approach may need due to a system internal error
additional consideration (or we need separate request types).
notImplemented: Operation envisaged in the protocol, but not
implemented in the contacted server.
7.2.3. Detailed CCMP Messages
Based on the request and response message structures described in
Section 7.2.1 and Section 7.2.2, the following summarizes the
specialized CCMP request/response types described in this document:
1. blueprintsRequest/blueprintsResponse
2. confsRequest/confsResponse
3. blueprintRequest/blueprintResponse
4. confRequest/confResponse
5. usersRequest/usersResponse
6. userRequest/userResponse
7. sidebarsByValRequest/sidebarsByValResponse
8. sidebarsByRefRequest/sidebarsByRefResponse
9. sidebarByValRequest/sidebarByValResponse
10. sidebarByRefRequest/sidebarByRefResponse
These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 7 to manipulate the conference data. Table 1
summarizes the CCMP operations and corresponding actions that are
valid for a specific CCMP request type, noting that neither the
blueprintsRequest/blueprints/Response or confsRequest/ConfsResponse
require an "operation" parameter. The corresponding response MUST
contain the same operation. Note that some entries are labeled "N/A"
indicating the operation is invalid for that request type. In the
case of an "N/A*", the operation MAY be allowed for specific
privileged users or system administrators, but is not part of the
functionality included in this document.
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Change | Delete | | Operation | Retrieve | Create | Update | Delete |
| (HTTP method) | (GET) | (PUT) | (PATCH or | (DELETE) | | ------------- | | | | |
| ------------- | | | POST) | | | -Request Type | | | | |
| Request Type | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprintsReq | Gets list | N/A | N/A | N/A | | blueprintsReq | Get list | N/A | N/A | N/A |
| uest | of | | | | | uest | of | | | |
| | available | | | |
| | blueprints | | | | | | blueprints | | | |
| | . | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest | Gets list | N/A | N/A | N/A | | | | | | |
| | of active | | | | | blueprintRequ | Get | N/A* | N/A* | N/A* |
| | or | | | | | est | blueprint. | | | |
| | reserved | | | | | | | | | |
| | confs | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprintRequ | Gets a | Creates a | Changes a | Deletes a | | | | | | |
| est | specific | blueprint | blueprint | blueprint | | confsRequest | Get list | N/A | N/A | N/A |
| | blueprint | (needs | (needs | (needs | | | of | | | |
| | | admin | admin | admin | | | conference | | | |
| | | privileges | privileges | privileges | | | s (active, | | | |
| | | ) | ) | ) | | | etc.) | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| confRequest | Gets | Creates | Changes | Deletes | | confRequest | Gets | Creates | Changes | Deletes |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object | object | object | Object as | | | object or | object | object | Object as |
| | | | | a whole | | | blueprint. | | | a whole. |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Gets a | Creates a | Modifies | Deletes a | | | | | | |
| | specific | user and | the | user | | usersRequest | Gets a | N/A | Adds or | N/A |
| | user | associated | specified | element as | | | specific | | modifies | |
| | element | XCON-UserI | user | a whole | | | users | | the | |
| | | D | element | | | | element. | | specified | |
| | | | users | |
| | | | element. | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Gets a | N/A | Modifies | Deletes a | | | | | | |
| | specific | | the | users | | userRequest | Gets a | Creates | Adds or | Deletes a |
| | users | | specified | element as | | | specific | XCON-UserI | modifies | user |
| | element | | users | a whole | | | user | D . | the | element as |
| | | | element | | | | element. | | specified | a whole. |
| | | | user | |
| | | | element. | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarReques | Gets a | Creates a | Modifies a | Removes/de | | | | | | |
| t | sidebar | new | sidebar by | l etes the | | sidebarsByVal | Gets | N/A | N/A | N/A |
| | element by | sidebar by | Val | entire | | Request | sidebars-b | | | |
| | Val or by | Val | | sidebar b | | | y -val | | | |
| | Ref | | | y Val | | | element | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarsByRef | Gets | N/A | N/A | N/A |
| Request | sidebars-b | | | |
| | y -ref | | | |
| | element | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarByValR | Gets a | N/A | Adds or | Removes/de |
| equest | sidebar | | modifies a | l etes the |
| | element. | | sidebar. | entire |
| | | | | sidebar. |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarByRefR | Gets a | N/A | Adds or | Removes/de |
| equest | sidebar | | modifies a | l etes the |
| | element. | | sidebar. | entire |
| | | | | sidebar. |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
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 The following additional parameters are included in the specialized
for each request type in the above table Table 1 CCMP request/response messages detailed in the subsequent sections:
o blueprintsRequest: GET /blueprints operation: An optional parameter for each CCMP request/response
o confsRequest: GET /confs message. This parameter is REQUIRED in all messages except for
o blueprintRequest the "blueprintRequest", "blueprintResponse", "confsRequest" and
* GET /blueprint/blueprintId "confsResponse" messages.
* 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 blueprintInfo: An optional parameter used for the blueprintResponse
message. It is of type "conference-type" as defined in the XCON
data model and contains the data of the conference object
representing the blueprint in the conference server. This
parameter SHOULD not be included in any other response type
messages and SHOULD only be included in a "create", "update" or
"delete" operation for a blueprintRequest message in special cases
where a user has special privileges such as an administrator.
A response to the CCMP request MUST contain a response code and may blueprintsInfo: An optional parameter used for the
contain other elements depending upon the specific request and the blueprintsResponse message. It contains a list of elements of
value of the response code. type "blueprintInfo". This parameter SHOULD not be included in
any other response type messages and SHOULD only be included in a
"create", "update" or "delete" operation for a blueprintRequest
message in special cases where a user has special privileges such
as an administrator.
In case of a RESTful implementation, the CCMP response message MUST confsInfo: An optional parameter used for the confsResponse message.
be enclosed in a HTTP response message. CCMP-related error codes It contains a list of XCON-URIs. This parameter SHOULD not be
will be carried in the body of the response: no mapping is proposed included in any other response type messages and SHOULD only be
in this document regarding the potential association between CCMP and included in a "create", "update" or "delete" operation for a
HTTP error codes. For the sake of adhering to the principle of blueprintRequest message in special cases where a user has special
separation of concerns, HTTP maintains its own semantics, while privileges such as an administrator.
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 usersInfo: An OPTIONAL parameter that MAY be included in a
in successfully processed transport-level responses. For example usersRequest and usersReponse message, depending upon the
where HTTP is used, CCMP Response messages MUST be accompanied by a operation. The 'usersInfo' parameter carries an object compliant
200 OK HTTP response. with the <users> field of the XCON data model.
The set of CCMP Response codes currently contain the following 7.2.3.1. blueprintsRequest and blueprintsResponse messages
tokens:
success: This code indicates that the request was successfully A 'blueprintsRequest' (Figure 4) message is sent to request the list
processed. of XCON-URIs associated with the available blueprints from the
modified: This code indicates that the object was created, but may conference server. Such URIs can be subsequently used by the client
differ from the request. to access detailed information about a specified blueprint with a
badRequest: This code indicates that the request was badly formed in specific 'blueprintRequest' message per Section 7.2.3.3. A
some fashion. 'blueprintsRequest' message REQUIRES no additional parameters beyond
unauthorized: This code indicates that the user was not authorized those specified for the basic CCMP request message. The associated
for the specific operation on the conference object. 'blueprintsResponse' message SHOULD contain, as shown in Figure 4, a
forbidden: This code indicates that the specific operation is not 'blueprintsInfo' parameter containing the above mentioned XCON-URI
valid for the target conference object. list. The 'confObjId' parameter is NOT REQUIRED in the request or
objectNotFound: This code indicates that the specific conference response for this transaction.
object was not found.
operationNotAllowed: This code indicates that the specific operation
is not allowed for the target conference object (e.g.., when
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
cannot delete the specific conference object because it is a
parent for another conference object.
changeFailedProtected: This code indicates that the target
conference object cannot be changed (e.g., due to policies, roles,
privileges, etc.).
requestTimeout: This code indicates that the request could not be
processed within a reasonable time, with the time specific to a
conferencing system implementation.
serverInternalError: This code indicates that the conferencing <!-- blueprintsRequest -->
system experienced some sort of internal error. <xs:complexType name="ccmp-blueprints-request-message-type">
notImplemented: This code indicates that the specific operation is <xs:complexContent>
not implemented on that conferencing system. <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
CCMP Response codes are defined to allow for extensibility. A <!-- blueprintsResponse -->
conference control client SHOULD treat unrecognized response codes as <xs:complexType name="ccmp-blueprints-response-message-type">
it handles a Response code of "notImplemented". <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
8.3.1. blueprintsResponse <!-- blueprintsResponseType -->
A "blueprintsResponse" message containing a response code of <xs:element name="blueprintsResponse"
"success" MUST include the XML namespaces that the server understands type="blueprintsResponseType"/>
and the namespaces to be used in subsequent responses that it
requires the client to understand. Future work may add more global
capabilities rather than conferencing system specific. Within the
conferencing system, the namespaces correlate with blueprints, as
specified in the XCON framework. The blueprints are comprised of
conference information initialized to specific values and ranges.
Upon receipt of a successful "blueprintsResponse" message, a <xs:complexType name="blueprintsResponseType">
conference control client may then initiate a "blueprintRequest" with <xs:sequence>
a "retrieve" operation per Section 7.1 to get a specific conference <xs:element name="blueprintsInfo"
blueprint. type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
In the case of a response code of "requestTimeout", a conference Figure 4: Structure of the blueprintsRequest and blueprintsResponse
control client MAY re-attempt the request within a period of time messages
that would be specific to a conference control client or conference
control server.
The response codes of "modified", "deleteParentFailed" and 7.2.3.2. confsRequest and confsResponse messages
"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 A 'confsRequest' message is used to retrieve, from the server, the
an error and the handling is specific to the conference control list of XCON-URIs associated with active and registered conferences A
client. Typically, an error for a "blueprintsRequest" indicates a 'confsRequest' message REQUIRES no additional parameters beyond those
configuration problem in the conference control server or in the specified for the basic CCMP request message. The associated
client. 'confsResponse' message SHOULD contain the list of XCON-URIs in the
'confsInfo' parameter. The 'confObjId' parameter is NOT REQUIRED for
this transaction. A user, upon receipt of the response message, can
interact with the available conference objects through further CCMP
messages. The 'confsRequest' message is of a "retrieve-only" type,
since the sole purpose is to collect information available at the
conference server. Thus, an 'operation' parameter SHOULD NOT be
included in a 'confsRequest' message.
8.3.2. confsResponse <!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
A "confsResponse" message containing a response code of "success" <!-- confsResponse -->
MUST include the list of XCON-URIs associated with reserved/active <xs:complexType name="ccmp-confs-response-message-type">
conferences at the server. <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Upon receipt of a successful "confsResponse" message, a conference <!-- confsResponseType -->
control client may then initiate a "confRequest" with a "retrieve"
operation per Section 7.1 to get a specific conference object.
In the case of a response code of "requestTimeout", a conference <xs:element name="confsResponse" type="confsResponseType"/>
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 <xs:complexType name="confsResponseType">
"changeFailedProtected" are not applicable to a "confsRequest" and <xs:sequence>
should be treated as "serverInternalError", the handling of which is <xs:element name="confsInfo"
specific to the conference control client. type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
A "confsResponse" message containing any other response code is an Figure 5: Structure of the confsRequest and confsResponse messages
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.3. Operation Responses 7.2.3.3. blueprintRequest and blueprintResponse messages
The following sections detail the operation specific handling of the Through a 'blueprintRequest', a client can manipulate the conference
response codes, including details associated with specific types of object associated with a specified blueprint. The request MUST
responses in the cases where the response handling is not generic. include an 'operation' parameter and a 'confObjId' parameter. Only
the "retrieve" 'operation' SHOULD should be included in a
'blueprintRequest message. The 'create', 'update' and 'delete'
operations SHOULD NOT be included in a 'blueprintRequest' message
except in the case of privileged users (e.g. the conference server
administration staff). The 'confObjId' parameter contains the XCON-
URI of the blueprint, which might have been previously retrieved
through a 'blueprintsRequest' message.
8.3.3.1. Retrieve Operation Responses In the case of responseCode of "success" for a 'retrieve' operation,
the 'blueprintInfo' parameter SHOULD be included in the
'blueprintResponse' message. Inside responses, the 'blueprintInfo'
parameter carries the conference document associated with the
blueprint specified in the request.
A confResponse for a "retrieve" operation containing a response code <!-- blueprintRequest -->
of "success" MUST contain the full XML document describing the <xs:complexType name="ccmp-blueprint-request-message-type">
conference object in its current state including all inherited <xs:complexContent>
values. Elements may be marked by attributes, in particular, whether <xs:extension base="tns:ccmp-request-message-type">
they are specific to this instance or have been inherited from the <xs:sequence>
parent node. <xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
A blueprintResponse for a "retrieve" operation containing a response <!-- blueprintRequestType -->
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, <xs:element name="blueprintRequest" type="blueprintRequestType"/>
etc.) for a "retrieve" operation containing a response code of
"success" MUST contain the XML document describing the specific
target parameter (as indicated by the specific type of Request) from
the conference object.
If a response code of "objectNotFound" is received in a <xs:complexType name="blueprintRequestType">
"blueprintResponse" message to a "blueprintRequest" to get the <xs:sequence>
initial blueprint, it is RECOMMENDED that a conference control client <xs:element name="operation" type="operationType"
attempt to retrieve another conference blueprint if more than one had minOccurs="1" maxOccurs="1" />
been received in the "blueprintsResponse" message. If there was only <xs:element name="blueprintInfo"
one blueprint in the "blueprintsResponse" initially, then the client type="info:conference-type" minOccurs="0"/>
should send another "blueprintsRequest" message to determine if there </xs:sequence>
may be new or additional blueprints for the specific conferencing </xs:complexType>
system. If this "blueprintsResponse" message contains no blueprints,
the handling is specific to the conference control client. This
might indicate, for example, that something is going wrong at the
server, since no more blueprints are now available at it. In such
case, the client MAY interpret the new answer as a
'serverInternalError' and assume that no more service associated with
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 <!-- blueprintResponse -->
response, a conference control client MAY re-attempt the request <xs:complexType name="ccmp-blueprint-response-message-type">
within a period of time that would be specific to a conference <xs:complexContent>
control client or conference control server. <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Response codes such as "notImplemented" and "forbidden" indicate that <!-- blueprintResponseType -->
a subsequent "retrieve" would not likely be sucessful. Handling of
these and other response codes is specific to the conference control
client. For example, in the case of some clients a
"blueprintsRequest" operation might be performed again or another
conference control server may be accessed.
The response codes of "modified", "deleteParentFailed" and <xs:element name="blueprintResponse" type="blueprintResponseType"/>
"changeFailedProtected" are not applicable to the "retrieve"
operation and SHOULD be treated as "serverInternalError", the
handling of which is specific to the conference control client.
8.3.3.2. Create Operation Responses <xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
The only valid responses containing a "create" operation are a Figure 6: Structure of the blueprintRequest and blueprintResponse
"confResponse", a "blueprintResponse" and the "userResponse". The messages
"blueprintRequest" containing a "create" operation has to be
considered a special operation, used by a conference server
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 7.2.3.4. confRequest and confResponse messages
of "modified", along with the XCON-URI for the conference object, the
response MUST also contain the entire XML document associated with
that conference object for a "confRequest". For example, in the case
where the conference object contained a calendar element, the
conference server may only offer a subset of the dates requested,
thus the updated dates are included in the returned XML document.
In the case of a response code of "requestTimeout", a conference With a 'confRequest' message, CCMP clients can manipulate conference
control client MAY re-attempt the request within a period of time objects associated with either active or registered conferences
that would be specific to a conference control client or conference (blueprints or reservations). The request MUST include an
control server. 'operation' parameter. Depending upon the type of 'operation' a
'confObjId' parameter and/or 'confInfo' parameter MAY be included.
The 'confObjId' parameter contains the XCON-URI of the specific
active or registered conference. The 'confInfo' parameter contains
the conference data that is the target of the 'confRequest' - i.e.
the <conference-info> document (compliant with the XCON data model
structure).
Response codes such as "unauthorized", "forbidden" and To create a new conference through a 'confRequest' message, two
"operationNotAllowed" indicate the client does not have the approaches can be embraced:
appropriate permissions, 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 likely not succeed.
The response codes of "deleteParentFailed" and 1. Creation through explicit cloning: the 'confObjId' parameter MUST
"changeFailedProtected" are not applicable to the "create" operation contain the XCON-URI of the blueprint to be cloned, while the
and SHOULD be treated as "serverInternalError", the handling of which 'confInfo' parameter SHOULD NOT be included in the request;
is specific to the conference control client.
Any other response code indicates an error in the client or 2. Creation through implicit cloning (also known as "direct
conference control server (e.g., "forbidden", "badRequest") and the creation"): the 'confObjId' parameter SHOULD NOT be included in
handling is specific to the conference control client. the request, whereas the 'confInfo' parameter describing the
conference to be created MUST be included in the request.
8.3.3.3. Change Operation Responses In both cases, a successful completion of the request carries back a
responseCode of 'success' and SHOULD contain, in the 'confObjId'
parameter, the XCON-URI of the created conference. In addition, the
'confInfo' parameter transporting the created conference document
SHOULD be included. Obviously, the newly created object can be
manipulated by the client through subsequent 'update' operations.
If the CCMP response to the "change" operation contains a response In the case of 'retrieve' or 'delete' operations, the 'confObjId'
code of "success", the response SHOULD also contain the XCON-URI for representing the XCON-URI of the target conference MUST be included
the conference object that was changed. and the 'confInfo' SHOULD NOT be included in the request. Inside the
response to a 'retrieve' request, in case of responseCode of
'success', the 'confInfo' containing a description of the target
conference object MUST be included. On the other hand, a response to
a 'delete' operation SHOULD NOT include the 'confInfo' parameter.
The "blueprintRequest" containing a "change" operation has to be In case of an 'update' operation, the 'confInfo' and 'confObjID MUST
considered a special operation, used by a conference server be included in the request. The 'confInfo' represents an object of
administrator wishing to remotely an existing blueprint in the type "conference-type" containing all the changes to be applied to
conference server. the conference whose identifier is 'confObjId'. In the case of a
responseCode of success, no additional information is REQUIRED in the
'confResponse'message. For a successful response, the conference
server should consider as unchanged all parts of the referenced
conference document. However, if the target conference object has
not been modified exactly as required by the client the responsecode
MUST be set to 'modified' and the 'confInfo' parameter MUST contain
the entire conference document to which the required changes have
been (at least partially) applied.
If the CCMP response to the "change" operation contains a response The schema for the confRequest/confResponse pair is shown in
code of "modified", the response MUST contain the XCON-URI for the Figure 7.
conference object and the appropriate XML document (either the full
XML document for a confResponse or specific paramaters for the other
CCMP request types) associated with that conference object. For
example, a conferencing system may not have the resources to support
specific capabilities that were changed, such as <codecs> in the
<available-media>, thus the <codecs> supported are included in the
returned XML document.
If the CCMP response code of "requestTimeout" is received, a <!-- confRequest -->
conference control client MAY re-attempt the request within a period <xs:complexType name="ccmp-conf-request-message-type">
of time that would be specific to a conference control client or <xs:complexContent>
conference control server. <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Response codes such as "unauthorized", "forbidden", <!-- confRequestType -->
"operationNotAllowed" and "changeFailedProtected" indicate the client
does not have the appropriate permissions, the conference is locked,
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 likely not succeed.
The response code of "deleteParentFailed" is not applicable to the <xs:element name="confRequest" type="confRequestType" />
"change" operation and SHOULD be treated as "serverInternalError",
the handling of which is specific to the conference control client.
Any other response code indicates an error in the client or <xs:complexType name="confRequestType">
conference control server (e.g., "forbidden", "badRequest") and the <xs:sequence>
handling is specific to the conference control client. <xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="confInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
[Note by spromano: In case of "change" with a userRequest, the server <!-- confResponse -->
first has to change the user's information stored; then, it has to <xs:complexType name="ccmp-conf-response-message-type">
update all conference objects which include that user. The <xs:complexContent>
association between the user and the conferences in which she/he is <xs:extension base="tns:ccmp-response-message-type">
participating is guaranteed through the "entity" attribute of the <xs:sequence>
<user> element. IMO, after doing all that, the server just answers <xs:element ref="confResponse" />
with a userResponse message; then, if it is also using notifications, </xs:sequence>
it might raise events towards the interested subscribers, to notify </xs:extension>
them about the changes in the updated conference objects. Is this </xs:complexContent>
right??] </xs:complexType>
8.3.3.4. Delete Operation Responses <!-- confResponseType -->
If the CCMP response to the "delete" operation contains a response <xs:element name="confResponse" type="confResponseType" />
code of "success", the response MUST contain the XCON-URI for the
conference object that was deleted for a "confResponse" or whose data
element(s) were deleted for the other response types.
The "blueprintRequest" containing a "delete" operation has to be <xs:complexType name="confResponseType">
considered a special operation, used by a conference server <xs:sequence>
administrator wishing to remotely remove a blueprint from the <xs:element name="confInfo" type="info:conference-type"/>
conference server. </xs:sequence>
</xs:complexType>
The response code of "deleteParentFailed" indicates that the Figure 7: Structure of the confRequest and confResponse messages
conference object could not be deleted because it is the Parent of The following provides an example of the 'confInfo' parameter
another conference object that is in use. In this case, the response required to change the title of a conference:
also includes the XCON-URI for the conference object and is only
applicable to a "confResponse". If this response code is received
for any other type of CCMP response, it should be treated as
"serverInternalError", the handling of which is specific to the
conference control client.
If a response code of "requestTimeout" is received, a conference <conf-info entity="123">
control client MAY re-attempt the request within a period of time <conference-description>
that would be specific to a conference control client or conference <display-text>New conference title</display-text>
control server. </conference-description>
</conf-info>
Response codes such as "unauthorized", "forbidden" and Figure 8: Updating a conference object: modifying the title of a
"operationNotAllowed" indicate the client does not have the conference
appropriate permissions, the conference is locked, the object that
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
likely not succeed.
The response code of "changeFailedProtected" is not applicable to the Similarly, to remove the title of an existing conference, an 'update'
"delete" operation and SHOULD be treated as "serverInternalError", operation carrying the following 'confInfo' parameter would do the
the handling of which is specific to the conference control client. job.
Any other response code indicates an error in the client or <conf-info entity="123">
conference control server (e.g., "forbidden", "badRequest") and the <conference-description>
handling is specific to the conference control client. <display-text/>
</conference-description>
</conf-info>
[Note by spromano (same comment as for "change"): In case of "delete" Figure 9: Updating a conference object: removing the title of a
with a userRequest, the server first has to delete the user's conference
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 7.2.3.5. usersRequest and usersResponse messages
Sidebars can be either "by reference" or "by value". The management Through a usersRequest message the CCMP client manipulates the
of sidebars differs in the two cases, as discussed below <users> element of the conference document associated with the
conference identified by the 'confObjId' parameter. Inside the
<users> element, along with the list of conference users, there is
information that the client may be interested in controlling, such as
the lists of users to which access to the conference is allowed/
denied, conference participation policies, etc.; for this reason, a
customized message has been designed to allow for the manipulation of
this specific part of a conference document. Besides the usual
'operation' parameter, a 'usersInfo' parameter MAY also be included
depending upon the operation. The 'usersInfo' parameter carries an
object compliant with the <users> field of the XCON data model.
9.1. Sidebars by value An 'operation' parameter MUST be included in a "usersRequest"
message. Two operations are allowed in a "usersRequest" message:
Sidebars by value represent an inner part of the conference object 1. retrieve: In this case the request SHOULD NOT include a
associated with the root conference from which they stem. One or 'usersInfo' parameter, while a successful response MUST contain
more sidebars by value are then created by using the "confRequest" the desired <users> element in the 'usersInfo' parameter.
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 2. update: In this case, the 'usersInfo' parameter MUST contain the
modifications to be applied to the referred <users> element. If
the responseCode is 'success', then the 'usersInfo' parameter
SHOULD NOT be returned. If the responseCode is 'modified', the
'usersInfo' parameter MUST be included in the response. The
'usersInfo' reflects to the client the (partial) modifications
that have been applied.
Sidebars by reference represent semi-independent conference objects, Operations of 'create' and 'delete' make little sense in the case of
i.e. objects that exist on their own, but which are strictly coupled a usersRequest and SHOULD NOT be considered by the server, which
to the conference object from which they stem. A sidebar by means that a responseCode of 'forbidden' SHOULD be included in the
reference is then created by using the "confRequest" message with an usersResponse message.
operation of "create".
Editor's Note: should we have a means to indicate that the object we <!-- usersRequest -->
are creating is actually a sidebar? This would go in the <xs:complexType name="ccmp-users-request-message-type">
confRequest/create message. Otherwise, we might add a <xs:complexContent>
sidebarRequest/create operation which basically does a conference <xs:extension base="tns:ccmp-request-message-type">
creation, but, e.g., stores it in a different repository (/sidebars <xs:sequence>
rather than /confs). <xs:element ref="usersRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Once the sidebar has been created, you can add it to a conference by <!-- usersRequestType -->
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 <xs:element name="usersRequest" type="usersRequestType" />
This section describes in detail the parameters that are used for the <xs:complexType name="usersRequestType">
CCMP protocol. <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="usersInfo"
type="info:users-type" minOccurs="0" />
</xs:sequence>
</xs:complexType>
10.1. Operation Parameter <!-- 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>
The "operation" attribute is a mandatory token included in all CCMP <!-- usersResponseType -->
request and response messages. This document defines four possible
values for this parameter: "retrieve", "create", "change" and
"delete".
10.2. ConfObjID Parameter <xs:element name="usersResponse" type="usersResponseType" />
The "confObjID" attribute is an optional URI included in the CCMP <xs:complexType name="usersResponseType">
request and response messages. This attribute is required in the <xs:sequence>
case of an "operation" of "retrieve", "change", and "delete" in the <xs:element name="usersInfo" type="info:users-type"/>
CCMP request and response messages. The attribute is optional for an </xs:sequence>
"operation" of "create" in the "confRequest" message. The "create" </xs:complexType>
cases for which this parameter is REQUIRED are described in
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-
iterate the normative text here.]
This attribute is not included in the "userRequest" message for an Figure 10: Structure of the usersRequest and usersResponse messages
operation of "create". In this case, the conference control client
is requesting the creation of a new conference user, as detailed in
Section 10.3.
In the cases where the "conference-info" parameter Section 10.6 is 7.2.3.6. userRequest and userResponse messages
also included in the requests and responses, the "confObjID" MUST
match the XCON-URI in the "entity" attribute.
10.3. ConfUserID Parameter A "userRequest" message is used to manipulate <user> elements inside
a conference document associated with a conference identified by the
'confObjId' parameter. Besides retrieving information about a
specific conference user, the message MAY be used to either create,
or modify, or delete information about a user. A "userRequest" MUST
include the 'operation' parameter, and MAY include a 'userInfo'
parameter containing the detailed user's information.
The "confUserID" attribute is optional URI included in the CCMP Conference users can be created in a number of different ways. Let
request and response messages. This is the XCON-USERID for the us first consider the case of a user who wants to enter a conference
conference control client initiating the request. The attribute is (i.e. to add himself to the conference). In such a case, the
required in the CCMP request and response messages with the exception 'userInfo' parameter in the request (which MUST have an 'operation'
of the "userRequest" message. The "confUserID" parameter is used to value set to "create") SHOULD contain a <user> element (compliant
determine if the conference control client has the authority to with the XCON data model) having its 'entity' attribute set to a
perform the operation. Note that the details for authorization and value which represents the XCON-USERID of the user in question.
related policy are specified in a separate document [TBD].
This attribute is optional only for an "userRequest" message with a A different situation is one in which the CCMP client acts on behalf
"create" operation. In this case, the request MUST include of a third user, whose XCON-USERID is known. In this case, the
information about the user in the "user" element. At a minimum, the <user> element SHOULD contain an 'entity' attribute whose value is
request MUST include the "user" element with an "entity" attribute. set to the XCON-USERID of the user in question. As a final case, if
For this case, the conference control server MUST create a new the CCMP client is not aware of the XCON-USERID of the user to be
conference user and return the associated confUserID in the response, inserted, the key attribute (i.e. 'entity') SHOULD NOT be included in
if the allocation of a new XCON-USERID is succesful. the request: the XCON-USERID generated by the conference server for
such a user MUST be returned to the client as the value of the
'entity' attribute in the 'userInfo' parameter of the response if the
responseCode is "success". The last case also applies to a CCMP
client that obtains a new user profile in the context of a
conference.
In the case where there is a confUserID in the request that has <!-- userRequest -->
already been allocated, this request may be the creation of a <xs:complexType name="ccmp-user-request-message-type">
confUserID for the conference control client to take on an additional <xs:complexContent>
role. <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
This attribute is required in the "userResponse" message in the case <!-- userRequestType -->
of an "operation" of "create" and for all other responses.
10.4. ResponseCode Parameter <xs:element name="userRequest" type="userRequestType" />
The "responseCode" attribute is a mandatory parameter in all CCMP <xs:complexType name="userRequestType">
response messages. The values for each of the "responseCode" values <xs:sequence>
are detailed in Section 8.3 with the associated processing described <xs:element name="operation" type="operationType"
in Section 8.3.3. minOccurs="1" maxOccurs="1" />
<xs:element name="userInfo"
type="info:user-type" minOccurs="0" />
</xs:sequence>
</xs:complexType>
10.5. Blueprints Parameter <!-- 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>
The "blueprints" attribute is an optional parameter in the CCMP <!-- userResponseType -->
blueprintsResponse message. In the case of a "blueprintsRequest"
message, the "blueprintsResponse" message with a "responseCode" of
"success" SHOULD include the "blueprints" supported by the conference
control server. The "blueprints" attribute is comprised of a list of
blueprints supported by the specific conference server and includes a
conference system specific "blueprintName" and a "confObjID" in the
form of an XCON-URI for each of the blueprints.
10.6. Conference-info Parameter <xs:element name="userResponse" type="userResponseType" />
The "conference-info" element is optional in the CCMP confRequest and <xs:complexType name="userResponseType">
confResponse messages. <xs:sequence>
<xs:element name="userInfo" type="info:user-type"/>
</xs:sequence>
</xs:complexType>
Figure 11: Structure of the userRequest and userResponse messages
The "conference-info" element contains the data for the conference 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse messages
object that is the target for the "confRequest" operations for
"create", "change" and "delete" operations. It is returned in a
"confResponse" if the "confResponse" contains a responseCode of
"modified" or if the original CCMP request for the "create" operation
did not contain a "conference-info" element. The latter case occurs
when a conference control client sends a "confRequest" containing any
of the following: - a "confObjID" associated with a specific
blueprint - a "confObjID associated with a specific active conference
or conference reservation that was included in a "confsResponse"
message - no "confObjID" (or "conference-info") element, in which
case the request is to create a conference object based on a default
provided by a conferencing system.
The "conference-info" element is also returned in a "userResponse" A "sidebarsByValRequest" is used to execute a retrieve-only operation
message, in the case of a "change" operation. In such case, in fact, on the <sidebars-by-val> field of the conference object represented
the request contains the <user> element to be added to the conference by the 'confObjId'. The request MUST include an 'operation' of
indicated in the <confObjID> parameter; the associated answer SHOULD "retrieve" and a 'confObjId'. A "sidebarsByValResponse" MUST contain
carry the updated conference object in its body. a 'sidebarsByValInfo' parameter reporting the desired <sidebars-by-
val> element. The 'sidebarsByValInfo' parameter contains the
identifiers of the sidebars derived from the main conference. For
the creation and manipulation of sidebars, a different message has
been envisaged, namely "sidebarByValRequest", which is described in
Section 7.2.3.8
The details on the information that may be included in the <!-- sidebarsByValRequest -->
"conference-info" element MUST follow the rules as specified in the
XCON Data Model document [I-D.ietf-xcon-common-data-model]. The
conference control client and conference control server MUST follow
those rules in generating the "conference-info" in any of the CCMP
request and response messages.
Note that the "conference-info" element is not explicitly shown in <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
the XML schema (Section 12) due to XML schema constraints. <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
10.7. User Parameter <!-- sidebarsByValRequestType -->
The "user" element contains the data for the conference user that is <xs:element name="sidebarsByValRequest"
the target for the CCMP request operations. It is REQUIRED for all type="sidebarsByValRequestType" />
"userRequest" messages.
The details on the information that may be included in the "user" <xs:complexType name="sidebarsByValRequestType">
element MUST follow the rules as specified in the XCON Data Model <xs:sequence>
document [I-D.ietf-xcon-common-data-model]. The conference control <xs:element name="operation" type="operationType"
client and conference control server MUST follow those rules in minOccurs="1" maxOccurs="1" />
generating the "user" in any of the CCMP request and response <xs:element name="sidebarsByValInfo"
messages. type="info:sidebars-by-val-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Note that the "user" element is not explicitly shown in the XML <!-- sidebarsByValResponse -->
schema Section 12 due to XML schema constraints.
10.8. Users Parameter <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The "users" element contains the data for the conference users that <!-- sidebarsByValResponseType -->
are the target for the CCMP request operations. It is REQUIRED for
all "usersRequest" messages.
The details on the information that may be included in the "users" <xs:element name="sidebarsByValResponse"
element MUST follow the rules as specified in the XCON Data Model type="sidebarsByValResponseType" />
document [I-D.ietf-xcon-common-data-model]. The conference control
client and conference control server MUST follow those rules in
generating the "users" in any of the CCMP request and response
messages.
Note that the "users" element is not explicitly shown in the XML <xs:complexType name="sidebarsByValResponseType">
schema Section 12 due to XML schema constraints. <xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type"/>
</xs:sequence>
</xs:complexType>
10.9. Sidebar Parameters Figure 12: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages
The "sidebar" parameter contains the data for the sidebar that is the 7.2.3.8. sidebarByValRequest and sidebarByValResponse messages
target for the CCMP request operations. It is REQUIRED for all
"sidebarRequest" messages. There are two elements associated with a
sidebar: "sidebar-by-val" and "sidebar-by-ref". The elements relate
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
is created for the sidebar.
The details on the information that may be included in the "sidebar- A "sidebarByValRequest" message MUST contain the 'operation'
by-val" or "sidebar-by-ref" element MUST follow the rules as parameter which discriminates among creation, modification and
specified in the XCON Data Model document deletion of a specific sidebar. The 'sidebarByValInfo' parameter, in
[I-D.ietf-xcon-common-data-model]. The conference control client and turn, contains the description (in an XCON data model compliant
conference control server MUST follow those rules in generating the fashion) of the sidebar itself. The 'confObjId' parameter of such
"sidebar-by-val" or "sidebar-by-ref" element in any of the CCMP messages MUST contain the XCON-URI of the main conference which the
request and response messages. sidebar belongs to. The XCON-URI of the sidebar is contained in the
'entity' attribute of the above mentioned 'sidebarByValInfo'
document. In case of creation, the 'sidebarByValInfo' SHOULD NOT be
included in the request, since, as envisaged in the XCON framework
([RFC5239]), sidebars are always created by cloning the main
conference. The 'sidebarByValInfo' parameter MUST be included in a
successful response. The 'sidebarByValInfo' represents the created
sidebar, whose URI appears in the 'entity' attribute.
11. Examples <!-- sidebarByValRequest -->
Examples on the use of HTTP as the CCP based on a RESTful <xs:complexType name="ccmp-sidebarByVal-request-message-type">
implementation are provided in Section 11.1. The body of the HTTP <xs:complexContent>
methods contains the CCMP operations and data. Examples of the CCMP <xs:extension base="tns:ccmp-request-message-type">
operations and related data are provided in section Section 11.2 <xs:sequence>
<xs:element ref="sidebarByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
11.1. HTTP methods for realizing a RESTful CCMP <!-- sidebarByValRequestType -->
This section provides a series of examples using the HTTP methods for <xs:element name="sidebarByValRequest"
realization of the CCMP. The examples provide a sequence of type="sidebarByValRequestType" />
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': <xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
CCMP client "Alice" ConfS <!-- sidebarByValResponse -->
| |
| GET /confs |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ conf info
|<---------------------------------------------| (list of
| | conf objs)
Figure 3: Getting a List of Active Coferences <xs:complexType name="ccmp-sidebarByVal-response-message-type">
Alice is now able to retrieve info about a specific conference: <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByValResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
CCMP client "Alice" ConfS <!-- sidebarByValResponseType -->
| |
| GET /confs/confid-34fg67h |
|--------------------------------------------->|
| |--+ Prepare
| | | formatted
| 200 OK (w/ body) |<-+ XML info
|<---------------------------------------------|
| |
Figure 4: Getting a Specific Coference <xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
Alice decides to add a new user to this conference: <xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
Figure 13: Structure of the sidebarByValRequest and
sidebarByValResponse messages
CCMP client "Alice" ConfS 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse messages
Similar to the "sidebarsByValRequest", a "sidebarsByRefRequest" can
be invoked to retrieve the <sidebars-by-ref> element of the
conference object identified by the 'confObjId' parameter. The
'confObjID' parameter MUST be included in the request. An operation
of 'retrieve' MUST also be included in the request. In the case of a
responseCode of success, the 'sidebarsByRefInfo' parameter,
containing the <sidebars-by-ref> element of the conference object,
MUST be included in the response. The <sidebars-by-ref> element
represents the set of URIs of the sidebars associated with the main
conference, whose description (in the form of a standard XCON
conference document) is external to the main conference itself.
Through the retrieved URIs, it is then possible to access single
sidebars by exploiting the ad-hoc defined "sidebarByRef" request,
described in Section 7.2.3.10.
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByref-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence>
<xs:element name="sidebarsByRefInfo"
type="info:uris-type"/>
</xs:sequence>
</xs:complexType>
Figure 14: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages
7.2.3.10. sidebarByRefRequest and sidebarByRefResponse messages
A "sidebarByRefRequest" message along with the REQUIRED 'operation'
parameter, MAY contain a 'sidebarByRefInfo' parameter describing the
conference object (compliant with the XCON data model) associated
with the sidebar. In case of 'retrieve', 'delete', 'update' and
'create' operations, the 'confObjId' parameter representing the XCON-
URI of the target sidebar MUST be included. The 'sidebarByRefInfo'
parameter is NOT REQUIRED in the first two cases ('retrieve' and
'delete'), whereas in the case of an 'update' the 'sidebarByRefInfo'
parameter MUST contain the changes to be applied to the referenced
sidebar. The 'sidebarByRefInfo' MUST NOT be included for a 'create'
operation since, as already stated, sidebar creation is by default
achieved by cloning the main conference.
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByref-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
Figure 15: Structure of the sidebarByRefRequest and
sidebarByRefResponse messages
8. A complete example of the CCMP in action
In this section a typical scenario in which the CCMP comes into play
is described, by showing the actual composition of the various CCMP
messages. In the call flows of the example, the Conference Control
Client is a CCMP-enabled client, whereas the Conference Control
Server is a CCMP-enabled server. The 'confUserId' of the client is
"Alice" and appears in all requests. The sequence of operations is
as follows:
1. Alice retrieves from the server the list of available blueprints
(Section 8.1);
2. Alice asks for detailed information about a specific blueprint
(Section 8.2);
3. Alice decides to create a new conference by cloning the retrieved
blueprint (Section 8.3);
4. Alice modifies information (e.g. XCON-URI, name, description)
associated with the newly created blueprint (Section 8.4);
5. Alice specifies a list of users to be contacted when the
conference is activated (Section 8.5);
6. Alice joins the conference (Section 8.6);
7. Alice lets a new user (whose 'confUserId' is "Ciccio") join the
conference (Section 8.7).
Note, the examples do not include any details beyond the basic
operation.
In the following sections we deal with each of the above mentioned
actions separately.
8.1. Alice retrieves the available blueprints
This section illustrates the transaction associated with retrieval of
the blueprints, together with a dump of the two messages exchanged
("blueprintsRequest" and "blueprintsResponse"). As it comes out from
the figure, the "blueprintsResponse" message contains, in the
'blueprintsInfo' parameter, information about the available
blueprints, in the form of the standard XCON-URI of the blueprint,
plus additional (and optional) information, like its display-text and
purpose.
Alice retrieves from the server the list of available blueprints:
CCMP Client CCMP Server
| | | |
| PUT /confs/confid-34fg67h/users/pippo876 | | CCMP blueprintsRequest message |
| (w/ body=new user info) | | - confUserID: Alice |
|--------------------------------------------->| | - confObjId: (null) |
| |--+ Add new user |------------------------------------------------------>|
| | | to data model
| 200 OK (w/ body) |<-+ and update
|<---------------------------------------------| user in system
| | | |
| | (event triggered | CMP blueprintsResponse message |
| | e.g. RFC4575) | - confUserID: Alice |
| |----------------> | - confObjId: (null) |
| - responseCode: success |
| - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------|
| | | |
. .
. .
Figure 5: Adding a New User to an Active Conference 1. blueprintsRequest message:
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 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xcon:ccmp-blueprints-request-message-type">
<confUserID>Alice</confUserID>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintsResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:AudioRoom@meetecho.com</info:uri>
<info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room:
conference room with public access,
where only audio is available, more users
can talk at the same time
and the requests for the AudioFloor
are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoRoom@meetecho.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
8 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference1@meetecho.com</info:uri>
<info:display-text>AudioConference1</info:display-text>
<info:purpose>Public Audio Conference:
conference with public access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoConference1@meetecho.com</info:uri>
<info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference
where both audio and video are available,
only one user can talk
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference2@meetecho.com</info:uri>
<info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference:
conference with private access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
</blueprintsInfo>
</ccmp:blueprintsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 16: Getting blueprints from the server
8.2. Alice gets detailed information about a specific blueprint
This section illustrates the second transaction in the overall flow.
In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about
one of them (the one called with XCON-URI
"xcon:AudioRoom@meetecho.com"). The picture shows such transaction.
Notice that the response contains, in the 'blueprintInfo' parameter,
a document compliant with the standard XCON data model.
Alice retrieves detailed information about a specified blueprint:
CCMP Client CCMP Server
| | | |
| GET /confs/confid-34fg67h/users/pippo876 | | CCMP blueprintRequest message |
|--------------------------------------------->| | - confUserID: Alice |
| |--+ Prepare | - confObjId: bp123 |
| | | formatted | - Operation: retrieve |
| 200 OK (w/ body) |<-+ XML info | - blueprintInfo: (null) |
|<---------------------------------------------| |------------------------------------------------------>|
| | | |
| GET /users/pippo876 | | CCMP blueprintResponse message |
|--------------------------------------------->| | - confUserID: Alice |
| |--+ Prepare | - confObjId: bp123 |
| | | formatted | - responseCode: success |
| 200 OK (w/ body) |<-+ XML info | - blueprintInfo: bp123Info |
|<---------------------------------------------| |<------------------------------------------------------|
| | | |
. .
. .
Figure 6: Getting a Specific Conference Object after Changes 1. blueprintRequest message:
Alice updates some info related to the same user: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:blueprintRequest>
<operation>retrieve</operation>
</ccmp:blueprintRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
CCMP client "Alice" ConfS 2. blueprintResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintResponse>
<blueprintInfo entity="AudioRoom">
<info:conference-description>
<info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count>
<info:available-media>
<info:entry label="audioLabel">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm
</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 17: Getting info about a specific blueprint
8.3. Alice creates a new conference through a cloning operation
This section illustrates the third transaction in the overall flow.
Alice decides to create a new conference by cloning the blueprint
having XCON-URI "xcon:AudioRoom@meetecho.com", for which she just
retrieved detailed information through the "blueprintRequest"
message. This is achieved by sending a "confRequest/create" message
having the blueprint's URI in the 'confObjId' parameter. The picture
shows such transaction. Notice that the response contains, in the
'confInfo' parameter, the document associated with the newly created
conference, which is compliant with the standard XCON data model.
The 'confObjId' in the response is set to the XCON-URI of the new
conference (in this case, "xcon:8977794@meetecho.com"). We also
notice that this value is equal to the value of the "entity"
attribute of the <conference-info> element of the document
representing the newly created conference object.
Alice creates a new conference by cloning the
"xcon:AudioRoom@meetecho.com" blueprint:
CCMP Client CCMP Server
| | | |
| POST /confs/confid-34fg67h/users/pippo876 | | CCMP confRequest message |
| (w/ body=updated user info) | | - confUserID: Alice |
|--------------------------------------------->| | - confObjId: xcon:AudioRoom@meetecho.com |
| |--+ Update user | - Operation: create |
| | | in data | - confInfo: (null) |
| 200 OK (w/ body) |<-+ and in |------------------------------------------------------>|
|<---------------------------------------------| system
| | | |
| |Event trigger | CCMP confResponse message |
| |e.g. RFC4575 | - confUserID: Alice |
| |-------------> | - confObjId: newConfId |
| - responseCode: success |
| - confInfo: newConfInfo |
|<------------------------------------------------------|
| | | |
Figure 7: Updating a User's Information . .
. .
Alice destroys the running conference: when trying to access it, the 1. confRequest message:
server returns an error:
CCMP client "Alice" ConfS <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:confRequest>
<operation>create</operation>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@meetecho.com">
<info:conference-description>
<info:display-text>
New conference by Alice cloned from AudioRoom
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>
xcon:8977794@meetecho.com
</info:uri>
<info:display-text>
conference xcon-uri
</info:display-text>
<xcon:conference-password>
8601
</xcon:conference-password>
</info:entry>
</info:conf-uris>
<info:maximum-user-count>10</info:maximum-user-count>
<info:available-media>
<info:entry label="11">
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>
confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="11"/>
</xcon:conference-floor-policy>
</xcon:floor-information>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 18: Creating a new conference by cloning a blueprint
8.4. Alice updates conference information
This section illustrates the fourth transaction in the overall flow.
Alice decides to modify some of the details associated with the
conference she just created. More precisely, she changes the
<display-text> element under the <conference-description> element of
the document representing the conference. This is achieved through a
"confRequest/update" message carrying the fragment of the conference
document to which the required changes have to be applied. As shown
in the picture, the response contains a code of 'success', which
acknowledges the modifications requested by the client.
Alice updates information about the conference she just created:
CCMP Client CCMP Server
| | | |
| DELETE /confs/confid-34fg67h | | CCMP confRequest message |
|--------------------------------------------->| | - confUserID: Alice |
| |--+ Prepare | - confObjId: xcon:8977794@meetecho.com |
| | | formatted | - Operation: update |
| 200 OK (w/ body) |<-+ XML info | - confInfo: conf456Updates |
|<---------------------------------------------| |------------------------------------------------------>|
| | | |
| GET /confs/confid-34fg67h | | CCMP confResponse message |
|--------------------------------------------->| | - confUserID: Alice |
| |--+ ConfS can't | - confObjId: xcon:89.. |
| | | find the | - responseCode: success |
| 200 OK (w/body: |<-+ conference | - confInfo: (null) |
|<---------------------------------------------| |<------------------------------------------------------|
| responseCode=objectNotFound |
| | | |
. .
. .
Figure 8: Deleting an Active Coference 1. confRequest message:
11.2. CCMP Detailed Message Body Examples <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:confRequest>
<operation>update</operation>
<confInfo entity="xcon:8977794@meetecho.com">
<info:conference-description>
<info:display-text>
Alice's conference
</info:display-text>
</info:conference-description>
</confInfo>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
The examples below contain simply the <body> of the requests and 2. confResponse message form the server:
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 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
The first example creates a new conference. Figure 19: Updating conference information
<confRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> 8.5. Alice inserts a list of users in the conference object
<operation>create</operation>
<confUserID> userA-confxyz987 </confUserID>
<conference-info This section illustrates the fifth transaction in the overall flow.
xmlns="urn:ietf:params:xml:ns:conference-info" Alice modifies the <allowed-users-list> under the <users> element in
version="1"> the document associated with the conference she created. To the
<conference-description> purpose, she exploits the "usersRequest" message provided by the
<parent>http://example.com/conf200</parent> CCMP. The picture below shows the transaction.
<subject>Agenda: This month's goals</subject>
<conf-uris>
<entry>
<uri>sips:conf223@example.com</uri>
<purpose>participation</purpose>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharep/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
<entry>
<uri>http://example.com/conf233</uri>
<purpose>control</purpose>
</entry>
</service-uris>
</conference-description>
</conference-info>
</confRequest> Alice updates information about the list of users to whom access to
the conference is permitted:
Figure 9: Create Request Example CCMP Client CCMP Server
| |
| CCMP usersRequest message |
| - confUserID: Alice |
| - confObjId: xcon:8977794@meetecho.com |
| - Operation: update |
| - usersInfo: usersUpdates |
|------------------------------------------------------>|
| |
| CCMP usersResponse message |
| - confUserID: Alice |
| - confObjId: xcon:89.. |
| - responseCode: success |
| - usersInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
The response to this request is shown below; it returns the object 1. usersRequest message:
identifier as a URL and the final conference description, which may
modify the description offered by the user.
<confResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp" <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<operation>create</operation> <ccmp:ccmpRequest
<responseCode> modified </responseCode> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
<confObjID> xcon:confxyz987@example.com </confObjID> xmlns:info="urn:ietf:params:xml:ns:conference-info"
<confUserID> userA-confxyz987 </confUserID> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:usersRequest>
<operation>update</operation>
<usersInfo>
<xcon:allowed-users-list>
<xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer"
uri="tel:+390817683823"/>
<xcon:target method="refer"
uri="sip:Carol@example.com"/>
</xcon:allowed-users-list>
</usersInfo>
</ccmp:usersRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<conference-info 2. usersResponse message form the server:
xmlns="urn:ietf:params:xml:ns:conference-info"
version="1">
<entity> xcon:confxyz987@example.com </entity>
<conference-description>
<parent>http://example.com/conf200</parent>
<subject>Agenda: This month's goals</subject>
<conf-uris>
<entry>
<uri>sips:conf223@example.com</uri>
<purpose>participation</purpose>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharep/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
<entry>
<uri>http://example.com/conf233</uri>
<purpose>control</purpose>
</entry>
</service-uris>
<!-- Addt'l modified conference description including users alice, <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
bob and userA... --> <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<allowed-users-list> Figure 20: Updating the list of allowed users for the conference
<target uri="sip:alice@example.com" method="dial-out"/> 'xcon:8977794@meetecho.com'
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:userA@example.com" method="dial-in"/>
</allowed-users-list>
</conference-description> 8.6. Alice joins the conference
</conference-info>
</confResponse> This section illustrates the sixth transaction in the overall flow.
Alice uses the CCMP to add herself to the newly created conference.
This is achieved through a "userRequest/create" message containing,
in the 'userInfo' parameter, a <user> element compliant with the XCON
data model representation. Notice that such element includes
information about the user's Address of Records, as well as her
current end-point. The picture below shows the transaction. Notice
how the 'confUserId' parameter is equal to the "entity" attribute of
the <userInfo> element, which indicates that the request issued by
the client is a first-party one.
Figure 10: Create Response Example Alice joins the conference by issuing a "userRequest/create" message
with her own id to the server:
11.2.2. Creating a New Conference User CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjId: xcon:8977794@meetecho.com |
| - Operation: create |
| - userInfo: AliceUserInfo |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - confObjId: xcon:89.. |
| - responseCode: success |
| - userInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
The request below creates a new conference user, independent of a 1. userRequest message:
specific conference object.
<userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-confUser-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:confUserRequest>
<operation>create</operation> <operation>create</operation>
<userInfo entity="Alice">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:confUserRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<user entity="sip:bob@example.com"> 2. userResponse message form the server:
<role>observer</role>
</user>
</userRequest> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-confUser-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:confUserResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 11: Create User Example Figure 21: Alice joins the conference through the CCMP
The response to this request is shown below; it returns the 8.7. Alice adds a new user to the conference
conference user identifier.
<userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> This section illustrates the seventh and last transaction in the
<operation>create</operation> overall flow. Alice uses the CCMP to add a new user to the
<responseCode> success </responseCode> conference. This is achieved through a "userRequest/create" message
<confUserID>userC-confxyz987</confUserID> containing, in the 'userInfo' parameter, a <user> element compliant
</userResponse> with the XCON data model representation. Notice that such element
includes information about the user's Address of Records, as well as
his current end-point. The picture below shows the transaction.
Notice how the 'confUserId' parameter in the request is Alice's id,
whereas the <userInfo> element has no "entity" attribute and contains
information about a different user, thus indicating that the request
issued by the client is a third-party one. This is also reflected in
the response coming from the server, which this time contains a non-
void <userInfo> element, whose "entity" attribute has been set by the
server to the value of the newly created conference user id.
Figure 12: Create Response Example Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server:
11.2.3. Adding a User to a Conference CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjId: xcon:8977794@meetecho.com |
| - Operation: create |
| - usersInfo: CiccioUserInfo |
|------------------------------------------------------>|
| |
| CCMP userresponse message |
| - confUserID: Alice |
| - confObjId: xcon:89.. |
| - responseCode: success |
| - usersInfo: (not null!)|
|<------------------------------------------------------|
| |
. .
. .
The request below adds a user to the conference identified by the 1. "third party" userRequest message from Alice:
XCON-URI. Note that the user in "confUserID" element is the user
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
as the moderator, can add another user to the conference.
Editor's note: Do we need to consider users adding users OBO of other <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
users or in that case do we just change the conference object as a <ccmp:ccmpRequest
whole? xmlns:info="urn:ietf:params:xml:ns:conference-info"
<userRequest xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
<operation>change</operation> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<confObjID> xcon:confxyz987@example.com </confObjID> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<confUserID> userC-confxyz987 </confUserID> xsi:type="ccmp:ccmp-confUser-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID>
<ccmp:confUserRequest>
<operation>create</operation>
<userInfo>
<info:associated-aors>
<info:entry>
<info:uri>
mailto:ciccio@pernacchio.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:ciccio@pernacchio.com"/>
</userInfo>
</ccmp:confUserRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<user entity="sip:claire@example.com"> 2. "third party" userResponse message form the server:
<role>participant</role>
<type>dial-out</type>
</user>
</userRequest> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-confUser-response-message-type">
<confObjID>8977794</confObjID>
<confUserID>Alice</confUserID>
<ccmp:response-code>success</ccmp:response-code>
<ccmp:confUserResponse>
<confUserInfo entity="bn90ujbkj">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:ciccio@pernacchio.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:ciccio@pernacchio.com"/>
</confUserInfo>
</ccmp:confUserResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 13: Add User Example Figure 22: Alice adds a new user to the conference through the CCMP
The response to this request is shown below. 9. Locating a Conference Control Server
<userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"> If a conference control client is not pre-configured to use a
<operation>change</operation> specific conference control server for the requests, the client MUST
<responseCode> success </responseCode> first discover the conference control server before it can send any
<confObjID> xcon:confxyz987@example.com </confObjID> requests. The result of the discovery process, is the address of the
<confUserID> userC-confxyz987 </confUserID> server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server.
<user entity="sip:claire@example.com"> This document proposes the use of DNS to locate the conferencing
<role>participant</role> server. U-NAPTR resolution for conferencing takes a domain name as
<type><dial-out/></type> input and produces a URI that identifies the conferencing server.
</user> This process also requires an Application Service tag and an
</users> Application Protocol tag, which differentiate conferencing-related
</conference-info> NAPTR records from other records for that domain.
</userResponse> Section 12.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 12.4.2, is used to identify an XCON server that understands
the CCMP protocol.
Figure 14: Add User Response Example The NAPTR records in the following example Figure 23 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.".
12. XML Schema 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 23: Sample XCON:CCMP Service NAPTR Records
Details for the "XCON" Application Service tag and the "CCMP"
Application Protocol tag are included in Section 12.4.
10. 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:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="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:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- Import data model schema (as per the latest draft) -->
<xs:import <xs:import
namespace="urn:ietf:params:xml:ns:xcon-conference-info" namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel-11.xsd"/> schemaLocation="DataModel.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" <xs:element name="ccmpRequest" type="ccmp-request-type" />
type="ccmp-request-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<xs:element name="ccmpResponse"
type="ccmp-response-type" />
<!-- CCMP request definition --> <!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type"> <xs:complexType name="ccmp-request-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpRequest" <xs:element name="ccmpRequest"
type="ccmp-request-message-type" /> type="ccmp-request-message-type" />
</xs:sequence> </xs:sequence>
<xs:attribute name="xconURI" type="xs:string"
use="optional" />
</xs:complexType> </xs:complexType>
<!-- CCMP response definition --> <!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type"> <xs:complexType name="ccmp-response-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpResponse" <xs:element name="ccmpResponse"
type="ccmp-response-message-type" /> type="ccmp-response-message-type" />
</xs:sequence> </xs:sequence>
<xs:attribute name="xconURI" type="xs:string"
use="optional" />
</xs:complexType> </xs:complexType>
<!-- Definition of ccmp-request-message-type as an <!-- Definition of ccmp-request-message-type -->
abstract complex type -->
<xs:complexType abstract="true" <xs:complexType abstract="true"
name="ccmp-request-message-type"> name="ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- blueprintsRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexType
name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsRequest --> <!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confRequest --> <!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 39, line 38 skipping to change at page 59, line 15
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequest --> <!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType"/>
<xs:complexType name="confRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="confInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type"> <xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersRequest" /> <xs:element ref="usersRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType"/>
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="usersInfo"
type="info:users-type" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<!-- userRequest --> <!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- [TODO: sidebarRequest --> <!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="operation"
type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="userInfo"
type="info:user-type"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- Definition of ccmp-response-message-type --> <!-- Definition of ccmp-response-message-type -->
<xs:complexType abstract="true" <xs:complexType abstract="true"
name="ccmp-response-message-type"> name="ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element ref="response-code" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponse --> <!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 40, line 42 skipping to change at page 63, line 14
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsResponse --> <!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType" />
<xs:complexType name="blueprintsResponseType">
<xs:sequence>
<xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType" />
<xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo"
type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsResponse" /> <xs:element ref="confsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsResponseType">
<xs:sequence>
<xs:element name="confsInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type"> <xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confResponse" /> <xs:element ref="confResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersResponse --> <!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence>
<xs:element name="confInfo"
type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type"> <xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersResponse" /> <xs:element ref="usersResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponse --> <!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"/>
</xs:sequence>
</xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type"> <xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userResponse" /> <xs:element ref="userResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- [TODO: sidebarResponse --> <!-- userResponseType -->
<!-- response-code -->
<xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:token">
<xs:enumeration value="success"/>
<xs:enumeration value="pending"/>
<xs:enumeration value="modified"/>
<xs:enumeration value="badRequest"/>
<xs:enumeration value="unauthorized"/>
<xs:enumeration value="forbidden"/>
<xs:enumeration value="objectNotFound"/>
<xs:enumeration value="operationNotAllowed"/>
<xs:enumeration value="deleteFailedParent"/>
<xs:enumeration value="modifyFailedProtected"/>
<xs:enumeration value="requestTimeout"/>
<xs:enumeration value="serverInternalError"/>
<xs:enumeration value="notImplemented"/>
</xs:restriction>
</xs:simpleType>
<!-- blueprintsResponse -->
<xs:element name="blueprintsResponse" <xs:element name="userResponse" type="userResponseType" />
type="blueprintsResponseType" />
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element ref="namespace" <xs:element name="userInfo" type="info:user-type"/>
minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:element name="namespace"> <!-- sidebarsByValResponse -->
<xs:simpleType>
<xs:restriction base="xs:string" />
</xs:simpleType>
</xs:element>
<!-- confsResponse --> <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="confsResponse" <!-- sidebarsByValResponseType -->
type="confsResponseType" /> <xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="confsResponseType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element ref="namespace" <xs:element name="sidebarsByValInfo"
minOccurs="1" type="info:sidebars-by-val-type"/>
maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confRequest -->
<xs:element name="confRequest" <!-- sidebarsByRefResponse -->
type="confRequestType" />
<xs:complexType name="confRequestType"> <xs:complexType name="ccmp-sidebarsByref-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element ref="sidebarsByRefResponse" />
type="operationType"
minOccurs="1"
maxOccurs="1" />
<xs:element name="confInfo"
type="dm:conference-info"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- sidebarsByRefResponseType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="confResponseType"> <xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element name="sidebarsByRefInfo"
type="operationType" type="info:uris-type"/>
minOccurs="1"
maxOccurs="1" />
<xs:element name="confInfo"
type="dm:conference-info"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- userRequest --> <!-- sidebarByValResponse -->
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType"> <xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element ref="sidebarByValResponse" />
type="operationType"
minOccurs="1"
maxOccurs="1" />
<xs:element name="userInfo"
type="dm:user"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponse -->
<xs:element name="userResponse" <!-- sidebarByValResponseType -->
type="userResponseType" /> <xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element name="sidebarByValInfo"
type="operationType" type="info:conference-type"/>
minOccurs="1"
axOccurs="1" />
<xs:element name="userInfo"
type="dm:conference-info"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- usersRequest --> <!-- sidebarByRefResponse -->
<xs:element name="usersRequest"
type="usersRequestType" />
<xs:complexType name="usersRequestType"> <xs:complexType name="ccmp-sidebarByref-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element ref="sidebarByRefResponse" />
type="operationType"
minOccurs="1"
maxOccurs="1" />
<xs:element name="usersInfo"
type="dm:users"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- sidebarByRefResponseType -->
<xs:element name="usersResponse" <xs:element name="sidebarByRefResponse"
type="usersResponseType" /> type="sidebarByRefResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" <xs:element name="sidebarByRefInfo"
type="operationType" type="info:conference-type"/>
minOccurs="1"
maxOccurs="1" />
<xs:element name="usersInfo"
type="dm:users"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- response-code -->
<xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:token">
<xs:enumeration value="success"/>
<xs:enumeration value="pending"/>
<xs:enumeration value="modified"/>
<xs:enumeration value="badRequest"/>
<xs:enumeration value="unauthorized"/>
<xs:enumeration value="forbidden"/>
<xs:enumeration value="objectNotFound"/>
<xs:enumeration value="forbiddenDeleteParent"/>
<xs:enumeration value="forbiddenChangeProtected"/>
<xs:enumeration value="requestTimeout"/>
<xs:enumeration value="serverInternalError"/>
<xs:enumeration value="notImplemented"/>
</xs:restriction>
</xs:simpleType>
<!-- 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="update"/>
<xs:enumeration value="delete"/> <xs:enumeration value="delete"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Figure 15 Figure 24
13. Managing notifications 11. Managing notifications
This section is still "Under Construction" and currently contains This section is still "Under Construction" and currently contains
some views on handling notifications. some views on handling notifications.
One proposal is to stick with SIP notification. Another alternative, One proposal is to stick with SIP notification. Another alternative,
which is commonly done in other web-based systems, is a "call back", which is commonly done in other web-based systems, is a "call back",
i.e., the CCMP client provides the conference server with an HTTP URL i.e., the CCMP client provides the conference server with an HTTP URL
which is invoked when a change occurs. This is apparently how most which is invoked when a change occurs. This is apparently how most
credit card shopping cards work, having implemented one. This works credit card shopping cards work, having implemented one. This works
well for our scenario since a CCMP "client" is likely to be a web well for our scenario since a CCMP "client" is likely to be a web
skipping to change at page 46, line 5 skipping to change at page 70, line 5
Another option being considered is BOSH Another option being considered is BOSH
(http://xmpp.org/extensions/xep-0124.html), which is basically an (http://xmpp.org/extensions/xep-0124.html), which is basically an
extension to XMPP designed with the following aim: "...a transport extension to XMPP designed with the following aim: "...a transport
protocol that emulates a bidirectional stream between two entities protocol that emulates a bidirectional stream between two entities
(such as a client and a server) by efficiently using multiple (such as a client and a server) by efficiently using multiple
synchronous HTTP request/response pairs without requiring the use of synchronous HTTP request/response pairs without requiring the use of
polling or asynchronous chunking." polling or asynchronous chunking."
A final consideration (under discussion only) is basic XMPP. A final consideration (under discussion only) is basic XMPP.
14. Role based access control 12. IANA Considerations
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.
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 registers the the MIME type for the schema. This document also registers the
"XCON" Application Service tag and the "CCMP" Application Protocol "XCON" Application Service tag and the "CCMP" Application Protocol
tag. This document also defines registries for the CCMP operation tag. This document also defines registries for the CCMP operation
types and response codes. types and response codes.
15.1. URN Sub-Namespace Registration 12.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
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>CCMP Messages</title> <title>CCMP Messages</title>
</head> </head>
skipping to change at page 47, line 5 skipping to change at page 70, line 43
<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
15.2. XML Schema Registration 12.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 10 of this document.
15.3. MIME Media Type Registration for 'application/ccmp+xml' 12.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
UTF-8. UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2. 3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related conference control. Some of the data could protocol data related conference control. Some of the data could
be considered private and thus should be protected. be considered private and thus should be protected.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
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.
15.4. DNS Registrations 12.4. DNS Registrations
Section 15.4.1 defines an Application Service tag of "XCON", which is Section 12.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 15.4.2, is used to identify an XCON server that understands Section 12.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
15.4.1. Registration of a Location Server Application Service Tag 12.4.1. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag This section registers a new S-NAPTR/U-NAPTR Application Service tag
for XCON, as mandated by [RFC3958]. for XCON, as mandated by [RFC3958].
Application Service Tag: XCON Application Service Tag: XCON
Intended usage: Identifies a server that supports centralized Intended usage: Identifies a server that supports centralized
conferencing. conferencing.
Defining publication: RFCXXXX Defining publication: RFCXXXX
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
15.4.2. Registration of a Location Server Application Protocol Tag for 12.4.2. Registration of a Location Server Application Protocol Tag for
HELD HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958]. for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol. Manipulation Protocol.
skipping to change at page 48, line 41 skipping to change at page 73, line 4
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958]. for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol. Manipulation Protocol.
Applicable Service Tag(s): XCON Applicable Service Tag(s): XCON
Terminal NAPTR Record Type(s): U Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX Defining Publication: RFCXXXX
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
15.5. CCMP Protocol Registry 12.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.
15.5.1. CCMP Message Types 12.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 7 and defined in the XML
schema in Section 12. The following summarizes the requested schema in Section 10. 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:
blueprintsRequest: Used by a conference control client to query a blueprintsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of available conferencing system for its capabilities, in terms of available
conference blueprints. conference blueprints.
blueprintsResponse: 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 confsRequest: Used by a conference control client to query a
conferencing system for its scheduled/active conferences. conferencing system for its scheduled/active conferences.
confsResponse: The confsResponse returns the list of the currently confsResponse: The confsResponse returns the list of the currently
activated/scheduled conferences at the server. 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"
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.
15.5.2. CCMP Response Codes 12.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
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following thirteen initial response This section pre-registers the following thirteen initial response
codes as described above in Section 8.3: codes as described above in Section 7:
success: This code indicates that the request was successfully success: This code indicates that the request was successfully
processed. processed.
modified: This code indicates that the object was created, but may modified: This code indicates that the object was created, but may
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.., due to
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.
16. Security Considerations 13. 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. In the themselves to conferences or engaging in theft of services. In the
case of a RESTful implementation of the CCMP, implementors need to case of a RESTful implementation of the CCMP, implementors need to
deploy standard HTTP authentication and authorization mechanisms. deploy standard HTTP authentication and authorization mechanisms.
Since conference information may contain secrets such as participant Since conference information may contain secrets such as participant
lists and dial-in codes, all conference control information SHOULD be lists and dial-in codes, all conference control information SHOULD be
carried over TLS (HTTPS). carried over TLS (HTTPS).
17. Acknowledgments 14. Acknowledgments
The authors appreciate the feedback provided by Dave Morgan, Pierre The authors appreciate the feedback provided by Dave Morgan, Pierre
Tane, Lorenzo Miniero and Tobia Castaldi Tane, Lorenzo Miniero and Tobia Castaldi. Special thanks go to
Roberta Presta for her invaluable contribution to this document.
Roberta has worked on the specification of the CCMP protocol at the
University of Napoli for the preparation of her Master thesis. She
has also implemented the CCMP prototype used for the trials and from
which the dumps provided in Section 8 have been extracted.
18. Changes since last Version 15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
The following summarizes the changes between the WG 01 and the 02:
1. Changed the basic approach from REST to HTTP as a transport.
This impacted most of the document - i.e., a major rewrite - 02
is closer to 00 than the 01.
2. Added full example based on prototype.
The following summarizes the changes between the WG 00 and the 01: The following summarizes the changes between the WG 00 and the 01:
1. Changed the basic approach from using SOAP to REST - the 1. Changed the basic approach from using SOAP to REST - the
fundamentals are the same in terms of schema, basic operations. fundamentals are the same in terms of schema, basic operations.
This impacted most sections, in particular introduction and This impacted most sections, in particular introduction and
motivation. motivation.
2. Added new request types - blueprintsRequest, blueprintRequest and 2. Added new request types - blueprintsRequest, blueprintRequest and
confsRequest. The first replaces the optionsRequest and the confsRequest. The first replaces the optionsRequest and the
latter allows the client to get a list of all active conferences. latter allows the client to get a list of all active conferences.
3. Merged all requests into the basic operations table. Added 3. Merged all requests into the basic operations table. Added
summary of RESTful examples (referenced by the basic operations summary of RESTful examples (referenced by the basic operations
table. table.
4. Added examples showing RESTful approach - i.e., HTTP methods for 4. Added examples showing RESTful approach - i.e., HTTP methods for
message exchange. message exchange.
5. Removed requestID from the schema (it should be handle by the 5. Removed requestID from the schema (it should be handle by the
transport - e.g., HTTP). Updated schema (based on current transport - e.g., HTTP). Updated schema (based on current
prototype - it still needs another revision. prototype - it still needs another revision.
6. Added placeholders for Notifications and Role Based Access 6. Added placeholders for Notifications and Role Based Access
Control. Control.
7. Added some text for discovery using DNS (including IANA 7. Added some text for discovery using DNS (including IANA
registrations) registrations)
8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to
informational section. informational section.
19. References 16. References
19.1. Normative References 16.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.
skipping to change at page 52, line 36 skipping to change at page 79, line 29
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., Even, R., and J. Novo, O., Camarillo, G., Morgan, D., Even, R., and J.
Urpalainen, "Conference Information Data Model for Urpalainen, "Conference Information Data Model for
Centralized Conferencing (XCON)", Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-12 (work in progress), draft-ietf-xcon-common-data-model-12 (work in progress),
October 2008. October 2008.
19.2. Informative References 16.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. 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,
skipping to change at page 53, line 25 skipping to change at page 80, line 18
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 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] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. Gudgin, M., Hadley, M., Mendelsohn, N., Nielsen, H., and
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Moreau, J., Mendelsohn, N., Hadley, M., Nielsen, H., and Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered
for CCMP
The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2.
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. A coarser-grained approach to the 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.
For CCMP, the resource (REST) model might appear more attractive,
since the conference operations fit the CRUD approach.
Neither of these approaches were considered ideal as SOAP was not
considered to be general purpose enough for use in a broad range of
operational environments. It is quite awkward to apply a RESTful
approach since the CCMP requires a more complex request/response
protocol in order to maintain the data both in the server and at the
client. This doesn't map very elegantly to the basic request/
response model, whereby a response typically indicates whether the
request was successful or not, rather than providing additional data
to maintain the synchronization between the client and server data.
In addition, the CCMP clients may also receive the data in
Notifications. While the notification method or protocol used by
some conferencing clients can be independent of the CCMP, the same
data in the server is used for both the CCMP and Notifications - this
requires a server application above the transport layer (e.g., HTTP)
for maintaining the data, which in the CCMP model is transparent to
the transport protocol.
A.1. Using SOAP for the CCMP
A remote procedure call (RPC) mechanism for the CCMP could use SOAP
(Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC
-soap12-part2-20030624]), where conferences and the other objects are
modeled as services with associated operations. Conferences and
other objects are selected by their own local identifiers, such as
email-like names for users. This approach has the advantage that it
can easily define atomic operations that have well-defined error
conditions.
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.
A.2. A RESTful approach for the CCMP
Conference objects can also 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 natural URIs.
CCMP can be mapped into the CRUD (Create, Read, Update, Delete)
design pattern. The basic CRUD operations are used to manipulate
conference objects, which are XML documents containing the
information characterizing a specified conference instance, be it an
active conference or a conference blueprint used by the conference
server to create new conference instances through a simple clone
operation.
Following the CRUD approach, CCMP could use a general-purpose
protocol such as HTTP [RFC2616] to transfer domain-specific XML-
encoded data objects defined in the Conference Information Data Model
for Centralized Conferencing [I-D.ietf-xcon-common-data-model].
Following on the CRUD approach, CCMP could follow the well-known REST
(REpresentational State Transfer) architectural style [REST]. The
CCMP could map onto the REST philosophy, by specifying resource URIs,
resource formats, methods supported at each URI and status codes that
have to be returned when a certain method is invoked on a specific
URI. A REST-style approach must ensure sure that all operations can
be mapped to HTTP operations.
The following summarizes the specific HTTP method that could be used
for each of the CCMP Requests:
Retrieve: HTTP GET could be used on XCON-URIs, so that clients can
obtain data about conference objects in the form of XML data model
documents.
Create: HTTP PUT could be used to create a new object as identified
by the XCON-URI or XCON-USERID.
Change: Either HTTP PATCH or HTTP POST could be used to change the
conference object identified by the XCON-URI.
Delete: HTTP DELETE could be used to delete conference objects and
parameters within conference objects identified by the XCON-URI.
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 NS-Technologies
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: chris@ns-technologies.com
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
Italy Italy
Email: spromano@unina.it Email: spromano@unina.it
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
Email: hgs+xcon@cs.columbia.edu Email: hgs+xcon@cs.columbia.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 400 change blocks. 
1329 lines changed or deleted 2210 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/