draft-ietf-xcon-ccmp-05.txt   draft-ietf-xcon-ccmp-06.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: June 27, 2010 NS-Technologies Expires: August 21, 2010 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
December 24, 2009 February 17, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-05 draft-ietf-xcon-ccmp-06
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) can create, The Centralized Conferencing Manipulation Protocol (CCMP) allows a
retrieve, change and delete objects describing a centralized XCON conferencing system client to create, retrieve, change and
conference, such as state and capabilities of the conference, delete objects describing a centralized conference, being a mean to
participants, and their roles. The conference information is control basic and advanced conference features such as conference
contained in XML documents and fragments conforming to the state and capabilities, participants and relative roles and details.
centralized conferencing data model schema. Even though the goal of The CCMP is a state-less, XML-based, client server protocol carrying
the CCMP is to appropriately manage conference state, the mechanisms in its request and response messages conference information in the
upon which the protocol itself is built are based on a state-less form of XML documents and fragments conforming to the centralized
request/response paradigm. Conferencing clients send requests to conferencing data model schema.
conference servers, which respond to the client with the conference
information.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 2, line 5 skipping to change at page 1, line 49
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 June 27, 2010. This Internet-Draft will expire on August 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. XCON Conference Control System Architecture . . . . . . . . . 7 4. XCON Conference Control System Architecture . . . . . . . . . 7
4.1. Conference Objects . . . . . . . . . . . . . . . . . . . 8 4.1. Conference Objects . . . . . . . . . . . . . . . . . . . 8
4.2. Conference Users . . . . . . . . . . . . . . . . . . . . 8 4.2. Conference Users . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10 5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10
5.2. Implementation Approach . . . . . . . . . . . . . . . . . 12 5.2. Implementation Approach . . . . . . . . . . . . . . . . . 13
6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13 6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13 6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 14
6.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14 6.2. CCMP Response Message Type . . . . . . . . . . . . . . . 16
6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17
6.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19 6.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20
6.3.2. confsRequest and confsResponse . . . . . . . . . . . 22 6.3.2. confsRequest and confsResponse . . . . . . . . . . . 22
6.3.3. blueprintRequest and blueprintResponse . . . . . . . 24 6.3.3. blueprintRequest and blueprintResponse . . . . . . . 23
6.3.4. confRequest and confResponse . . . . . . . . . . . . 26 6.3.4. confRequest and confResponse . . . . . . . . . . . . 25
6.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 6.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
6.3.6. userRequest and userResponse . . . . . . . . . . . . 32 6.3.6. userRequest and userResponse . . . . . . . . . . . . 32
6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 37 6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36
6.3.8. sidebarByValRequest and sidebarByValResponse . . . . 39 6.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38
6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 42 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 41
6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 44 6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42
6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 47 6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 45
7. A complete example of the CCMP in action . . . . . . . . . . 51 7. A complete example of the CCMP in action . . . . . . . . . . 49
7.1. Alice retrieves the available blueprints . . . . . . . . 51 7.1. Alice retrieves the available blueprints . . . . . . . . 49
7.2. Alice gets detailed information about a specific 7.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 54 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3. Alice creates a new conference through a cloning 7.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 56 operation . . . . . . . . . . . . . . . . . . . . . . . . 54
7.4. Alice updates conference information . . . . . . . . . . 58
7.5. Alice inserts a list of users in the conference object . 60 7.4. Alice updates conference information . . . . . . . . . . 56
7.6. Alice joins the conference . . . . . . . . . . . . . . . 62 7.5. Alice inserts a list of users in the conference object . 58
7.7. Alice adds a new user to the conference . . . . . . . . . 64 7.6. Alice joins the conference . . . . . . . . . . . . . . . 60
8. Locating a Conference Control Server . . . . . . . . . . . . 67 7.7. Alice adds a new user to the conference . . . . . . . . . 62
9. Managing Notifications . . . . . . . . . . . . . . . . . . . 69 8. Locating a Conference Control Server . . . . . . . . . . . . 65
10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 70 9. Managing Notifications . . . . . . . . . . . . . . . . . . . 67
11. Security Considerations . . . . . . . . . . . . . . . . . . . 72 10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 68
11. Security Considerations . . . . . . . . . . . . . . . . . . . 70
11.1. Assuring that the Proper Conferencing Server has been 11.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 73 contacted . . . . . . . . . . . . . . . . . . . . . . . . 71
11.2. User Authentication and Authorization . . . . . . . . . . 73 11.2. User Authentication and Authorization . . . . . . . . . . 71
11.3. Security and Privacy of Identity . . . . . . . . . . . . 74 11.3. Security and Privacy of Identity . . . . . . . . . . . . 72
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 75 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 73
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 87 13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 87
13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 87 13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 87
13.3. MIME Media Type Registration for 'application/ccmp+xml' . 88 13.3. MIME Media Type Registration for 'application/ccmp+xml' . 88
13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 89 13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 89
13.4.1. Registration of a Conference Control Server 13.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 89 Application Service Tag . . . . . . . . . . . . . . . 89
13.4.2. Registration of a Conference Control Server 13.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 89 Application Protocol Tag for CCMP . . . . . . . . . . 89
13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 90 13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 90
skipping to change at page 5, line 21 skipping to change at page 4, line 21
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.
The CCMP implements the client-server model within the XCON The CCMP implements the client-server model within the XCON
Framework, with the conferencing client and conference control server Framework, with the Conference Control Client and Conference Control
acting as client and server, respectively. The CCMP uses HTTP Server acting as client and server, respectively. The CCMP uses HTTP
[RFC2616] as the protocol to transfer the CCMP requests and [RFC2616] as the protocol to transfer requests and responses, which
responses, which contain the domain-specific XML-encoded data objects contain the domain-specific XML-encoded data objects defined in
defined in the Conference Information Data Model for Centralized [I-D.ietf-xcon-common-data-model] Conference Information Data Model
Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model]. for Centralized Conferencing (XCON Data Model).
Section 4 provides an overview of the Conference Control Section 4 provides an overview of the Conference Control
functionality of the XCON framework, together with a description of functionality of the XCON framework, together with a description of
the main targets CCMP deals with, namely conference objects and the main targets CCMP deals with, namely conference objects and
conference users. A general description of the operations associated conference users. A general description of the operations associated
with protocol messages is given in Section 5 together with with protocol messages is given in Section 5 together with
implementation details. A complete example of the operation of the implementation details. A complete example of the operation of the
CCMP, describing a typical call flow associated with conference CCMP, describing a typical call flow associated with conference
creation and manipulation, is provided in Section 7. Section 12 creation and manipulation, is provided in Section 7. Section 12
provides the XML schema. provides the XML schema.
skipping to change at page 7, line 12 skipping to change at page 6, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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:
XCON aware client: An XCON conferencing system client which is able XCON aware client: An XCON conferencing system client which is able
to use all of the protocols of the XCON framework suite. to issue CCMP requests.
CRUD: CRUD stands for Create/Read/Update/Delete and indicates a
design pattern supporting creating, retrieving, updating and
destroying objects.
REST: REpresentational State Transfer (REST) is an architectural
style, i.e., a coordinated set of architectural constraints. REST
is based on the consideration that a software architecture can
often be specified as an appropriate configuration of components,
data and connectors, all coordinated through constraining their
mutual relationships. Coordination and constraints help achieve a
desired set of architectural properties. [REST]
SOAP: Simple Object Access Protocol defined in
[W3C.REC-soap12-part1-20030624] and
[W3C.REC-soap12-part2-20030624].
4. XCON Conference Control System Architecture 4. XCON Conference Control System Architecture
CCMP supports the XCON framework. Figure 1 depicts a subset of the CCMP supports the XCON framework . Figure 1 depicts a subset of the
"Conferencing System Logical Decomposition" architecture from the "Conferencing System Logical Decomposition" architecture from the
XCON framework document. It illustrates the role that CCMP assumes XCON framework document. It illustrates the role that CCMP assumes
within the overall centralized architecture. within the 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 | .
. +-+-------------------------------------+ | . . +-+-------------------------------------+ | .
skipping to change at page 8, line 34 skipping to change at page 7, line 34
. ^ . . ^ .
. | . . | .
. v . . v .
. +-------------------+ . . +-------------------+ .
. | Conference Control| . . | Conference Control| .
. | Server | . . | Server | .
. +-------------------+ . . +-------------------+ .
. ^ . . ^ .
.........................|.............................. .........................|..............................
| |
|Conference |Centralized
|Control |Conferencing
|Manipulation |Manipulation
|Protocol |Protocol
| |
.........................|.............................. .........................|..............................
. V . . V .
. +----------------+ . . +----------------+ .
. | Conference | . . | Conference | .
. | Control | . . | Control | .
. | Client | . . | Client | .
. +----------------+ . . +----------------+ .
skipping to change at page 9, line 13 skipping to change at page 8, line 13
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 XCON framework and related documents. discussed in the XCON framework and related documents.
Conference object and conference users do represent key elements Conference object and conference users do represent key elements
involved in Conference Control operations. Their identifiers are involved in Conference Control Protocol operations. Their
widely used for creating the CCMP requests and responses. Such identifiers, respectively the conference XCON-URI and the
identifiers, used in CCMP for the conference object (XCON-URI) and conferencing client XCON-USERID, and their XML representations
conference user (XCON-USERID), are introduced in the XCON framework compliant with the XML Schema defined in the XCON data model are
and defined in the XCON data model [I-D.ietf-xcon-common-data-model]. widely used for creating the CCMP requests and responses. The main
The main conference objects and users features are briefly described conference objects and users features envisioned by the XCON
in the following subsections. framework are briefly described in the following subsections.
4.1. Conference Objects 4.1. Conference Objects
Conference objects feature a simple dynamic inheritance-and-override Conference objects feature a simple dynamic inheritance-and-override
mechanism. Conference objects are linked into a tree known as mechanism. Conference objects are linked into a tree known as
"cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree
node inherits attributes from its parent node. The roots of these node inherits attributes from its parent node. The roots of these
inheritance trees are also known as "blueprints". Nodes in the inheritance trees are conference templates also known as
inheritance tree can be active conferences or simply descriptions "blueprints". Nodes in the inheritance tree can be active
that do not currently have any resources associated with them. An conferences or simply descriptions that do not currently have any
object can mark certain of its properties as unalterable, so that resources associated with them (conference reservations). An object
they cannot be overridden. can mark certain of its properties as unalterable, so that they
cannot be overridden. It is envisaged by the framework that a client
MAY specify a parent object (a conference or blueprint) from which
the conference to be created has to inherit values by the mean of the
Conference Control Protocol.
The schema for the conference object is defined in the XCON data Conference objects are uniquely identified by the XCON-URI within the
model. Conference objects are uniquely identified by the XCON-URI. scope of the conferencing system. Such identifier is introduced in
A client MAY specify a parent object (a conference or blueprint) from the XCON framework and defined in the XCON common data model.
which to inherit values.
Conference objects are comprehensively represented through XML
documents compliant with the XML Schema defined in the XCON data
model [I-D.ietf-xcon-common-data-model]. The root element of such
documents is one of type "conference-type" called "<conference-info>"
which encompasses other XML elements describing different conference
features and users as well. By the mean of CCMP, conferencing
clients can use such XML structures to express their preferences in
creation or update and conferencing server can convey conference
information of such a form back to them.
4.2. Conference Users 4.2. Conference Users
Each conference can have zero or more users. All conference Each conference can have zero or more users. All conference
participants are users, but some users may have only administrative participants are users, but some users may have only administrative
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. When a conference is one user at a time to simplify error reporting. When a conference is
cloned from a parent object, users are inherited as well, so that it cloned from a parent object, users are inherited as well, so that it
is easy to set up a conference that has the same set of participants is easy to set up a conference that has the same set of participants
or a common administrator. The Conference Control Server creates or a common administrator. The Conference Control Server creates
individual users, assigning them a unique Conference User Identifier individual users, assigning them a unique Conference User Identifier
(XCON-USERID). (XCON-USERID). The XCON-USERID as identifier of each conferencing
system client is introduced in the XCON framework and defined in the
XCON common data model. Each CCMP request, with an exception pointed
out in Section 6.3.6 representing the case of a user at his first
entrance in the system as a conference participant, MUST carry the
XCON-USERID of the requestor in the proper "confUserID" parameter.
A variety of elements defined in the common <conference-info> element The XCON-USERID acts as a pointer to the user's profile as a
as specified in the XCON data model are used to determine how a conference actor, e.g. her signalling URI and other XCON protocol
specific user expects and is allowed to join a conference as a URIs in general, her role (moderator, participant, observer, etc.),
participant or as a user with specific privileges (e.g., observer). her display text, her joining information and so on. A variety of
For example, each <target> element representing a user in the elements defined in the common <conference-info> element as specified
conference <allowed-user-list> shows a "method" attribute which in the XCON data model are used to describe the users related to a
defines how the user is expected to join the conference, i.e. conference, in the first place the <users> element, as well as each
"dial-in" for users that are allowed to dial, "dial-out" for users <user> element included in it. For example, it is possible to
that the conference focus will be trying to reach. "dial-in" is the determine how a specific user expects and is allowed to join a
default. If the conference is currently active, dial-out users are conference by looking at the <allowed-user-list> in <users>: each
contacted immediately; otherwise, they are contacted at the start of <target> element involved in such a list represents a user and shows
the conference. The conference control protocol provides a mean to a "method" attribute defining how the user is expected to join the
conference, i.e. "dial-in" for users that are allowed to dial, "dial-
out" for users that the conference focus will be trying to reach
(with "dial-in" being the default mode). If the conference is
currently active, dial-out users are contacted immediately;
otherwise, they are contacted at the start of the conference. The
CCMP, acting as the Conference Control Protocol, provides a means to
manipulate these and other kinds of user-related features. manipulate these and other kinds of user-related features.
The conference control server assigns a unique Conference User As a consequence of an explicit user registration to a specific XCON
Identifier (XCON-USERID) to each conferencing system user. The conferencing system, conferencing clients are usually provided
conference control server uses the XCON-USERID to change or delete (besides the XCON-USERID) with log-in credentials (i.e. username and
<user> elements. Depending upon policies and privileges, specific password). Such credentials can be used to authenticate the XCON
conference control clients MAY also manipulate <user> elements. aware client issuing CCMP requests, in order to provide her with the
right authorization information. To this purpose, both username and
password SHOULD be carried in a CCMP request as part of the "subject"
parameter whenever a registered conferencing client wishes to contact
a CCMP server. The specific registration modality is out of the
scope of the CCMP document.
5. Protocol Overview 5. Protocol Overview
CCMP is a client-server, XML-based, state-less protocol, which has CCMP is a client-server, XML-based protocol, which has been
been specifically conceived to provide users with the necessary means specifically conceived to provide users with the necessary means for
for the creation, retrieval, modification and deletion of conference the creation, retrieval, modification and deletion of conference
objects. objects. CCMP is also state-less, which means implementations can
safely handle transactions independently from each other.
Conference-related information is encapsulated into CCMP messages in
the form of XML documents or XML document fragments compliant with
the XCON data model representation.
Section 5.1 specifies the basic operations that can create, retrieve, Section 5.1 specifies the basic operations that can create, retrieve,
modify and delete conference-related information in a centralized modify and delete conference-related information in a centralized
conference. The core set of objects manipulated in the CCMP protocol conference. The core set of objects manipulated in the CCMP protocol
includes conference blueprints, the conference object, users, and includes conference blueprints, the conference object, users, and
sidebars. sidebars.
Conference-related information is encapsulated into CCMP messages in CCMP has been conceived as completely independent from underlying
the form of documents or document fragments compliant with the XCON protocols, which means that there can be different ways to carry CCMP
data model representation. Implementation details are presented in messages across the network, from a conferencing client to a
Section 5.2 conferencing server. Nevertheless, it is recommended to use HTTP as
a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies. Implementation details
are presented in Section 5.2
5.1. Protocol Operations 5.1. Protocol Operations
The main operations provided by CCMP belong in four general The main operations provided by CCMP belong in four general
categories: categories:
create: for the creation of a conference, a conference user, a create: for the creation of a conference, a conference user, a
sidebar, or a blueprint. sidebar, or a blueprint.
retrieve: to get information about the current state of either a retrieve: to get information about the current state of either a
conference object (be it an actual conference or a blueprint, or a conference object (be it an actual conference or a blueprint, or a
sidebar) or a conference user. A retrieve operation can also be sidebar) or a conference user. A retrieve operation can also be
used to obtain the XCON-URIs of the active conferences and/or used to obtain the XCON-URIs of the current conferences (active or
blueprints available at the server. registered) handled by the conferencing server and/or the
available blueprints.
update: to modify the current features of a specified conference or update: to modify the current features of a specified conference or
conference user. conference user.
delete: to remove from the system a conference object or a delete: to remove from the system a conference object or a
conference user. conference user.
Thus, the main targets of CCMP operations are: Thus, the main targets of CCMP operations are:
o conference objects associated with either active or registered o conference objects associated with either active or registered
conferences, conferences,
o conference objects associated with blueprints, o conference objects associated with blueprints,
o conference objects associated with sidebars, both embedded in the o conference objects associated with sidebars, both embedded in the
main conference (i.e. <entry> elements in <sidebars-by-value>) and main conference (i.e. <entry> elements in <sidebars-by-value>) and
external to it (i.e. whose xcon-uris are included in the <entry> external to it (i.e. whose xcon-uris are included in the <entry>
elements of <sidebars-by-ref>)], elements of <sidebars-by-ref>),
o <user> elements associated with conference users, o <user> elements associated with conference users,
o the list of XCON-URIs related to conferences and blueprints o the list of XCON-URIs related to conferences and blueprints
available at the server, for which only retrieval operations are available at the server, for which only retrieval operations are
allowed. allowed.
Each operation in the protocol model is atomic and either succeeds or Each operation in the protocol model is atomic and either succeeds or
fails as a whole. The conference server MUST ensure that the fails as a whole. The conference server MUST ensure that the
operations are atomic in that the operation invoked by a specific operations are atomic in that the operation invoked by a specific
skipping to change at page 12, line 27 skipping to change at page 11, line 36
functionality are out of scope for the CCMP protocol specification functionality are out of scope for the CCMP protocol specification
and are implementation specific for a conference server. Thus, the and are implementation specific for a conference server. Thus, the
conference server first checks all the parameters, before making any conference server first checks all the parameters, before making any
changes to the internal representation of the conference object. For changes to the internal representation of the conference object. For
example, it would be undesirable to change the <subject> of the example, it would be undesirable to change the <subject> of the
conference, but then detect an invalid URI in one of the <service- conference, but then detect an invalid URI in one of the <service-
uris> and abort the remaining updates. Also, since multiple clients uris> and abort the remaining updates. Also, since multiple clients
can modify the same conference objects, conference clients SHOULD can modify the same conference objects, conference clients SHOULD
first obtain the current object from the conference server and then first obtain the current object from the conference server and then
update the relevant data elements in the conference object prior to update the relevant data elements in the conference object prior to
invoking a specific operation on the conference server. invoking a specific operation on the conference server. In order to
effectively manage modifications to conference data, a versioning
approach is exploited in the CCMP. More precisely, each conference
object is associated with a version number indicating the most up to
date view of the conference at the server's side. Such version
number is reported to the clients when answering their requests. A
client willing to make modifications to a conference object has to
send an update message to the server. In case the modifications are
all successfully applied, the server sends back to the client a
"success" response which also carries information about the current
server-side version of the modified object. With such approach, a
client which is working on version "X" of a conference object and
finds inside a "success" response a version number which is "X+1" can
be sure that the version it was aware of was the most up to date. On
the other hand, if the "success" response carries back a version
which is at least "X+2", the client can detect that the object that
has been modified at the server's side was more up to date than the
one it was working upon. This is clearly due to the effect of
concurrent modification requests issued by independent clients.
Hence, for the sake of having available the latest version of the
modified object, the client can send to the conference server a
further "retrieve" request. In no case a copy of the conference
object available at the server is returned to the client as part of
the update response message. Such a copy can always be obtained
through an ad-hoc "retrieve" message.
In order to effectively manage modifications to conference data, a Based on the above considerations, all CCMP response messages
versioning approach is implemented in the CCMP. More precisely, each carrying in their body a conference document (or a fragment of it)
conference object is associated with a version number indicating the MUST contain a "version" parameter. This does not hold for request
most up to date view of the conference at the server's side. This messages, for which the "version" parameter is not at all required,
version number is reported to the clients in response to their since it represents useless information for the server: as long as
requests. A client sends an "update" message to the server to make the required modifications can be applied to the target conference
modifications to a conference object. If the modifications are all object with no conflicts, the server does not care whether or not the
successfully applied, the server sends a "success" response to the client had an up to date view of the information stored at its side.
client. This response contains information about the current server- This said, it stands clear that a client which has subscribed at the
side version of the modified object. With this approach, a client server, through the XCON event package [I-D.ietf-xcon-event-package],
working on version "X" of a conference object that finds a version to notifications about conference object modifications, will always
number which is "X+1" inside a "success" response can be certain that have the most up to date version of that object available at his
the version being used is the most up to date. On the other hand, if side.
the "success" response contains a version which is at least "X+2",
the client can detect that the object that has been modified at the
server's side was more up to date than the one it was working upon.
This is clearly due to the effect of concurrent modification requests
issued by independent clients. Hence, to ensure that the client has
the latest version of the modified object, the client can send an
additional "retrieve" request to the conference server. If a copy of
the conference object is not returned to the client as part of the
"update" response message, the client can obtain a copy through an
ad-hoc "retrieve" message.
Based on the above considerations, all CCMP response messages except A final consideration concerns the relation between the CCMP and the
those associated with the retrieval of either the list of blueprints main entities it manages, i.e. conference objects. Such objects have
or the list of conferences MUST contain a mandatory "version" to be compliant with the XCON data-model, which identifies some
parameter. The "version" parameter is not included in request elements/attributes as mandatory. From the CCMP standpoint this can
messages, since it represents information the server does not need: become a problem in cases of client-initiated operations, like the
as long as the required modifications can be applied to the target creation/update of conference objects. In such cases, not all of the
conference object with no conflicts, the server does not care whether mandatory data can be known in advance to the client issuing a CCMP
the client had an up to date view of the information. Thus, a client request. As an example, a client has no means to know, at the time
which has subscribed at the server, through the XCON event package it issues a conference creation request, the XCON-URI that the server
[I-D.ietf-xcon-event-package], to notifications about conference will assign to the yet-to-be-created conference and hence it is not
object modifications, always has the most up to date version of the able to appropriately fill with that value the mandatory "entity"
conference object. attribute of the conference document contained in the request. To
solve this kind of issues, the CCMP will fill all mandatory data
model fields, for which no value is available at the client at the
time the request is constructed, with fake values in the form of
wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental
index initialized to a value of 1). Upon reception of the mentioned
kinds of requests, the server will: (i) generate the proper
identifier(s); (ii) produce a response in which the received fake
identifier(s) carried in the request has (have) been replaced by the
newly created one(s). With this approach we maintain compatibility
with the data model requirements, at the same time allowing for
client-initiated manipulation of conference objects at the server's
side (which is, by the way, one of the main goals for which the CCMP
protocol has been conceived at the outset).
5.2. Implementation Approach 5.2. Implementation Approach
There have been a number of different proposals as to the most There have been a number of different proposals as to the most
suitable implementation solution for the CCMP. A non-exhaustive suitable implementation solution for the CCMP. A non-exhaustive
summary of the most interesting ones is provided in Appendix A. The summary of the most interesting ones is provided in Appendix A. The
solution for the CCMP defined in this document is viewed as a good solution for the CCMP defined in this document is viewed as a good
compromise amongst the most notable past candidates and is referred compromise amongst the most notable past candidates and is referred
to as "HTTP transport plus CCMP body". With this approach, CCMP is to as "HTTP single-verb transport plus CCMP body". With this
able to take advantage of existing HTTP functionality. As with SOAP, approach, CCMP is able to take advantage of existing HTTP
the CCMP uses a "single HTTP verb" for transport (i.e. a single functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
transaction type for each request/response pair); this allows transport (i.e. a single transaction type for each request/response
decoupling CCMP messages from HTTP messages. Similarly, as with any pair); this allows decoupling CCMP messages from HTTP messages.
RESTful approach, CCMP messages are inserted directly in the body of Similarly, as with any RESTful approach, CCMP messages are inserted
HTTP messages, thus avoiding any unnecessary processing and directly in the body of HTTP messages, thus avoiding any unnecessary
communication burden associated with further intermediaries. With processing and communication burden associated with further
this approach, no modification to the CCMP messages/operations is intermediaries. With this approach, no modification to the CCMP
required to use a different transport protocol. messages/operations is required to use a different transport
protocol.
The remainder of this document focuses on the selected approach. The The remainder of this document focuses on the selected approach. The
CCMP protocol inserts XML-based CCMP requests into the body of HTTP CCMP protocol inserts XML-based CCMP requests into the body of HTTP
POST operations and retrieves responses from the body of HTTP "200 POST operations and retrieves responses from the body of HTTP "200
OK" messages. CCMP messages have a MIME-type of "application/ OK" messages. CCMP messages have a MIME-type of "application/
ccmp+xml", which appears inside the "Content-Type" and "Accept" ccmp+xml", which appears inside the "Content-Type" and "Accept"
fields of HTTP requests and responses. Section 10 provides the fields of HTTP requests and responses. Section 10 provides the
complete requirements for an HTTP implementation to support the CCMP. complete requirements for an HTTP implementation to support the CCMP.
6. CCMP messages 6. CCMP messages
skipping to change at page 14, line 18 skipping to change at page 14, line 18
request message is defined in Section 6.1. The general CCMP response request message is defined in Section 6.1. The general CCMP response
message is defined in Section 6.2. The details of the specific message is defined in Section 6.2. The details of the specific
message type which is carried in the CCMP request and response message type which is carried in the CCMP request and response
messages are described in Section 6.3. CCMP response codes are messages are described in Section 6.3. CCMP response codes are
listed in Section 6.4 listed in Section 6.4
6.1. CCMP Request Message Type 6.1. CCMP Request Message Type
A CCMP request message is comprised of the following parameters: A CCMP request message is comprised of the following parameters:
subject: An optional parameter containing username and password of
the client registered at the conferencing system. Each user who
subscribes to the conferencing system is assumed to be equipped
with those credentials and SHOULD enclose them in each CCMP
request she issues. These fields can be used to control that the
user sending the CCMP request has the authority to perform the
entailed operation. The same fields can also be exploited to
carry out other Authorization, Authentication and Accounting (AAA)
procedures.
confUserID: An optional parameter containing the XCON-USERID of the confUserID: An optional parameter containing the XCON-USERID of the
client. The "confUserID" parameter is used to determine if the client. The XCON-USERID is used to identify any conferencing
conference control client has the authority to perform the client within the context of the conferencing system and it is
operation, as well as other Authorization, Authentication and assinged by the conferencing server at each conferencing client
Accounting (AAA) procedures. The attribute is REQUIRED in the who interacts with it. The "confUserID" parameter is REQUIRED in
CCMP request and response messages with the exception of the case the CCMP request and response messages with the exception of the
of a user who has no XCON-USERID and who wants to enter, via CCMP, case of a user who has no XCON-USERID and who wants to enter, via
a conference whose identifier is known. In such case, a side- CCMP, a conference whose identifier is known. In such case, a
effect of the request is that the user is provided with an side-effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 6.3.6. will be provided in Section 6.3.6.
confObjID: An optional parameter containing the XCON-URI of the confObjID: An optional parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter refining the type of specialized operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest" requests except for the "blueprintsRequest" and "confsRequest"
specialized messages. specialized messages.
password: An optional parameter that MUST be inserted in all conference-password: An optional parameter that MUST be inserted in
requests whose target conference object is password-protected (as all requests whose target conference object is password-protected
per the <conference-password> element in (as per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]). [I-D.ietf-xcon-common-data-model]).
specialized request message: This is specialization of the generic specialized request message: This is specialization of the generic
request message (e.g., blueprintsRequest), containing parameters request message (e.g., blueprintsRequest), containing parameters
that are dependent on the specific request sent to the server. A that are dependent on the specific request sent to the server. A
specialized request message MUST be included in the CCMP request specialized request message MUST be included in the CCMP request
message. The details for the specialized messages and associated message. The details for the specialized messages and associated
parameters are provided in Section 6.3. parameters are provided in Section 6.3.
<!-- Definition of CCMP Request -->
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
<!-- CCMP request definition --> <!-- Definition of ccmp-request-type-->
<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:complexType> </xs:complexType>
<!-- Definition of ccmp-request-message-type --> <!-- Definition of ccmp-request-message-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="confUserID" type="xs:string" <xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string" <xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
</xs:sequence> <xs:element name="conference-password" type="xs:string"
</xs:complexType> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 2: Structure of CCMP Request messages Figure 2: Structure of CCMP Request messages
6.2. CCMP Response Message Type 6.2. CCMP Response Message Type
A CCMP response message is comprised of the following parameters: A CCMP response message is comprised of the following parameters:
confUserID: A mandatory parameter in CCMP response messages confUserID: A mandatory parameter in CCMP response messages
containing the XCON-USERID of the conferencing client who issued containing the XCON-USERID of the conferencing client who issued
the CCMP request message. the CCMP request message.
skipping to change at page 16, line 10 skipping to change at page 16, line 25
operation: An optional parameter for CCMP response messages. This operation: An optional parameter for CCMP response messages. This
parameter is REQUIRED in all responses except for the parameter is REQUIRED in all responses except for the
"blueprintsResponse" and "confsResponse" specialized messages. "blueprintsResponse" and "confsResponse" specialized messages.
response-code: A mandatory parameter containing the response code response-code: A mandatory parameter containing the response code
associated with the request. The response code MUST be chosen associated with the request. The response code MUST be chosen
from the codes listed in Section 6.4. from the codes listed in Section 6.4.
response-string: An optional reason string associated with the response-string: An optional reason string associated with the
response. In case of an error, the string can be used to provide response. In case of an error, in particular, such string can be
the client with detailed information about the error. used to provide the client with detailed information about the
error itself.
version: An optional parameter reflecting the current version number version: An optional parameter reflecting the current version number
of the conference object referenced by the confObjID. The version of the conference object referred by the confObjID. This number
number is contained in the "version" attribute of the <conference- is contained in the "version" attribute of the <conference-info>
info> element related to that conference. element related to that conference.
specialized response message: This is a specialization of the specialized response message: This is specialization of the generic
generic response message, containing parameters that are dependent response message, containing parameters that are dependent on the
on the specific request sent to the server (e.g., specific request sent to the server (e.g., blueprintsResponse). A
blueprintsResponse). A specialized response message SHOULD be specialized response message SHOULD be included in the CCMP
included in the CCMP response message, except in an error response message, except in an error situation where the CCMP
situation where the CCMP request message did not contain a valid request message did not contain a valid specialized message. In
specialized message. In this case, the conference server MUST this case, the conference server MUST return a "response-code" of
return a "response-code" of "badRequest". The details for the "badRequest". The details for the specialized messages and
specialized messages and associated parameters are provided in associated parameters are provided in Section 6.3.
Section 6.3.
<!-- Definition of CCMP Response -->
<xs:element name="ccmpResponse" type="ccmp-response-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP response definition --> <!-- Definition of ccmp-response-type -->
<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:complexType> </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="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType" <xs:element name="operation" minOccurs="0"
minOccurs="0" maxOccurs="1" /> maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element ref="response-code" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
<xs:element name="response-string" type="xs:string" <xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 3: Structure of CCMP Response message Figure 3: Structure of CCMP Response message
6.3. Detailed messages 6.3. Detailed messages
Based on the request and response message structures described in Based on the request and response message structures described in
Section 6.1 and Section 6.2, the following summarizes the specialized Section 6.1 and Section 6.2, the following summarizes the specialized
CCMP request/response types described in this document: CCMP request/response types described in this document:
skipping to change at page 19, line 8 skipping to change at page 19, line 8
require an "operation" parameter. The corresponding response MUST require an "operation" parameter. The corresponding response MUST
contain the same operation. Note that some entries are labeled "N/A" contain the same operation. Note that some entries are labeled "N/A"
indicating the operation is invalid for that request type. In the indicating the operation is invalid for that request type. In the
case of an "N/A*", the operation MAY be allowed for specific case of an "N/A*", the operation MAY be allowed for specific
privileged users or system administrators, but is not part of the privileged users or system administrators, but is not part of the
functionality included in this document. functionality included in this document.
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete | | Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | | | ------------- | | | | |
| -Request Type | | | | | | Request Type | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprintsReq | Get list | N/A | N/A | N/A | | blueprints | Get list | N/A | N/A | N/A |
| uest | of | | | | | Request | of | | | |
| | blueprints | | | | | | blueprints | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| blueprintRequ | Get | N/A* | N/A* | N/A* | | blueprint | Get | N/A* | N/A* | N/A* |
| est | blueprint | | | | | Request | blueprint | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| confsRequest | Get list | N/A | N/A | N/A | | confsRequest | Get list | N/A | N/A | N/A |
| | of confs | | | | | | of confs | | | |
| | (active, | | | |
| | etc.) | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| confRequest | Gets | Creates | Changes | Deletes | | confRequest | Gets | Creates | Changes | Deletes |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object or | object | object | Object as | | | object | object | object | object |
| | blueprint | | | a whole |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| usersRequest | Gets | N/A | Changes | N/A | | usersRequest | Gets | N/A(**) | Changes | N/A(**) |
| | specific | | specified | | | | <users> | | <users> | |
| | users | | users | |
| | element | | element | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| userRequest | Gets | Adds a | Changes | Deletes | | userRequest | Gets | Adds a | Changes | Deletes |
| | specific | user to a | specified | user | | | specified | <user> to | specified | specified |
| | user | conf (**) | user | element as | | | <user> | a conf | <user> | <user> |
| | element | | element | a whole | | | | (***) | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarsByVal | Gets | N/A | N/A | N/A | | sidebarsByVal | Gets | N/A | N/A | N/A |
| Request | sidebars-b | | | | | Request | <sidebars- | | | |
| | y -val | | | | | | by-val> | | | |
| | element | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarsByRef | Gets | N/A | N/A | N/A | | sidebarsByRef | Gets | N/A | N/A | N/A |
| Request | sidebars-b | | | | | Request | <sidebars- | | | |
| | y -ref | | | | | | by-ref> | | | |
| | element | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarByValR | Gets a | Creates a | Adds or | Removes/ | | sidebarByVal | Gets | Creates | Changes | Deletes |
| equest | sidebar | sidebar by | modifies a | deletes | | Request | sidebar- | sidebar- | sidebar- | sidebar- |
| | element | cloning | sidebar | entire | | | by-val | by-val | by-val | by-val |
| | | existing | | sidebar |
| | | conf | | |
| | | object | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarByRefR | Gets a | Creates | Adds or | Removes/ | | sidebarByRef | Gets | Creates | Changes | Deletes |
| equest | sidebar | sidebar by | modifies | deletes | | Request | sidebar- | sidebar- | sidebar- | sidebar- |
| | element | cloning | sidebar | entire | | | by-ref | by-ref | by-ref | by-ref |
| | | existing | | sidebar |
| | | conf | | |
| | | object | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 1: Request Type Operation Specific Processing
(**): This operation can involve the creation of an XCON-UserID, if (**): These operations are not allowed for a usersRequest message,
the sender does not add it in the "confUserID" parameter, or if the since the <users> section, which is the target element of such a
"entity" field of the userInfo parameter is void. request, is created and removed in conjuntcion with, respectively,
the creation and deletion of the associated conference document.
Thus, "update" and "retrieve" are the only semantically correct
operations for such message.
(***): This operation can involve the creation of an XCON-USERID, if
the sender does not add it in the "confUserID" parameter, and/or if
the "entity" field of the "userInfo" parameter is void.
Additional parameters included in the specialized CCMP request/ Additional parameters included in the specialized CCMP request/
response messages are detailed in the subsequent sections. response messages are detailed in the subsequent sections.
6.3.1. blueprintsRequest and blueprintsResponse 6.3.1. blueprintsRequest and blueprintsResponse
A "blueprintsRequest" (Figure 4) message is sent to request the list A "blueprintsRequest" (Figure 4) message is sent to request the list
of XCON-URIs associated with the available blueprints from the of XCON-URIs associated with the available blueprints from the
conference server. Such URIs can be subsequently used by the client conference server. Such URIs can be subsequently used by the client
to access detailed information about a specified blueprint with a to access detailed information about a specified blueprint with a
specific "blueprintRequest" message per Section 6.3.3. A specific blueprintRequest message per Section 6.3.3. The
"blueprintsRequest" message REQUIRES no additional parameters beyond "confUserID" parameter MUST be included in every blueprintsRequest/
those specified for the basic CCMP request message. The "confObjID" Response message and reflect the XCON-USERID of the conferencing
and "operation" parameters MUST NOT be included in the request or client issuing the request. A blueprintsRequest message REQUIRES no
response for this transaction. A "blueprintsRequest" message MAY "confObjID" and "operation" parameters, since it is not targetted to
contain an optional "xpathFilter" parameter, which can be used to a specific conference instance and it is conceived as a "retrieve-
instruct the server on how to filter-out unwanted information from only" request. In order to obtain a specific subset of the available
the response. This parameter is of type "xs:string" for generality. blueprints, a client may specify a selection filter providing an
The "xpathFilter" parameter MUST represent a syntactically correct appropriate xpath query in the optional "xpathFilter" parameter of
XPath [W3C.REC-xpath-19991116] string used by the server to properly the request. For example, to select blueprints having both audio and
query the conference document database it manages. video stream support, a possible xpathFilter value could be: "/
conference-info[conference-description/available-media/entry/
type='audio' and conference-description/available-media/entry/
type='video']".
The associated "blueprintsResponse" message SHOULD contain, as shown The associated "blueprintsResponse" message SHOULD contain, as shown
in Figure 4, a "blueprintsInfo" parameter containing the above in Figure 4, a "blueprintsInfo" parameter containing the above
mentioned XCON-URI list. If the "blueprintsInfo" parameter is empty, mentioned XCON-URI list.
the conference control client MAY attempt to use a local default
blueprint to create conferences. However, the handling in this
situation is specific to the conference control client
implementation.
<xs:complexType name="ccmp-blueprints-request-message-type"> <!-- blueprintsRequest -->
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="blueprintsRequest" <xs:complexType name="ccmp-blueprints-request-message-type">
type="blueprintsRequestType" /> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="blueprintsRequestType"> <!-- blueprintsRequestType -->
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- blueprintsResponse --> <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType --> <xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:element name="blueprintsResponse" <!-- blueprintsResponse -->
type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintsInfo" <xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 4: Structure of the blueprintsRequest and blueprintsResponse Figure 4: Structure of the blueprintsRequest and blueprintsResponse
messages messages
6.3.2. confsRequest and confsResponse 6.3.2. confsRequest and confsResponse
A "confsRequest" message is used to retrieve, from the server, the A "confsRequest" message is used to retrieve, from the server, the
list of XCON-URIs associated with active and registered conferences. list of XCON-URIs associated with active and registered conferences
A "confsRequest" message REQUIRES no additional parameters beyond currently handled by the conferencing system. The "confUserID"
those specified for the basic CCMP request message. The "confObjID" parameter MUST be included in every confsRequest/Response message and
parameter MUST NOT be included in the confsRequest message. The reflect the XCON-USERID of the conferencing client issuing the
"confsRequest" message is of a "retrieve-only" type, since the sole request. The "confObjID" parameter MUST NOT be included in the
purpose is to collect information available at the conference server. confsRequest message. The "confsRequest" message is of a "retrieve-
Thus, an "operation" parameter MUST NOT be included in a only" type, since the sole purpose is to collect information
"confsRequest" message. The associated "confsResponse" message available at the conference server. Thus, an "operation" parameter
SHOULD contain the list of XCON-URIs in the "confsInfo" parameter. A MUST NOT be included in a "confsRequest" message. In order to
user, upon receipt of the response message, can interact with the retrieve a specific subset of the available conferences, a client may
available conference objects through further CCMP messages. A specify a selection filter providing an appropriate xpath query in
"confsRequest" message MAY contain an optional "xpathFilter" the optional "xpathFilter" parameter of the request. For example, to
parameter, which can be used to instruct the server on how to filter- select only the registered conferences, a possible xpathFilter value
out unwanted information from the response. This parameter is of could be: "/conference-info[conference-description/conference-state/
type "xs:string" for generality. The "xpathFilter" parameter MUST active='false']". The associated "confsResponse" message SHOULD
represent a syntactically correct XPath [W3C.REC-xpath-19991116] contain the list of XCON-URIs in the "confsInfo" parameter. A user,
string used by the server to properly query the conference document upon receipt of the response message, can interact with the available
database it manages. As an example, to retrieve just registered conference objects through further CCMP messages.
conferences, a CCMP client can configure the mentioned "xpathFilter"
parameter as follows: xpathFilter="/
info:conference-info[info:conference-state/info:active='false']";
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <!-- confsRequest -->
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType --> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" /> <xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType"> <xs:complexType name="confsRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/> <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType --> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="confsResponse" type="confsResponseType"/> <!-- confsResponseType -->
<xs:complexType name="confsResponseType"> <xs:element name="confsResponse" type="confsResponseType"/>
<xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confsInfo" <xs:element name="confsInfo" type="info:uris-type"
type="info:uris-type" minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 5: Structure of the confsRequest and confsResponse messages Figure 5: Structure of the confsRequest and confsResponse messages
6.3.3. blueprintRequest and blueprintResponse 6.3.3. blueprintRequest and blueprintResponse
Through a "blueprintRequest", a client can manipulate the conference Through a "blueprintRequest", a client can manipulate the conference
object associated with a specified blueprint. The request MUST object associated with a specified blueprint. Further than the
include an "operation" parameter and a "confObjID" parameter. The "confUserID" parameter, the request MUST include the "confObjID" and
the "operation" one. Again, the "confUserID" parameter MUST be
included in every blueprintRequest/Response message and reflect the
XCON-USERID of the conferencing client issuing the request. The
"confObjID" parameter MUST contain the XCON-URI of the blueprint, "confObjID" parameter MUST contain the XCON-URI of the blueprint,
which might have been previously retrieved through a which might have been previously retrieved through a
"blueprintsRequest" message. The blueprintRequest message SHOULD NOT "blueprintsRequest" message.
contain an "operation" parameter other than "retrieve". The
"create", "update" and "delete" operations SHOULD NOT be included in The blueprintRequest message SHOULD NOT contain an "operation"
a "blueprintRequest" message except in the case of privileged users parameter other than "retrieve". The "create", "update" and "delete"
(e.g. the conference server administration staff). operations SHOULD NOT be included in a "blueprintRequest" message
except in the case of privileged users (e.g. the conference server
administration staff), who might authenticate themselves by the mean
of the "subject" request parameter.
A blueprintRequest/retrieve carrying a "confObjID" which is not
associated with one of the available system's blueprints will
generate, on the server's side, a blueprintResponse message
containing an "objectNotFound" error code. This holds also for the
case in which the mentioned "confObjID" is related to an existing
conference document stored at the server, but associated with an
actual conference (be it active or registered) or with a sidebar
rather than a blueprint.
In the case of "response-code" of "success" for a "retrieve" In the case of "response-code" of "success" for a "retrieve"
operation, the "blueprintInfo" parameter MUST be included in the operation, the "blueprintInfo" parameter MUST be included in the
"blueprintResponse" message. The "blueprintInfo" parameter contains "blueprintResponse" message. The "blueprintInfo" parameter contains
the conference document associated with the blueprint as identified the conference document associated with the blueprint as identified
by the "confObjID" parameter specified in the blueprintRequest. by the "confObjID" parameter specified in the blueprintRequest.
If a response code of "objectNotFound" is received in a
"blueprintResponse" message, a conference control client may attempt
to retrieve another conference blueprint if more than one had been
received in the "blueprintsResponse" message. If there was only one
blueprint in the "blueprintsResponse" initially, then the client
should send another "blueprintsRequest" message to determine if there
may be new or additional blueprints for the specific conferencing
system. If this "blueprintsResponse" message contains no blueprints,
the handling is specific to the conference control client.
<!-- blueprintRequest --> <!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type"> <xs:complexType name="ccmp-blueprint-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="blueprintRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType"/> <xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- blueprintResponse --> <!-- 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: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>
<xs:element name="blueprintResponse" type="blueprintResponseType"/> <!-- blueprintResponseType -->
<xs:complexType name="blueprintResponseType"> <xs:element name="blueprintResponse" type="blueprintResponseType"/>
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"/> <xs:complexType name="blueprintResponseType">
</xs:sequence> <xs:sequence>
</xs:complexType> <xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 6: Structure of the blueprintRequest and blueprintResponse Figure 6: Structure of the blueprintRequest and blueprintResponse
messages messages
6.3.4. confRequest and confResponse 6.3.4. confRequest and confResponse
With a "confRequest" message, CCMP clients can manipulate conference With a "confRequest" message, CCMP clients can manipulate conference
objects associated with either active or registered conferences objects associated with either active or registered conferences. The
(blueprints or reservations). The request MUST include an "confUserID" parameter MUST be included in every confRequest/Response
"operation" parameter. Depending upon the type of "operation" a message and reflect the XCON-USERID of the conferencing client
"confObjID" parameter MAY be included. The "confObjID" parameter issuing the request. ConfRequest and confResponse messages MUST also
contains the XCON-URI of the specific active or registered include an "operation" parameter. ConfResponse messages MUST return
conference. The requirements for inclusion of "confInfo" parameter to the requestor a "response-code" and MAY contain a "response-
depends upon the specific "operation" in the confRequest/confResponse string" explaining it. Depending upon the type of "operation", a
and are detailed below. The detailed information included in the "confObjID" and "confInfo" parameter MAY be included in the
"confInfo" parameter MUST follow the rules as specified in the XCON confRequest and response. The requirements for inclusion of
Data Model document [I-D.ietf-xcon-common-data-model]. "confObjID" and "confInfo" parameter in the confRequest/confResponse
messages and are detailed below for each "operation" case.
To create a new conference through a "confRequest" message, two The creation case deserves care. To create a new conference through
approaches can be considered: a "confRequest" message, two approaches can be considered:
1. Creation through explicit cloning: the "confObjID" parameter MUST 1. Creation through explicit cloning: the "confObjID" parameter MUST
contain the XCON-URI of either the blueprint, or of the contain the XCON-URI of the blueprint or of the conference to be
conference, to be cloned, while the "confInfo" parameter MUST NOT cloned, while the "confInfo" parameter MUST NOT be included in
be included in the confRequest; the confRequest;
2. Creation through implicit cloning (also known as "direct 2. Creation through implicit cloning (also known as "direct
creation"): the "confObjID" parameter MUST NOT be included in the creation"): the "confObjID" parameter MUST NOT be included in the
request and the CCMP client can describe the desired conference request and the CCMP client can describe the desired conference
to be created through the "confInfo" parameter. If no "confInfo" to be created using the "confInfo" parameter. If no "confInfo"
parameter is provided in the request, the new conference will be parameter is provided in the request, the new conference will be
created as a clone of the system's default blueprint. created as a clone of the system default blueprint.
In both cases, the confResponse, for a successful completion of a In both creation cases, the confResponse, for a successful completion
"create" operation, contains a "response-code" of "success" and MUST of a "create" operation, contains a response-code of "success" and
contain the XCON-URI of the created conference in the "confObjID" MUST contain the XCON-URI of the newly created conference in the
parameter. In addition, the "confInfo" parameter transporting the "confObjID" parameter, in order to allow the conferencing client to
created conference document MAY be included. Obviously, the newly manipulate that conference through following CCMP requests. In
created object can be manipulated by the client through a subsequent addition, the "confInfo" parameter transporting the created
"update" operation. For example, after the creation and addition of conference document MAY be included, at the discretion of the
the participants, the creator may want to lock the conference object. conferencing system implementation, along with an optional version
This can be accomplished with a confRequest with an operation of parameter initialized at "1", since immediatly upon the creation the
"update" by setting the "locked" element in the confInfo included in conference object is at its first version.
the confRequest message described below.
In the case of a confRequest with a "retrieve" operation, the In the case of a confRequest with a "retrieve" operation, the
"confObjID" representing the XCON-URI of the target conference the "confObjID" representing the XCON-URI of the target conference MUST
conference control client MUST be included and the "confInfo" be included and the "confInfo" parameter MUST NOT be included in the
parameter SHOULD NOT be included in the request. The conferencing request. The conferencing server MUST ignore any "confInfo"
server MUST ignore any "confInfo" parameter that is received in a parameter that is received in a confRequest/retrieve. If the
"confRequest" and this "confInfo" parameter MUST NOT be included in confResponse for the "retrieve" operation contains a "response-code"
the confResponse. If the confResponse for the "retrieve" operation of "success", the "confInfo" parameter MUST be included in the
contains a "response-code" of "success", the "confInfo" parameter response. The "confInfo" parameter MUST contain the entire
MUST be included in the response. The "confInfo" parameter MUST conference document describing the target conference object in its
contain the entire conference document describing the target current state. The current state of the retrieved conference object
conference object in its current state. MUST also be reported in the proper "version" response parameter.
In case of a confRequest with an "update" operation, the "confInfo" In case of a confRequest with an "update" operation, the "confInfo"
and "confObjID" MUST be included in the request. The "confInfo" and "confObjID" MUST be included in the request. The "confInfo"
represents an object of type "conference-type" containing all the represents an object of type "conference-type" containing all the
changes to be applied to the conference whose identifier is changes to be applied to the conference whose identifier is
"confObjID". In the case of a confResponse with a "response-code" of "confObjID". Note that, in such a case, though the confInfo
"success", no additional information is required in the parameter has indeed to follow the rules indicated in the XCON data
"confResponse" message. A "response-code" of "success" indicates model, it does not represent the entire updated version of the target
that the referenced conference document has been changed by the conference, since it rather conveys just the modifications to apply
conference server. A "response-code" of "changeFailedProtected" to that conference. For example, in order to change the conference
indicates that the conferencing client is not allowed to make the title, the confInfo parameter will be of the form:
changes reflected in the "confInfo" in the initial request. This
might be due to policies, roles, specific privileges, etc.), with the <confInfo entity="xcon:8977777@example.com">
reason specific to a conferencing system and its configuration. <conference-description>
<display-text> *** NEW CONFERENCE TITLE *** </display-text>
</conference-description>
</confInfo>
Figure 7: Updating a conference object: modifying the title of a
conference
Similarly, to remove the title of an existing conference, a
confRequest/update carrying the following "confInfo" parameter would
do the job.:
<confInfo entity="xcon:8977777@example.com">
<conference-description>
<display-text/>
</conference-description>
</confInfo>
Figure 8: Updating a conference object: removing the title of a
conference
In the case of a confResponse/update with a response-code of
"success", no additional information is required in the response
message, which means the return of confInfo parameter is not
mandatory. A following confRequest/retrieve transaction might
provide the CCMP client with the current aspect of the conference
upon the modification, or the Notification Protocol might address
that task as well. A "success" response-code indicates that the
referenced conference document has been changed accordingly to the
request by the conferencing server. The "version" parameter MUST be
enclosed in the confResponse/update message, in order to let the
client understand what is the actual current conference-object
version, upon the applied modifications. An "updateFailed" response-
code indicates that the changes reflected in the request "confInfo"
are not feasible. This could be due to policies, requestor roles,
specific privileges, unacceptable values etc., with the reason
specific to a conferencing system and its configuration. Together
with the "updateFailed" response-code, the "version" parameter MUST
be attached in the confResponse/update, by this way allowing the
client to eventually retrieve the current version of the target
conference if the one she attempted to modify was not the most up-to-
date.
In the case of a confRequest with a "delete" operation, the In the case of a confRequest with a "delete" operation, the
"confObjID" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included and the "confInfo" SHOULD NOT be included in the request. be included while the "confInfo" MUST NOT be included in the request.
The conferencing server MUST ignore any "confInfo" parameter that is The conferencing server MUST ignore any "confInfo" parameter that is
received. The confResponse MUST contain the same "confObjID" that received within such a request. The confResponse MUST contain the
was included in the confRequest. The confResponse MUST contain a same "confObjID" that was included in the confRequest. If the
"response-code" of "success" if the targeted conference is confResponse/delete operation contains a "success" response-code, the
successfully deleted. If the confResponse for the "delete" operation conference indicated in the "confObjID" has been succesfully deleted.
contains a "response-code" of "success", the confResponse MUST NOT A "success" confResponse/delete MUST NOT contain the "confInfo"
contain the "confInfo" parameter. If the conferencing server cannot parameter. The "version" parameter SHOULD NOT be returned in any
delete the conference referenced by the "confObjID" received in the confResponse/delete. If the conferencing server cannot delete the
confRequest because it is the parent of another conference object conference referenced by the "confObjID" received in the confRequest
that is in use, the conferencing server MUST return a "response-code" because it is the parent of another conference object that is in use,
of "deleteParentFailed". the conferencing server MUST return a response-code of
"deleteParentFailed".
A confRequest with an "operation" of "retrieve", "update" or "delete"
carrying a "confObjID" which is not associated with one of the
conferences (active or registered) the system is holding will
generate, on the server's side, a confResponse message containing an
"objectNotFound" error code. This holds also for the case in which
the mentioned "confObjID" is related to an existing conference object
stored at the server, but associated with a blueprint or with a
sidebar rather than an actual conference.
The schema for the confRequest/confResponse pair is shown in The schema for the confRequest/confResponse pair is shown in
Figure 7. Figure 9.
<!-- 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>
<!-- confRequestType --> <!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" /> <xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType"> <xs:complexType name="confRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" <xs:element name="confInfo" type="info:conference-type"
type="info:conference-type" minOccurs="0"/> minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- 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>
<!-- confResponseType --> <!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType"> <xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type"/> <xs:element name="confInfo" type="info:conference-type"
</xs:sequence> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 7: Structure of the confRequest and confResponse messages Figure 9: Structure of the confRequest and confResponse messages
The following provides an example of the "confInfo" parameter
required to change the title of a conference:
<conf-info entity="123">
<conference-description>
<display-text>New conference title</display-text>
</conference-description>
</conf-info>
Figure 8: Updating a conference object: modifying the title of a
conference
Similarly, to remove the title of an existing conference, an "update"
operation carrying the following "confInfo" parameter would do the
job.
<conf-info entity="123">
<conference-description>
<display-text/>
</conference-description>
</conf-info>
Figure 9: Updating a conference object: removing the title of a
conference
6.3.5. usersRequest and usersResponse 6.3.5. usersRequest and usersResponse
Through a usersRequest message the CCMP client manipulates the Through a "usersRequest" message the CCMP client manipulates the XML
<users> element of the conference document associated with the <users> element of the conference document associated with the
conference identified by the "confObjID" parameter. Inside the conference identified by the "confObjID" parameter complusory
<users> element, along with the list of conference users, there is included in the request. Inside the <users> element, along with the
information that the client may be interested in controlling, such as list of <user> elements associated with conference participants,
the lists of users to which access to the conference is allowed/ there is information that the client may be interested in
denied, conference participation policies, etc.; for this reason, a controlling, such the list of the users to which access to the
customized message has been designed to allow for the manipulation of conference is allowed/denied, conference participation policies,
this specific part of a conference document. etc.; for this reason, a customized message has been designed to
allow for the manipulation of this specific part of a conference
document.
A "usersInfo" parameter MAY be included in a usersRequest message A "usersInfo" parameter MAY be included in a usersRequest message
depending upon the operation. If the "usersInfo" parameter is depending upon the operation. If the "usersInfo" parameter is
included in the usersRequest message, the parameter MUST be compliant included in the usersRequest message, the parameter MUST be compliant
with the <users> field of the XCON data model. with the <users> field of the XCON data model.
Two operations are allowed for a "usersRequest" message: Two operations are allowed for a "usersRequest" message:
1. "retrieve": In this case the request MUST NOT include a 1. "retrieve": In this case the request MUST NOT include a
"usersInfo" parameter, while a successful response MUST contain "usersInfo" parameter, while a successful response MUST contain
the desired <users> element in the "usersInfo" parameter. The the desired <users> element in the "usersInfo" parameter. The
conference server MUST be ignore a "usersInfo" parameter if it is conference server MUST ignore a "usersInfo" parameter if it is
received in a request with a "retrieve" operation. received in a request with a "retrieve" operation.
2. update: In this case, the "usersInfo" parameter MUST contain the 2. update: In this case, the "usersInfo" parameter MUST contain the
modifications to be applied to the referred <users> element. If modifications to be applied to the referred <users> element. If
the "response-code" is "success", then the "usersInfo" parameter the "response-code" is "success", then the "usersInfo" parameter
SHOULD NOT be returned. Any "usersInfo" parameter that is SHOULD NOT be returned. Any "usersInfo" parameter that is
returned SHOULD be ignored. A "response-code" of returned SHOULD be ignored. A "response-code" of
"changeFailedProtected" indicates that the conferencing client is "forbiddenChangeProtected" indicates that the conferencing client
not allowed to make the changes reflected in the "usersInfo" in is not allowed to make the changes reflected in the "usersInfo"
usersRequest message. This could be due to policies, roles, contained in the usersRequest message. This could be due to
specific privileges, etc.), with the reason specific to a policies, roles, specific privileges, etc., with the reason
conferencing system and its configuration. Thus, it is specific to a conferencing system and its configuration.
RECOMMENDED that the client continue using the previous version
of the "usersInfo".
Operations of "create" and "delete" are not applicable to a Operations of "create" and "delete" are not applicable to a
usersRequest message and MUST NOT be considered by the server, which usersRequest message and MUST NOT be considered by the server, which
means that a "response-code" of "forbidden" MUST be included in the means that a "response-code" of "forbidden" MUST be included in the
usersResponse message. usersResponse message.
<!-- usersRequest --> <!-- 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:extension> </xs:sequence>
</xs:complexContent> </xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType --> <!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" <xs:element name="usersInfo"
type="info:users-type" minOccurs="0" /> type="info:users-type" minOccurs="0" />
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- usersResponse --> <!-- 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>
<!-- usersResponseType --> <!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type"/> <xs:element name="usersInfo" type="info:users-type"
</xs:sequence> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 10: Structure of the usersRequest and usersResponse messages Figure 10: Structure of the usersRequest and usersResponse messages
6.3.6. userRequest and userResponse 6.3.6. userRequest and userResponse
A "userRequest" message is used to manipulate <user> elements inside A "userRequest" message is used to manipulate <user> elements inside
a conference document associated with a conference identified by the a conference document associated with a conference identified by the
"confObjID" parameter. Besides retrieving information about a "confObjID" parameter. Besides retrieving information about a
specific conference user, the message is used to request that the specific conference user, the message is used to request that the
skipping to change at page 34, line 8 skipping to change at page 33, line 8
included in the userRequest. The "userInfo" parameter MUST included in the userRequest. The "userInfo" parameter MUST
contain a <user> element and the "entity" attribute value MUST be contain a <user> element and the "entity" attribute value MUST be
set to the XCON-USERID of the third user in question. No set to the XCON-USERID of the third user in question. No
additional parameters beyond those previously described are additional parameters beyond those previously described are
required in the userResponse message, in the case of a "response- required in the userResponse message, in the case of a "response-
code" of "success". code" of "success".
o A conferencing client who has no XCON-USERID and who wants to o A conferencing client who has no XCON-USERID and who wants to
enter, via CCMP, a conference whose identifier is known. In such enter, via CCMP, a conference whose identifier is known. In such
case, a side-effect of the request is that the user is provided case, a side-effect of the request is that the user is provided
with an appropriate XCON-USERID. The involved messages with a new XCON-USERID (created by the server) carried inside the
(userRequest and userResponse) in such case should look like the "confUserID" parameter of the response. This is the only case in
following: which a CCMP request can be valid though carrying a void
"confUserID" parameter. A "userInfo" parameter MUST be enclosed
in the request, providing at least a contact URI of the joining
client, in order to let the focus instigate the signaling phase
needed to add her to the conference. The mandatory "entity"
attribute of the "userInfo" parameter in the request is filled
with a dummy value recognizable on the server side, so to conform
to the rules contained in the XCON data model XML schema. The
involved messages (userRequest and userResponse) in such case
should look like the following:
Request fields: Request fields:
confUserID=null; confUserID=null;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
userInfo= userInfo=
<userInfo entity=null> <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<endpoint entity="sip:GHIL345@blablabla"> <endpoint entity="sip:GHIL345@blablabla">
... ...
Response fields (in case of success): Response fields (in case of success):
confUserID=user345; confUserID=user345;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
response-code=success; response-code=success;
userInfo=null; //or the entire userInfo object userInfo=null; //or the entire userInfo object
Figure 11: userRequest and userResponse in the absence of an xcon- Figure 11: userRequest and userResponse in the absence of an xcon-
userid userid
o Conferencing client is unaware of the XCON-USERID of a third user: o Conferencing client is unaware of the XCON-USERID of a third user:
In this case, the "entity" attribute MUST NOT be included in the In this case, the XCON-USERID in the request "confUserID" is the
request. The XCON-USERID generated by the conference server for sender's one and the "entity" attribute of the attached userInfo
such a user MUST also be returned to the client as the value of is filled with the pre-defined fake value
the "entity" attribute in the "userInfo" parameter of the response "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the
if the "response-code" is "success". This scenario is mainly third user MUST be returned to the client issuing the request in
intended to support the case whereby a non-registered user is the "entity" attribute of the response "userInfo" parameter, if
added to a conference by a third party, e.g. the chairperson of the "response-code" is "success". [RP] This scenario is intended
the conference. to support both the case where a brand new conferencing system
user is added to a conference by a third party (i.e. a user who is
o Conferencing client obtains a new user profile in the context of a not yet provided with an XCON-USERID) and the case where the CCMP
conference: this case is handled in the same manner as the client issuing the request does not know the to-be-added user's
previous case associated with the creation of a user on behalf of XCON-USERID (which means such an identifier could already exist on
a third party when the XCON-USERID is unknown, thus indicating to the server's side for that user). In this last case, the
the conference server that the client wants a new XCON-USERID and conferencing server is in charge of avoiding XCON-URI duplicates
associated "userInfo" parameter to be allocated and populated for the same conferencing client, looking at key fields in the
respectively. request provided "userInfo" parameter, such as the signalling URI:
if the joining user is a brand new one, then the generation of a
new XCON identifier is needed; otherwise, if that user is an
existing one, the server must recover the corresponding XCON
identifier.
In the case of a userRequest with a "retrieve" operation, the In the case of a userRequest with a "retrieve" operation, the
"confObjID" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included. The "confUserID", containing the xcon-userid of the be included. The "confUserID", containing the CCMP client's xcon-
CCMP client, MUST also be included in the userRequest message. If userid, MUST also be included in the userRequest message. If the
the client wants to retrieve information about her profile in the client wants to retrieve information about her profile in the
specified conference, no "userInfo" parameter is needed in the specified conference, no "userInfo" parameter is needed in the
retrieve request. On the other hand, if the client wants to obtain retrieve request. On the other hand, if the client wants to obtain
someone else's information within the given conference, she MUST someone else's info within the given conference, she MUST include in
include in the userRequest/retrieve a "userInfo" parameter whose the userRequest/retrieve a "userInfo" parameter whose "entity"
"entity" attribute conveys the desired user's xcon-userid. If the attribute conveys the desired user's xcon-userid. If the
userResponse for the "retrieve" operation contains a "response-code" userResponse for the "retrieve" operation contains a "response-code"
of "success", the "userInfo" parameter MUST be included in the of "success", the "userInfo" parameter MUST be included in the
response. response.
In case of a userRequest with an "update" operation, the "confObjID", In case of a userRequest with an "update" operation, the "confObjID",
"confUserID" and "userInfo" MUST be included in the request. The "confUserID" and "userInfo" MUST be included in the request. The
"userInfo" is of type "user-type" and contains all the changes to be "userInfo" is of type "user-type" and contains all the changes to be
applied to a specific <user> element in the conference object applied to a specific <user> element in the conference object
identified by the "confObjID" in the userRequest message. The user identified by the "confObjID" in the userRequest message. The user
to be modified is identified through the "entity" attribute of the to be modified is identified through the "entity" attribute of the
"userInfo" parameter included in the request. In the case of a "userInfo" parameter included in the request. In the case of a
userResponse with a "response-code" of "success", no additional userResponse with a "response-code" of "success", no additional
information is required in the "userResponse" message. A "response- information is required in the "userResponse" message. A "response-
code" of "success" indicates that the referenced user element has code" of "success" indicates that the referenced user element has
been updated by the conference server. A "response-code" of been updated by the conference server. A "response-code" of
"changeFailedProtected" indicates that the conferencing client is not "forbiddenChangeProtected" indicates that the conferencing client is
allowed to make the changes reflected in the "userInfo" in the not allowed to make the changes reflected in the "userInfo" in the
initial request. This could be due to policies, roles, specific initial request. This could be due to policies, roles, specific
privileges, etc., with the reason specific to a conferencing system privileges, etc., with the reason specific to a conferencing system
and its configuration. Thus, it is RECOMMENDED that the client and its configuration.
continue using the previous version of the "userInfo".
In the case of a userRequest with a "delete" operation, the In the case of a userRequest with a "delete" operation, the
"confObjID" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included. The "confUserID", containing the CCMP client's xcon- be included. The "confUserID", containing the CCMP client's xcon-
userid, MUST also be included in the userRequest message. If the userid, MUST be included in the userRequest message. If the client
client wants to exit the specified conference, no "userInfo" wants to exit the specified conference, no "userInfo" parameter is
parameter is needed in the delete request. On the other hand, if the needed in the delete request. On the other hand, if the client wants
client wants to remove another participant from the given conference, to remove another participant from the given conference, she MUST
she MUST include in the userRequest/delete a "userInfo" parameter include in the userRequest/delete a "userInfo" parameter whose
whose "entity" attribute conveys the xcon-userid of that participant. "entity" attribute conveys the xcon-userid of that participant. The
The userResponse MUST contain the same "confObjID" that was included userResponse MUST contain the same "confObjID" that was included in
in the userRequest. The userResponse MUST contain a "response-code" the userRequest. The userResponse MUST contain a "response-code" of
of "success" if the target <user> element has been successfully "success" if the target <user> element has been successfully deleted.
deleted. If the userResponse for the "delete" operation contains a If the userResponse for the "delete" operation contains a "response-
"response-code" of "success", the userResponse MUST NOT contain the code" of "success", the userResponse MUST NOT contain the "userInfo"
"userInfo" parameter. parameter.
<!-- 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>
<!-- userRequestType --> <!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" /> <xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType"> <xs:complexType name="userRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" <xs:element name="userInfo"
type="info:user-type" minOccurs="0" /> type="info:user-type" minOccurs="0" />
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- userResponse --> <!-- 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>
<!-- userResponseType --> <!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type"/> <xs:element name="userInfo" type="info:user-type
</xs:sequence> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 12: Structure of the userRequest and userResponse messages Figure 12: Structure of the userRequest and userResponse messages
6.3.7. sidebarsByValRequest and sidebarsByValResponse 6.3.7. sidebarsByValRequest and sidebarsByValResponse
A "sidebarsByValRequest" is used to execute a retrieve-only operation A "sidebarsByValRequest" is used to execute a retrieve-only operation
on the <sidebars-by-val> field of the conference object represented on the <sidebars-by-val> field of the conference object represented
by the "confObjID". The "sidebarsByValRequest" message is of a by the "confObjID". The "sidebarsByValRequest" message is of a
"retrieve-only" type, so an "operation" parameter MUST NOT be "retrieve-only" type, so an "operation" parameter MUST NOT be
included in a "sidebarsByValRequest" message. A included in a "sidebarsByValRequest" message. As with blueprints and
conferences, also with sidebars, CCMP allows for the use of xpath
filters whenever a selected subset of the sidebars available at the
server's side has to be retrieved by the client. This applies both
to sidebars by reference and to sidebars by value. A
"sidebarsByValResponse" with a "response-code" of "success" MUST "sidebarsByValResponse" with a "response-code" of "success" MUST
contain a "sidebarsByValInfo" parameter containing the desired contain a "sidebarsByValInfo" parameter containing the desired
<sidebars-by-val> element. The "version" parameter contained in the <sidebars-by-val> element. A "sidebarsByValResponse" message MUST
response is related to the current version of the main conference carry back to the client a "version" element related to the current
referenced by the "confObjId" parameter of the request. The version of the main conference object (i.e. the one whose identifier
"sidebarsByValInfo" parameter contains the list of the conference is contained in the "confObjId" field of the request) to which the
objects associated with the sidebars by value derived from the main sidebars in question are associated. The "sidebarsByValInfo"
conference. The retrieved sidebars can then be updated or deleted parameter contains the list of the conference objects associated with
using the "sidebarByValRequest" message, which is described in the sidebars by value derived from the main conference. The
Section 6.3.8. retrieved sidebars can then be updated or deleted using the
"sidebarByValRequest" message, which is described in Section 6.3.8.
<!-- sidebarsByValRequest --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByVal-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="sidebarsByValRequest"/> <xs:element ref="sidebarsByValRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValRequestType --> <!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest" <xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" /> type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType"> <xs:complexType name="sidebarsByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
type="info:sidebars-by-val-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse --> <!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type"> <xs:complexType name="ccmp-sidebarsByVal-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="sidebarsByValResponse"/> <xs:element ref="sidebarsByValResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponseType --> <!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse" <xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" /> type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type"/> type="info:sidebars-by-val-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 13: Structure of the sidebarsByValRequest and Figure 13: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages sidebarsByValResponse messages
6.3.8. sidebarByValRequest and sidebarByValResponse 6.3.8. sidebarByValRequest and sidebarByValResponse
A sidebarByValRequest message MUST contain the "operation" parameter A sidebarByValRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of a "create" operation, the "confObjID" parameter MUST In the case of a "create" operation, the "confObjID" parameter MUST
be included in the sidebyValRequest message. In this case, the be included in the sidebyValRequest message. In this case, the
"confObjID" parameter contains the XCON-URI of the main conference in "confObjID" parameter contains the XCON-URI of the main conference in
which the sidebar is to be created. The "sidebarByValInfo" parameter which the sidebar has to be created. If no "sidebarByValInfo"
SHOULD NOT be included in the request, since, as envisaged in the parameter is included, as envisaged in the XCON framework
XCON framework ([RFC5239]), sidebars are always created by cloning ([RFC5239]), the sidebar is created by cloning the main conference,
the main conference. Any "sidebarByValInfo" included in the request following the implementation specific cloning rules. Otherwise,
MUST be ignored. The conference server sets the "active" element to similarly to the case of direct creation, the sidebar conference
"false" of the cloned conference to reflect that it is a "reserved" object is built on the basis of the "sidebarByValInfo" parameter
conference. The conference server MUST update the conference object provided by the requestor. As a consequence of a sidebar-by-val
reflected by the "confObjID" parameter, in the sidebarbyVal request creation, the conference server MUST update the main conference
message, from which the sidebar was created to reflect the newly object reflected by the "confObjID" parameter in the
created sidebar. The newly created conference object MAY be included sidebarbyValRequest/create message introducing the new sidebar object
in the response in the "sidebarByValInfo" parameter, if the as a new new <entry> in the proper section <sidebars-by-val>. The
"response-code" is "success". The URI of the conference object newly created sidebar conference object MAY be included in the
associated with the newly created sidebar object MUST appear in the sidebarByValResponse in the "sidebarByValInfo" parameter, if the
"confObjID" parameter of the response. The conference server can "response-code" is "success". The XCON-URI of the newly created
notify any conferencing clients that have subscribed to the sidebar MUST appear in the "confObjID" parameter of the response.
conference event package, and are authorized to receive the The conference server can notify any conferencing clients that have
notifications, of the addition of the sidebar to the conference. subscribed to the conference event package, and are authorized to
receive the notifications, of the addition of the sidebar to the
conference.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
(received in the response to a "create" operation or in a (received in the response to a "create" operation or in a
sidebarsByValResponse message) MUST be included in the "confObjID" sidebarsByValResponse message) MUST be included in the "confObjID"
parameter in the request. This "retrieve" operation is handled by parameter in the request. This "retrieve" operation is handled by
the conference server in the same manner as a "retrieve" operation the conference server in the same manner as a "retrieve" operation
included in a confRequest message as detailed in Section 6.3.4. included in a confRequest message as detailed in Section 6.3.4.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"update", the "sidebarByValInfo" MUST also be included in the "update", the "sidebarByValInfo" MUST also be included in the
request. The "confObjID" parameter contained in the request message request. The "confObjID" parameter contained in the request message
identifies the specific sidebar instance to be updated. An "update" identifies the specific sidebar instance to be updated. An "update"
operation on the "sidebarByValInfo" is handled by the conference operation on the "sidebarByValInfo" is handled by the conference
server in the same manner as an "update" operation on the confInfo server in the same manner as an "update" operation on the confInfo
included in a confRequest message, as detailed in Section 6.3.4. The included in a confRequest message as detailed in Section 6.3.4. A
"version" parameter contained in the response is related to the "sidebarByValResponse" message MUST carry back to the client a
current version of the conference object associated with the sidebar "version" element related to the current version of the sidebar whose
referenced by the "confObjId" parameter of the request. identifier is contained in the "confObjId" field of the request.
If an "operation" of "delete" is included in the sidebarByVal If an "operation" of "delete" is included in the sidebarByVal
request, the "sidebarByValInfo" parameter MUST NOT be included in the request, the "sidebarByValInfo" parameter MUST NOT be included in the
request. Any "sidebarByValInfo" included in the request MUST be request. Any "sidebarByValInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
associated with the sidebar MUST be included in the "confObjID" associated with the sidebar MUST be included in the "confObjID"
parameter in the request. If the specific conferencing user as parameter in the request. If the specific conferencing user as
reflected by the "confUserID" in the request is authorized to delete reflected by the "confUserID" in the request is authorized to delete
the conference, the conference server deletes the conference object the conference, the conference server deletes the conference object
reflected by the "confObjID" parameter and updates the data in the reflected by the "confObjID" parameter and updates the data in the
conference object from which the sidebar was cloned. The conference conference object from which the sidebar was cloned. The conference
server can notify any conferencing clients that have subscribed to server can notify any conferencing clients that have subscribed to
the conference event package, and are authorized to receive the the conference event package, and are authorized to receive the
notifications, of the deletion of the sidebar to the conference. notifications, of the deletion of the sidebar to the conference.
If a sidebarByValRequest with an "operation" of "retrieve", "update"
or "delete" carries a "confObjID" which is not associated with any
existing sidebar-by-val, a confResponse message containing an
"objectNotFound" error code will be generated on the server's side.
This holds also for the case in which the mentioned "confObjID" is
related to an existing conference object stored at the server, but
associated with a blueprint or with an actual conference or with a
sidebar-by-ref rather than a sidebar-by-val.
<!-- sidebarByValRequest --> <!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type"> <xs:complexType name="ccmp-sidebarByVal-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="sidebarByValRequest"/> <xs:element ref="sidebarByValRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequestType --> <!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest" <xs:element name="sidebarByValRequest"
type="sidebarByValRequestType" /> type="sidebarByValRequestType" />
<xs:complexType name="sidebarByValRequestType"> <xs:complexType name="sidebarByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponse --> <!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:complexType name="ccmp-sidebarByVal-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="sidebarByValResponse"/> <xs:element ref="sidebarByValResponse"/>
</xs:sequence> </xs:sequence>
skipping to change at page 42, line 49 skipping to change at page 40, line 39
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponseType --> <!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse" <xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" /> type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type"/> type="info:conference-type minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 14: Structure of the sidebarByValRequest and Figure 14: Structure of the sidebarByValRequest and
sidebarByValResponse messages sidebarByValResponse messages
6.3.9. sidebarsByRefRequest and sidebarsByRefResponse 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse
Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
invoked to retrieve the <sidebars-by-ref> element of the conference invoked to retrieve the <sidebars-by-ref> element of the conference
object identified by the "confObjID" parameter. The object identified by the "confObjID" parameter. The
"sidebarsByRefRequest" message is of a "retrieve-only" type, so an "sidebarsByRefRequest" message is of a "retrieve-only" type, so an
"operation" parameter MUST NOT be included in a "operation" parameter MUST NOT be included in a
skipping to change at page 43, line 22 skipping to change at page 41, line 20
"sidebarsByRefRequest" message is of a "retrieve-only" type, so an "sidebarsByRefRequest" message is of a "retrieve-only" type, so an
"operation" parameter MUST NOT be included in a "operation" parameter MUST NOT be included in a
"sidebarsByRefRequest" message. In the case of a "response-code" of "sidebarsByRefRequest" message. In the case of a "response-code" of
"success", the "sidebarsByRefInfo" parameter, containing the "success", the "sidebarsByRefInfo" parameter, containing the
<sidebars-by-ref> element of the conference object, MUST be included <sidebars-by-ref> element of the conference object, MUST be included
in the response. The <sidebars-by-ref> element represents the set of in the response. The <sidebars-by-ref> element represents the set of
URIs of the sidebars associated with the main conference, whose URIs of the sidebars associated with the main conference, whose
description (in the form of a standard XCON conference document) is description (in the form of a standard XCON conference document) is
external to the main conference itself. Through the retrieved URIs, external to the main conference itself. Through the retrieved URIs,
it is then possible to access single sidebars using the it is then possible to access single sidebars using the
"sidebarByRef" request message, described in Section 6.3.10. The "sidebarByRef" request message, described in Section 6.3.10. A
"version" parameter contained in the response is related to the "sidebarsByRefResponse" message MUST carry back to the client a
current version of the main conference referenced by the "confObjId" "version" element related to the current version of the main
parameter of the request. conference object (i.e. the one whose identifier is contained in the
"confObjId" field of the request) to which the sidebars in question
are associated.
<!-- sidebarsByRefRequest --> <!-- 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: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>
<xs:element name="sidebarsByRefRequest" <!-- sidebarsByRefRequestType -->
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType"> <xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
type="info:uris-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
<!-- sidebarsByRefResponse --> </xs:complexType>
<xs:complexType name="ccmp-sidebarsByref-response-message-type"> <!-- sidebarsByRefResponse -->
<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: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>
<xs:element name="sidebarsByRefResponse" <!-- sidebarsByRefResponseType -->
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType"> <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo"
type="info:uris-type"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 15: Structure of the sidebarsByRefRequest and Figure 15: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
6.3.10. sidebarByRefRequest and sidebarByRefResponse 6.3.10. sidebarByRefRequest and sidebarByRefResponse
A sidebarByRefRequest message MUST contain the "operation" parameter A sidebarByRefRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of an "operation of "create", the "confObjID" parameter In the case of a "create" operation, the "confObjID" parameter MUST
representing the XCON-URI of the conference from which the sidebar is be included in the sidebyRefRequest message. In this case, the
to be created (cloned) MUST be included in all sidebarByRefRequest "confObjID" parameter contains the XCON-URI of the main conference in
messages. The "sidebarByRefInfo" parameter SHOULD NOT be included in which the sidebar has to be created. If no "sidebarByRefInfo"
the request, since, as envisaged in the XCON framework ([RFC5239]), parameter is included, as envisaged in the XCON framework
sidebars are always created by cloning the main conference. Any ([RFC5239]), the sidebar is created by cloning the main conference,
"sidebarByRefInfo" included in the request MUST be ignored. If the following the implementation specific cloning rules. Otherwise,
creation of the sidebar is successful, the conference server MUST similarly to the case of direct creation, the sidebar conference
update the "sidebars-by-ref" element in the conference object from object is built on the basis of the "sidebarByRefInfo" parameter
which the sidebar was created (i.e., as identified by the "confObjID" provided by the requestor. If the creation of the sidebar is
in the original sidebarByRef request), with the URI for the newly successful, the conference server MUST update the "sidebars-by-ref"
created sidebar. The newly created conference object MAY be included element in the conference object from which the sidebar was created
in the response in the "sidebarByRefInfo" parameter with a "response- (i.e., as identified by the "confObjID" in the original sidebarByRef
code" "success". The URI for the conference object associated with request), with the URI of the newly created sidebar. The newly
the newly created sidebar object MUST appear in the "confObjID" created conference object MAY be included in the response in the
parameter of the response. The conference server can notify any "sidebarByRefInfo" parameter with a "response-code" of "success".
conferencing clients that have subscribed to the conference event The URI for the conference object associated with the newly created
package, and are authorized to receive the notifications, of the sidebar object MUST appear in the "confObjID" parameter of the
addition of the sidebar to the conference. response. The conference server can notify any conferencing clients
that have subscribed to the conference event package, and are
authorized to receive the notifications, of the addition of the
sidebar to the conference.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. A MUST be included in the "confObjID" parameter in the request. A
"retrieve" operation on the "sidebarByRefInfo" is handled by the "retrieve" operation on the "sidebarByRefInfo" is handled by the
conference server in the same manner as a "retrieve" operation on the conference server in the same manner as a "retrieve" operation on the
confInfo included in a confRequest message as detailed in confInfo included in a confRequest message as detailed in
Section 6.3.4. Section 6.3.4.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"update", the URI for the conference object created for the sidebar "update", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. The MUST be included in the "confObjID" parameter in the request. The
"sidebarByRefInfo" MUST also be included in the request in the case "sidebarByRefInfo" MUST also be included in the request in the case
of an "operation" of "update". An "update" operation on the of an "operation" of "update". An "update" operation on the
"sidebarByRefInfo" is handled by the conference server in the same "sidebarByRefInfo" is handled by the conference server in the same
manner as an "update" operation on the confInfo included in a manner as an "update" operation on the confInfo included in a
confRequest message as detailed in Section 6.3.4. The "version" confRequest message as detailed in Section 6.3.4. A
parameter contained in the response is related to the current version "sidebarByRefResponse" message MUST carry back to the client a
of the conference object associated with the sidebar referenced by "version" element related to the current version of the sidebar whose
the "confObjId" parameter of the request. identifier is contained in the "confObjId" field of the request.
If an "operation" of "delete" is included in the sidebarByRef If an "operation" of "delete" is included in the sidebarByRef
request, the "sidebarByRefInfo" parameter MUST NOT be included in the request, the "sidebarByRefInfo" parameter MUST NOT be included in the
request. Any "sidebarByRefInfo" included in the request MUST be request. Any "sidebarByRefInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
for the sidebar MUST be included in the "confObjID" parameter in the for the sidebar MUST be included in the "confObjID" parameter in the
request. If the specific conferencing user as reflected by the request. If the specific conferencing user as reflected by the
"confUserID" in the request is authorized to delete the conference, "confUserID" in the request is authorized to delete the conference,
the conference server SHOULD delete the conference object reflected the conference server SHOULD delete the conference object reflected
by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" by the "confObjID" parameter and SHOULD update the "sidebars-by-ref"
element in the conference object from which the sidebar was element in the conference object from which the sidebar was
originally cloned. The conference server can notify any conferencing originally cloned. The conference server can notify any conferencing
clients that have subscribed to the conference event package, and are clients that have subscribed to the conference event package, and are
authorized to receive the notifications, of the deletion of the authorized to receive the notifications, of the deletion of the
sidebar. sidebar.
If a sidebarByRefRequest with an "operation" of "retrieve", "update"
or "delete" carries a "confObjID" which is not associated with any
existing sidebar-by-ref, a confResponse message containing an
"objectNotFound" error code will be generated on the server's side.
This holds also for the case in which the mentioned "confObjID" is
related to an existing conference object stored at the server, but
associated with a blueprint or with an actual conference or with a
sidebar-by-val rather than a sidebar-by-ref.
<!-- sidebarByRefRequest --> <!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type"> <xs:complexType name="ccmp-sidebarByRef-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="sidebarByRefRequest"/> <xs:element ref="sidebarByRefRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefRequestType --> <!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest" <xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" /> type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType"> <xs:complexType name="sidebarByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponse --> <!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByref-response-message-type"> <xs:complexType name="ccmp-sidebarByRef-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="sidebarByRefResponse"/> <xs:element ref="sidebarByRefResponse"/>
</xs:sequence>
</xs:extension> </xs:sequence>
</xs:complexContent> </xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponseType --> <!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse" <xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" /> type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 16: Structure of the sidebarByRefRequest and Figure 16: Structure of the sidebarByRefRequest and
sidebarByRefResponse messages sidebarByRefResponse messages
6.4. CCMP Response Codes 6.4. CCMP Response Codes
All CCMP response messages MUST include a "response-code". The All CCMP response messages MUST include a ""response-code"". The
following summarizes the CCMP response codes: following summarizes the CCMP response codes:
success: Successful completion of the requested operation. success: Successful completion of the requested operation.
badRequest: Syntactically malformed request. badRequest: Syntactically malformed request.
objectNotFound: Target conference object missing at the server (it objectNotFound: Target conference object missing at the server (it
refers to the "confObjID" parameter in the generic request refers to the "confObjID" parameter in the generic request
message) message)
userNotFound: Target user missing at the server (it is related to userNotFound: Target user missing at the server (it is related to
the XCON-USERID in the "entity" attribute of the "userInfo" the XCON-USERID in the "entity" attribute of the "userInfo"
parameter when it is included in userRequests) parameter when it is included in userRequests)
invalidConfUserID: User missing at the server (this code is returned invalidConfUserID: User missing at the server (this code is returned
in the case of requests in which the "confUserID" of the sender is in the case of requests in which the "confUserID" of the sender is
invalid). invalid).
invalidPassword: Target conference object's password contained in invalidConfPassword: Target conference object's password contained
the request is wrong. in the request is wrong.
passwordRequired: Conference password missing in a request to access confPasswordRequired: "conference-password" missing in a request to
a password-protected conference object. access a password-protected conference object.
unauthorized: User not allowed to perform the required operation. unauthorized: User not allowed to perform the required operation.
authenticationRequired: User's authentication information missing in
a request to perform the requested operation. "subject" parameter
needed in the request.
forbidden: Operation not allowed (e.g., cancellation of a forbidden: Operation not allowed (e.g., cancellation of a
blueprint). blueprint).
forbiddenDeleteParent: Cancel operation failed since the target forbiddenDeleteParent: Cancel operation failed since the target
object is a parent of child objects which depend on it, or because object is a parent of child objects which depend on it, or because
it effects, based on the "parent-enforceable" mechanism, the it effects, based on the "parent-enforceable" mechanism, the
corresponding element in a child object. corresponding element in a child object.
forbiddenChangeProtected: Update refused by the server because the forbiddenChangeProtected: Update refused by the server because the
target element cannot be modified due to its implicit dependence target element cannot be modified due to its implicit dependence
skipping to change at page 49, line 11 skipping to change at page 46, line 38
requestTimeout: The time required to serve the request has exceeded requestTimeout: The time required to serve the request has exceeded
the envisaged service threshold. the envisaged service threshold.
serverInternalError: The server cannot complete the required service serverInternalError: The server cannot complete the required service
due to a system internal error. due to a system internal error.
notImplemented: Operation envisaged in the protocol, but not notImplemented: Operation envisaged in the protocol, but not
implemented in the contacted server. implemented in the contacted server.
updateFailed: A generic error in the case that a requested "update" updateFailed A generic error associated with all those situations in
cannot be successfully completed by the server. An example is which a requested "update" cannot be successfully completed by the
when the modification of an object cannot be applied due to server. An example of such situation is when the modification of
conflicts arising at the server's side (e.g. because the client an object cannot be applied due to conflicts arising at the
version of the object is an obsolete one and the requested server's side (e.g. because the client version of the object is an
modifications collide with the up-to-date state of the object obsolete one and the requested modifications collide with the up-
stored at the server). to-date state of the object stored at the server).
The handling of a "response-code" of "objectNotFound", The handling of a "response-code" of "objectNotFound",
"userNotFound", "deleteParentFailed" and "changeFailedProtected" are "userNotFound", "deleteParentFailed" and "forbiddenChangeProtected"
only applicable to specific operations for specialized message are only applicable to specific operations for specialized message
responses and the details are provided in Section 6.3. The following responses and the details are provided in Section 6.3. The following
table summarizes these response codes and the specialized message and table summarizes these response codes and the specialized message and
operation to which they are applicable: operation to which they are applicable:
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Response code | Create | Retrieve | Update | Delete | | Response code | Create | Retrieve | Update | Delete |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| updateFailed | N/A | N/A | All update | N/A | | updateFailed | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| | | | | | | | | | | |
skipping to change at page 60, line 4 skipping to change at page 57, line 4
7.4. Alice updates conference information 7.4. Alice updates conference information
This section illustrates the fourth transaction in the overall flow. This section illustrates the fourth transaction in the overall flow.
Alice decides to modify some of the details associated with the Alice decides to modify some of the details associated with the
conference she just created. More precisely, she changes the conference she just created. More precisely, she changes the
<display-text> element under the <conference-description> element of <display-text> element under the <conference-description> element of
the document representing the conference. This is achieved through a the document representing the conference. This is achieved through a
"confRequest/update" message carrying the fragment of the conference "confRequest/update" message carrying the fragment of the conference
document to which the required changes have to be applied. As shown document to which the required changes have to be applied. As shown
in the picture, the response contains a code of "success", which in the picture, the response contains a code of "success", which
acknowledges the modifications requested by the client, at the same acknowledges the modifications requested by the client, while also
time updating the conference version number from 1 to 2, as reflected updating the conference version number from 1 to 2, as reflected in
in the "version" parameter. the "version" parameter.
Alice updates information about the conference she just created: Alice updates information about the conference she just created:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP confRequest message | | CCMP confRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - confInfo: confUpdates | | - confInfo: confUpdates |
skipping to change at page 65, line 19 skipping to change at page 62, line 19
<ccmp:version>4</ccmp:version> <ccmp:version>4</ccmp:version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Alice joins the conference through the CCMP Figure 22: Alice joins the conference through the CCMP
7.7. Alice adds a new user to the conference 7.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new user to the overall flow. Alice uses the CCMP to add a new conferencing system
conference. This is achieved through a "userRequest/create" message user, Ciccio, to the conference. This "third-party" request is
containing, in the "userInfo" parameter, a <user> element compliant realized through a "userRequest/create" message containing, in the
with the XCON data model representation. Notice that such element "userInfo" parameter, a <user> element compliant with the XCON data
includes information about the user's Address of Records, as well as model representation. Notice that such element includes information
his current end-point. The picture below shows the transaction. about Ciccio's Address of Records, as well as his current end-point,
Notice how the "confUserID" parameter in the request is Alice's id, but has a fake "entity" attribute, since it is unknown to Alice, in
whereas the <userInfo> element has no "entity" attribute and contains this example. Thus, the server is in charge of generating a new
information about a different user, thus indicating that the request XCON-USERID for the user Alice indicates, and returning it in the
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
"confUserID" parameter representing the conference user id of the
user just added to the conference with Alice's third-party request.
This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new user, Ciccio, to the
conference. This "third-party" request is realized 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 Ciccio's Address
of Records, as well as his current end-point, but has no "entity"
attribute, since such information is unknown to Alice, in this
example. Thus, the server is in charge of: (i) generating a new
xcon-userid for the user indicated by Alice; (ii) returning it in the
"entity" attribute of the "userInfo" parameter carried in the "entity" attribute of the "userInfo" parameter carried in the
response; (iii) adding the user to the conference. The picture below response, as well as adding the user to the conference. The picture
shows the transaction. below shows the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server: "userRequest/create" message to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: CiccioUserInfo(without "entity") | | - userInfo: CiccioUserInfo(with dummy "entity") |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: Ciccio | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - response-code: success | | - response-code: success |
| - version: 5 | | - version: 5 |
| - userInfo: CiccioUserInfo | | - userInfo: CiccioUserInfo |
| (with "entity") | | (with actual "entity") |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 1. "third party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo> <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Ciccio@example.com mailto:Ciccio@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/> <info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo> </userInfo>
skipping to change at page 67, line 17 skipping to change at page 64, line 4
2. "third party" userResponse message form the server: 2. "third party" userResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:version>5</ccmp:version> <ccmp:version>5</ccmp:version>
<ccmp:userResponse> <ccmp:userResponse>
<userInfo entity="xcon-userid:Ciccio@example.com"/> <userInfo entity="xcon-userid:Ciccio@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userResponse> </ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 23: Alice adds a new user to the conference through the CCMP Figure 23: Alice adds a new user to the conference through the CCMP
8. Locating a Conference Control Server 8. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
skipping to change at page 71, line 13 skipping to change at page 68, line 13
specification will document this solution. specification will document this solution.
10. HTTP Transport 10. HTTP Transport
This section describes the use of HTTP [RFC2616] and HTTP Over TLS This section describes the use of HTTP [RFC2616] and HTTP Over TLS
[RFC2818] as transport mechanisms for the CCMP protocol, which a [RFC2818] as transport mechanisms for the CCMP protocol, which a
conforming conference Server and Conferencing client MUST support. conforming conference Server and Conferencing client MUST support.
Although CCMP uses HTTP as a transport, it uses a strict subset of Although CCMP uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a HTTP features, and due to the restrictions of some features, a
conferencing server may not a fully compliant HTTP server. It is conferencing server may not be a fully compliant HTTP server. It is
intended that a conference server can easily be built using an HTTP intended that a conference server can easily be built using an HTTP
server with extensibility mechanisms, and that a conferencing client server with extensibility mechanisms, and that a conferencing client
can trivially use existing HTTP libraries. This subset of can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options requirements helps implementors avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
A conferencing client that conforms to this specification is not A conferencing client that conforms to this specification is not
required to support HTTP authentication [RFC2617] or cookies required to support HTTP authentication [RFC2617] or cookies
[RFC2965]. These mechanism are unnecessary because CCMP requests [RFC2965]. These mechanism are unnecessary because CCMP requests
carry their own authentication information (in the "confUserID" and carry their own authentication information (in the "subject" field;
"password" fields; see Section 6.1). see Section 6.1).
A CCMP request is carried in the body of an HTTP POST request. The A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request. conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/ The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields. provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content- If the conference server does not receive the appropriate Content-
Type and Accept header fields, the conference server SHOULD fail the Type and Accept header fields, the conference server SHOULD fail the
request, returning a 406 (not acceptable) response. CCMP responses request, returning a 406 (not acceptable) response. CCMP responses
skipping to change at page 76, line 10 skipping to change at page 73, line 10
userRequest message with an "update" or "create" operation, to ensure userRequest message with an "update" or "create" operation, to ensure
the user is provided the appropriate level of privacy. If the the user is provided the appropriate level of privacy. If the
"provide-anonymity" element is not included in the conference object, "provide-anonymity" element is not included in the conference object,
then other users can see the participant's identity. then other users can see the participant's identity.
12. XML Schema 12. XML Schema
This section provides the XML schema definition of the "application/ This section provides the XML schema definition of the "application/
ccmp+xml" format. ccmp+xml" format.
<?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: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:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
namespace="urn:ietf:params:xml:ns:xcon-conference-info" schemaLocation="DataModel.xsd"/>
schemaLocation="DataModel.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
<xs:import schemaLocation="rfc4575.xsd"/>
namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" 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: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:complexType> </xs:complexType>
<!-- Definition of ccmp-request-message-type -->
<xs:complexType abstract="true" <!-- Definition of ccmp-request-message-type -->
name="ccmp-request-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 name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:anyAttribute namespace="##any" processContents="lax"/>
</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:sequence> <xs:sequence>
<xs:element ref="blueprintsRequest" /> <xs:element ref="blueprintsRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintsRequestType --> <!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
type="blueprintsRequestType" />
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- blueprintRequest --> <xs:complexType name="blueprintsRequestType">
<xs:complexType name="ccmp-blueprint-request-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<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="blueprintRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- blueprintRequestType -->
<xs:element name="blueprintRequest" <xs:element name="blueprintRequest" type="blueprintRequestType" />
type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsRequest --> <!-- 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:sequence> <xs:sequence>
<xs:element ref="confsRequest" /> <xs:element ref="confsRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsRequestType --> <!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" /> <xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType"> <xs:complexType name="confsRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="xpathFilter" <xs:element name="xpathFilter" type="xs:string"
type="xs:string" minOccurs="0"/> minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</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>
<!-- confRequestType --> <!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType"> <xs:element name="confRequest" type="confRequestType" />
<xs:sequence>
<xs:element name="confInfo"
type="info:conference-type"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- usersRequest --> <xs:complexType name="confRequestType">
<xs:complexType name="ccmp-users-request-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="confInfo" type="info:conference-type"
<xs:extension base="tns:ccmp-request-message-type"> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<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 --> <!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" <xs:element name="usersInfo" type="info:users-type"
type="info:users-type" minOccurs="0" />
minOccurs="0" /> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
<!-- userRequest --> </xs:complexType>
<xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <!-- userRequest -->
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<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>
<!-- userRequestType --> <!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" /> <xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo"
type="info:user-type" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<!-- sidebarsByValRequest --> <xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <!-- sidebarsByValRequest -->
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType> <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>
<!-- sidebarsByRefRequest --> <!-- sidebarsByValRequestType -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequest --> <xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="ccmp-sidebarByVal-request-message-type"> <xs:complexType name="sidebarsByValRequestType">
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:ccmp-request-message-type"> <xs:element name="xpathFilter"
<xs:sequence> type="xs:string" minOccurs="0"/>
<xs:element ref="sidebarByValRequest" /> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
</xs:extension> </xs:sequence>
</xs:complexContent> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequestType --> <!-- sidebarsByRefRequest -->
<xs:element name="sidebarByValRequest" <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
type="sidebarByValRequestType" /> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="sidebarByValRequestType"> <!-- sidebarsByRefRequestType -->
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType> <xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<!-- sidebarByRefRequest --> <xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ccmp-sidebarByRef-request-message-type"> <!-- sidebarByValRequest -->
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefRequest" /> <xs:element ref="sidebarByValRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefRequestType --> <!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:element name="sidebarByRefRequest" <xs:complexType name="sidebarByValRequestType">
type="sidebarByRefRequestType" /> <xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="sidebarByRefRequestType"> <!-- sidebarByRefRequest -->
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- Definition of ccmp-response-message-type --> <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>
<xs:complexType abstract="true" <!-- sidebarByRefRequestType -->
name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" minOccurs="0"
maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1"
maxOccurs="1" />
<xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<!-- blueprintsResponse --> <xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="sidebarByRefRequestType">
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:ccmp-response-message-type"> <xs:element name="sidebarByRefInfo"
<xs:sequence> type="info:conference-type" minOccurs="0"/>
<xs:element ref="blueprintsResponse" /> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
</xs:extension> </xs:sequence>
</xs:complexContent> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponseType --> <!-- Definition of ccmp-response-message-type -->
<xs:element name="blueprintsResponse" <xs:complexType abstract="true" name="ccmp-response-message-type">
type="blueprintsResponseType" /> <xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:complexType name="blueprintsResponseType"> <xs:element name="operation" minOccurs="0"
<xs:sequence> maxOccurs="1" />
<xs:element name="blueprintsInfo" <xs:element ref="response-code" minOccurs="1"
type="info:uris-type" minOccurs="0"/> maxOccurs="1" />
</xs:sequence> <xs:element name="response-string" type="xs:string"
</xs:complexType> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse --> <!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:extension base="tns:ccmp-response-message-type"> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintResponseType --> <!-- blueprintsResponseType -->
<xs:element name="blueprintResponse" <xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
type="blueprintResponseType" />
<xs:complexType name="blueprintResponseType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintsInfo" type="info:uris-type"
type="info:conference-type"/> minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse --> <!-- blueprintResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexType name="ccmp-blueprint-response-message-type">
<xs:extension base="tns:ccmp-response-message-type"> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsResponse" /> <xs:element ref="blueprintResponse" />
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType --> </xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="confsResponse" type="confsResponseType" /> <!-- blueprintResponseType -->
<xs:complexType name="confsResponseType"> <xs:element name="blueprintResponse" type="blueprintResponseType"/>
<xs:sequence>
<xs:element name="confsInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- confResponse --> <xs:complexType name="blueprintResponseType">
<xs:complexType name="ccmp-conf-response-message-type"> <xs:sequence>
<xs:complexContent> <xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<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="confsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponseType --> <!-- confsResponseType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confResponseType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type"/> <xs:element name="confsInfo" type="info:uris-type"
</xs:sequence> minOccurs="0"/>
</xs:complexType> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse --> <!-- confResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent> <xs:complexType name="ccmp-conf-response-message-type">
<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="confResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersResponseType --> <!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type"/> <xs:element name="usersInfo" type="info:users-type"
</xs:sequence> minOccurs="0"/>
</xs:complexType> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userResponse -->
<!-- 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>
<!-- userResponseType --> <!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type"/> <xs:element name="userInfo" type="info:user-type"
</xs:sequence> minOccurs="0"/>
</xs:complexType> <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse --> <!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type"> <xs:complexType name="ccmp-sidebarsByVal-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="sidebarsByValResponse" /> <xs:element ref="sidebarsByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse" <!-- sidebarsByValResponseType -->
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType"> <xs:element name="sidebarsByValResponse"
<xs:sequence> type="sidebarsByValResponseType" />
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarsByRefResponse --> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ccmp-sidebarsByref-response-message-type"> <!-- sidebarsByRefResponse -->
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:complexType name="ccmp-sidebarsByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefResponse" /> <xs:element ref="sidebarsByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefResponseType --> <!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse" <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" /> type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType"> <xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo" type="info:uris-type"
type="info:uris-type"/> minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValResponse --> <!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:complexType name="ccmp-sidebarByVal-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="sidebarByValResponse" /> <xs:element ref="sidebarByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse" <!-- sidebarByValResponseType -->
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType"> <xs:element name="sidebarByValResponse"
<xs:sequence> type="sidebarByValResponseType" />
<xs:element name="sidebarByValInfo"
type="info:conference-type"/>
</xs:sequence>
</xs:complexType>
<!-- sidebarByRefResponse --> <xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ccmp-sidebarByref-response-message-type"> <!-- sidebarByRefResponse -->
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:complexType name="ccmp-sidebarByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefResponse" /> <xs:element ref="sidebarByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponseType --> <!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse" <xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" /> type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type"/> type="info:conference-type" minOccurs="0"/>
</xs:sequence> <xs:any namespace="##other" processContents="lax"
</xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- response-code --> <!-- response-code -->
<xs:element name="response-code" type="response-codeType" /> <xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType"> <xs:simpleType name="response-codeType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="success"/> <xs:enumeration value="success"/>
<xs:enumeration value="updateFailed"/> <xs:enumeration value="updateFailed"/>
<xs:enumeration value="badRequest"/> <xs:enumeration value="authorizationRequired"/>
<xs:enumeration value="unauthorized"/> <xs:enumeration value="badRequest"/>
<xs:enumeration value="forbidden"/> <xs:enumeration value="unauthorized"/>
<xs:enumeration value="objectNotFound"/> <xs:enumeration value="forbidden"/>
<xs:enumeration value="userNotFound"/> <xs:enumeration value="objectNotFound"/>
<xs:enumeration value="invalidConfUserID"/> <xs:enumeration value="userNotFound"/>
<xs:enumeration value="passwordRequired"/> <xs:enumeration value="invalidConfUserID"/>
<xs:enumeration value="invalidPassword"/> <xs:enumeration value="confPasswordRequired"/>
<xs:enumeration value="forbiddenDeleteParent"/> <xs:enumeration value="invalidConfPassword"/>
<xs:enumeration value="forbiddenChangeProtected"/> <xs:enumeration value="forbiddenDeleteParent"/>
<xs:enumeration value="requestTimeout"/> <xs:enumeration value="forbiddenChangeProtected"/>
<xs:enumeration value="serverInternalError"/> <xs:enumeration value="requestTimeout"/>
<xs:enumeration value="notImplemented"/> <xs:enumeration value="serverInternalError"/>
</xs:restriction> <xs:enumeration value="notImplemented"/>
</xs:simpleType> <xs:enumeration value="authenticationRequired"/>
</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="update"/> <xs:enumeration value="update"/>
<xs:enumeration value="delete"/> <xs:enumeration value="delete"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema>
<!-- subject-type -->
<xs:complexType name="subject-type">
<xs:sequence>
<xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
Figure 25 Figure 25
13. IANA Considerations 13. 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.
skipping to change at page 93, line 9 skipping to change at page 92, line 9
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 5.1: codes as described above in Section 5.1:
success: This code indicates that the request was successfully success: This code indicates that the request was successfully
processed. processed.
updateFailed: This code indicates that a requested "update" cannot updateFailed: This code indicates that a requested "update" cannot
be successfully completed by the server. An example is when the be successfully completed by the server. An example of such
modification of an object cannot be applied due to conflicts situation is when the modification of an object cannot be applied
arising at the server's side (e.g. because the client version of due to conflicts arising at the server's side (e.g. because the
the object is an obsolete one and the requested modifications client version of the object is an obsolete one and the requested
collide with the up-to-date state of the object stored at the modifications collide with the up-to-date state of the object
server). stored at the server).
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.
skipping to change at page 93, line 36 skipping to change at page 92, line 36
object was not found. object was not found.
userNotFound: This code is returned in answer to a "userRequest/ userNotFound: This code is returned in answer to a "userRequest/
create" operation, in the case of a third-party invite, when the create" operation, in the case of a third-party invite, when the
"confUserID" (contained in the "entity" attribute of the "confUserID" (contained in the "entity" attribute of the
"userInfo" parameter) of the user to be added is unknown. "userInfo" parameter) of the user to be added is unknown.
invalidConfUserID: This code is returned in the case of requests in invalidConfUserID: This code is returned in the case of requests in
which the "confUserID" of the sender is invalid. which the "confUserID" of the sender is invalid.
invalidPassword: This code is returned in response to all requests invalidConfPassword: This code is returned in response to all
wishing to access/manipulate a password-protected conference requests wishing to access/manipulate a password-protected
object, when the "password" parameter contained in the request is conference object, when the "conference-password" parameter
wrong. contained in the request is wrong.
passwordRequired: This code is returned in response to all requests confPasswordRequired: This code is returned in response to all
wishing to access/manipulate a password-protected conference requests wishing to access/manipulate a password-protected
object, when the "password" parameter is missing in the request. conference object, when the "conference-password" parameter is
missing in the request.
authenticationRequired: This code is returned in response whenever
the server wants to authenticate the requestor through the
"subject" parameter and such a parameter is not provided in the
request.
forbiddenDeleteParent: This code indicates that the conferencing forbiddenDeleteParent: This code indicates that the conferencing
system cannot delete the specific conference object because it is system cannot delete the specific conference object because it is
a parent for another conference object. a parent for another conference object.
forbiddenChangeProtected: This code indicates that the target forbiddenChangeProtected: 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
skipping to change at page 95, line 9 skipping to change at page 94, line 9
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.
14. 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, Tobia Castaldi, Theo Zourzouvillys, Sean Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean
Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen and Yu Guo. Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special
Special thanks go to Roberta Presta for her invaluable contribution thanks go to Roberta Presta for her invaluable contribution to this
to this document. Roberta has worked on the specification of the document. Roberta has worked on the specification of the CCMP
CCMP protocol at the University of Napoli for the preparation of her protocol at the University of Napoli for the preparation of her
Master thesis. She has also implemented the CCMP prototype used for Master thesis. She has also implemented the CCMP prototype used for
the trials and from which the dumps provided in Section 7 have been the trials and from which the dumps provided in Section 7 have been
extracted. extracted.
15. 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 04 and the 05:
1. Added versioning.
2. Added string to response codes.
3. Removed "modified" response code.
4. Added filtering for conference info in responses.
5. Editorial clarifications and nits.
The following summarizes the changes between the WG 03 and the 04: The following summarizes the changes between the WG 03 and the 04:
1. Re-organized document based on feedback from Richard Barnes. 1. Re-organized document based on feedback from Richard Barnes.
2. Editorial clarifications and nits, including those identified by 2. Editorial clarifications and nits, including those identified by
Richard and Simo Veikkolainen. Richard and Simo Veikkolainen.
The following summarizes the changes between the WG 02 and the 03: The following summarizes the changes between the WG 02 and the 03:
1. Clarified that the confUserID is optional in the generic CCMP 1. Clarified that the confUserID is optional in the generic CCMP
skipping to change at page 98, line 38 skipping to change at page 97, line 38
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-14 Conferencing (XCON)", draft-ietf-xcon-common-data-model-16
(work in progress), November 2009. (work in progress), February 2010.
16.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,
June 2002. June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-examples]
Barnes, M., Boulton, C., Miniero, L., Presta, R., and S.
Romano, "Centralized Conferencing Manipulation Protocol
(CCMP) Call Flow Examples", draft-ietf-xcon-examples-02
(work in progress), December 2009.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Hadley, M., Gudgin, M., Nielsen, H., Moreau, J., and N. Gudgin, M., Mendelsohn, N., Hadley, M., Moreau, J., and H.
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework",
Framework", World Wide Web Consortium FirstEdition REC- World Wide Web Consortium FirstEdition REC-soap12-part1-
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]
Mendelsohn, N., Nielsen, H., Moreau, J., Hadley, M., and Mendelsohn, N., Hadley, M., Gudgin, M., Moreau, J., and H.
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "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>.
[W3C.REC-xpath-19991116]
DeRose, S. and J. Clark, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
In both approaches, servers will have to recreate their internal In both approaches, servers will have to recreate their internal
state representation of the object with each update request, checking state representation of the object with each update request, checking
 End of changes. 334 change blocks. 
1283 lines changed or deleted 1615 lines changed or added

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