draft-ietf-xcon-ccmp-06.txt   draft-ietf-xcon-ccmp-07.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: August 21, 2010 NS-Technologies Expires: October 28, 2010 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
February 17, 2010 April 26, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-06 draft-ietf-xcon-ccmp-07
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) allows a The Centralized Conferencing Manipulation Protocol (CCMP) allows an
XCON conferencing system client to create, retrieve, change and XCON conferencing system client to create, retrieve, change, and
delete objects describing a centralized conference, being a mean to delete objects that describe a centralized conference. CCMP is a
control basic and advanced conference features such as conference means to control basic and advanced conference features such as
state and capabilities, participants and relative roles and details. conference state and capabilities, participants, relative roles, and
The CCMP is a state-less, XML-based, client server protocol carrying details. CCMP is a state-less, XML-based, client server protocol
in its request and response messages conference information in the that carries, in its request and response messages, conference
form of XML documents and fragments conforming to the centralized information in the form of XML documents and fragments conforming to
conferencing data model schema. the centralized conferencing data model schema.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 28, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. XCON Conference Control System Architecture . . . . . . . . . 5
4. XCON Conference Control System Architecture . . . . . . . . . 7 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . . 7
4.1. Conference Objects . . . . . . . . . . . . . . . . . . . 8 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . . 7
4.2. Conference Users . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10 4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11
5.2. Implementation Approach . . . . . . . . . . . . . . . . . 13 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12
6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12
6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 14 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . . 14
6.2. CCMP Response Message Type . . . . . . . . . . . . . . . 16 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16
6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . . 18
6.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20 5.3.2. confsRequest and confsResponse . . . . . . . . . . . . 20
6.3.2. confsRequest and confsResponse . . . . . . . . . . . 22 5.3.3. blueprintRequest and blueprintResponse . . . . . . . . 22
6.3.3. blueprintRequest and blueprintResponse . . . . . . . 23 5.3.4. confRequest and confResponse . . . . . . . . . . . . . 24
6.3.4. confRequest and confResponse . . . . . . . . . . . . 25 5.3.5. usersRequest and usersResponse . . . . . . . . . . . . 28
6.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 5.3.6. userRequest and userResponse . . . . . . . . . . . . . 30
6.3.6. userRequest and userResponse . . . . . . . . . . . . 32 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . . 34
6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . . 36
6.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . . 39
6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 41 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . . 40
6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 43
6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 45 6. A complete example of the CCMP in action . . . . . . . . . . . 46
7. A complete example of the CCMP in action . . . . . . . . . . 49 6.1. Alice retrieves the available blueprints . . . . . . . . . 47
7.1. Alice retrieves the available blueprints . . . . . . . . 49 6.2. Alice gets detailed information about a specific
7.2. Alice gets detailed information about a specific blueprint . . . . . . . . . . . . . . . . . . . . . . . . 49
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Alice creates a new conference through a cloning
7.3. Alice creates a new conference through a cloning operation . . . . . . . . . . . . . . . . . . . . . . . . 51
operation . . . . . . . . . . . . . . . . . . . . . . . . 54 6.4. Alice updates conference information . . . . . . . . . . . 54
6.5. Alice inserts a list of users in the conference object . . 56
7.4. Alice updates conference information . . . . . . . . . . 56 6.6. Alice joins the conference . . . . . . . . . . . . . . . . 57
7.5. Alice inserts a list of users in the conference object . 58 6.7. Alice adds a new user to the conference . . . . . . . . . 59
7.6. Alice joins the conference . . . . . . . . . . . . . . . 60 7. Locating a Conference Control Server . . . . . . . . . . . . . 61
7.7. Alice adds a new user to the conference . . . . . . . . . 62 8. Managing Notifications . . . . . . . . . . . . . . . . . . . . 63
8. Locating a Conference Control Server . . . . . . . . . . . . 65 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 63
9. Managing Notifications . . . . . . . . . . . . . . . . . . . 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 68 10.1. Assuring that the Proper Conferencing Server has been
11. Security Considerations . . . . . . . . . . . . . . . . . . . 70 contacted . . . . . . . . . . . . . . . . . . . . . . . . 66
11.1. Assuring that the Proper Conferencing Server has been 10.2. User Authentication and Authorization . . . . . . . . . . 66
contacted . . . . . . . . . . . . . . . . . . . . . . . . 71 10.3. Security and Privacy of Identity . . . . . . . . . . . . . 67
11.2. User Authentication and Authorization . . . . . . . . . . 71 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68
11.3. Security and Privacy of Identity . . . . . . . . . . . . 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 73 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 82
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 83
13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 87 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 83
13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 87 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 84
13.3. MIME Media Type Registration for 'application/ccmp+xml' . 88 12.4.1. Registration of a Conference Control Server
13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 89 Application Service Tag . . . . . . . . . . . . . . . 84
13.4.1. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 89 Application Protocol Tag for CCMP . . . . . . . . . . 84
13.4.2. Registration of a Conference Control Server 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 85
Application Protocol Tag for CCMP . . . . . . . . . . 89 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 85
13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 90 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 86
13.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 90 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87
13.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 91 14. Changes since last Version . . . . . . . . . . . . . . . . . . 87
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
15. Changes since last Version . . . . . . . . . . . . . . . . . 95 15.1. Normative References . . . . . . . . . . . . . . . . . . . 89
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 15.2. Informative References . . . . . . . . . . . . . . . . . . 90
16.1. Normative References . . . . . . . . . . . . . . . . . . 97
16.2. Informative References . . . . . . . . . . . . . . . . . 97
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . 99 considered for CCMP . . . . . . . . . . . . . . . . . 91
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 99 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 91
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 100 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON Framework introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing the current
state and capabilities of a conference. state and capabilities of a conference.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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 Conference Control Client and Conference Control Framework, with the Conference Control Client and Conference Control
Server 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 requests and responses, which [RFC2616] as the protocol to transfer requests and responses, which
contain the domain-specific XML-encoded data objects defined in contain the domain-specific XML-encoded data objects defined in
[I-D.ietf-xcon-common-data-model] Conference Information Data Model [I-D.ietf-xcon-common-data-model] Conference Information Data Model
for Centralized Conferencing (XCON Data Model). for Centralized Conferencing (XCON Data Model).
Section 4 provides an overview of the Conference Control Section 2 clarifies the conventions and terminology used in the
document. Section 3 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 4 together with
implementation details. A complete example of the operation of the implementation details. Section 5 delves into the details of the
CCMP, describing a typical call flow associated with conference specific CCMP messages. A complete, not normative, example of the
creation and manipulation, is provided in Section 7. Section 12 operation of the CCMP, describing a typical call flow associated with
provides the XML schema. conference creation and manipulation, is provided in Section 6. A
survey of the methods that can be used to locate a Conference Control
Server is provided in Section 7, whereas Section 8 discusses
potential approaches to notifications management. CCMP transport
over HTTP is highlighted in Section 9. Security considerations are
presented in Section 10. Finally, Section 11 provides the XML
schema.
2. Conventions 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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
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 issue CCMP requests. to issue CCMP requests.
4. XCON Conference Control System Architecture 3. 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 .
. . . .
. +---------------------------------------+ . . +---------------------------------------+ .
skipping to change at page 8, line 21 skipping to change at page 7, line 14
Conference object and conference users do represent key elements Conference object and conference users do represent key elements
involved in Conference Control Protocol operations. Their involved in Conference Control Protocol operations. Their
identifiers, respectively the conference XCON-URI and the identifiers, respectively the conference XCON-URI and the
conferencing client XCON-USERID, and their XML representations conferencing client XCON-USERID, and their XML representations
compliant with the XML Schema defined in the XCON data model are compliant with the XML Schema defined in the XCON data model are
widely used for creating the CCMP requests and responses. The main widely used for creating the CCMP requests and responses. The main
conference objects and users features envisioned by the XCON conference objects and users features envisioned by the XCON
framework are briefly described in the following subsections. framework are briefly described in the following subsections.
4.1. Conference Objects 3.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 conference templates also known as inheritance trees are conference templates also known as
"blueprints". Nodes in the inheritance tree can be active "blueprints". Nodes in the inheritance tree can be active
conferences or simply descriptions that do not currently have any conferences or simply descriptions that do not currently have any
resources associated with them (conference reservations). An object resources associated with them (conference reservations). An object
can mark certain of its properties as unalterable, so that they can mark certain of its properties as unalterable, so that they
cannot be overridden. It is envisaged by the framework that a client cannot be overridden. It is envisaged by the framework that a client
MAY specify a parent object (a conference or blueprint) from which 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 the conference to be created has to inherit values by the mean of the
Conference Control Protocol. Conference Control Protocol.
Conference objects are uniquely identified by the XCON-URI within the Conference objects are uniquely identified by the XCON-URI within the
scope of the conferencing system. Such identifier is introduced in scope of the conferencing system. Such identifier is introduced in
the XCON framework and defined in the XCON common data model. the XCON framework and defined in the XCON common data model.
Conference objects are comprehensively represented through XML Conference objects are comprehensively represented through XML
documents compliant with the XML Schema defined in the XCON data documents compliant with the XML Schema defined in the XCON data
model [I-D.ietf-xcon-common-data-model]. The root element of such model [I-D.ietf-xcon-common-data-model]. The root element of such
documents is one of type "conference-type" called "<conference-info>" documents, called "<conference-info>", is of type "conference-type".
which encompasses other XML elements describing different conference It encompasses other XML elements describing different conference
features and users as well. By the mean of CCMP, conferencing features and users as well. By the mean of CCMP, conferencing
clients can use such XML structures to express their preferences in clients can use such XML structures to express their preferences in
creation or update and conferencing server can convey conference creation or update. A conferencing server can convey conference
information of such a form back to them. information of such a form back to the clients.
4.2. Conference Users 3.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). The XCON-USERID as identifier of each conferencing (XCON-USERID). The XCON-USERID as identifier of each conferencing
system client is introduced in the XCON framework and defined in the system client is introduced in the XCON framework and defined in the
XCON common data model. Each CCMP request, with an exception pointed 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 out in Section 5.3.6 representing the case of a user at his first
entrance in the system as a conference participant, MUST carry the entrance in the system as a conference participant, must carry the
XCON-USERID of the requestor in the proper "confUserID" parameter. XCON-USERID of the requestor in the proper "confUserID" parameter.
The XCON-USERID acts as a pointer to the user's profile as a The XCON-USERID acts as a pointer to the user's profile as a
conference actor, e.g. her signalling URI and other XCON protocol conference actor, e.g. her signalling URI and other XCON protocol
URIs in general, her role (moderator, participant, observer, etc.), URIs in general, her role (moderator, participant, observer, etc.),
her display text, her joining information and so on. A variety of her display text, her joining information and so on. A variety of
elements defined in the common <conference-info> element as specified elements defined in the common <conference-info> element as specified
in the XCON data model are used to describe the users related to a in the XCON data model are used to describe the users related to a
conference, in the first place the <users> element, as well as each conference, in the first place the <users> element, as well as each
<user> element included in it. For example, it is possible to <user> element included in it. For example, it is possible to
skipping to change at page 9, line 46 skipping to change at page 8, line 36
(with "dial-in" being the default mode). If the conference is (with "dial-in" being the default mode). If the conference is
currently active, dial-out users are contacted immediately; currently active, dial-out users are contacted immediately;
otherwise, they are contacted at the start of the conference. The otherwise, they are contacted at the start of the conference. The
CCMP, acting as the Conference Control Protocol, provides a means to 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.
As a consequence of an explicit user registration to a specific XCON As a consequence of an explicit user registration to a specific XCON
conferencing system, conferencing clients are usually provided conferencing system, conferencing clients are usually provided
(besides the XCON-USERID) with log-in credentials (i.e. username and (besides the XCON-USERID) with log-in credentials (i.e. username and
password). Such credentials can be used to authenticate the XCON password). Such credentials can be used to authenticate the XCON
aware client issuing CCMP requests, in order to provide her with the aware client issuing CCMP requests. To this purpose, both username
right authorization information. To this purpose, both username and and password should be carried in a CCMP request as part of the
password SHOULD be carried in a CCMP request as part of the "subject" "subject" parameter whenever a registered conferencing client wishes
parameter whenever a registered conferencing client wishes to contact to contact a CCMP server. The CCMP does not look after users
a CCMP server. The specific registration modality is out of the subscriptions at the conference server; hence, it does not provide
scope of the CCMP document. any specific mechanism allowing clients to register their
conferencing accounts. The "subject" parameter is just used for
carrying authentication data associated with pre-registered clients.
5. Protocol Overview 4. Protocol Overview
CCMP is a client-server, XML-based protocol, which has been CCMP is a client-server, XML-based protocol, which has been
specifically conceived to provide users with the necessary means for specifically conceived to provide users with the necessary means for
the creation, retrieval, modification and deletion of conference the creation, retrieval, modification and deletion of conference
objects. CCMP is also state-less, which means implementations can objects. CCMP is also state-less, which means implementations can
safely handle transactions independently from each other. safely handle transactions independently from each other.
Conference-related information is encapsulated into CCMP messages in Conference-related information is encapsulated into CCMP messages in
the form of XML documents or XML document fragments compliant with the form of XML documents or XML document fragments compliant with
the XCON data model representation. the XCON data model representation.
Section 5.1 specifies the basic operations that can create, retrieve, Section 4.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.
CCMP has been conceived as completely independent from underlying CCMP has been conceived as completely independent from underlying
protocols, which means that there can be different ways to carry CCMP protocols, which means that there can be different ways to carry CCMP
messages across the network, from a conferencing client to a messages across the network, from a conferencing client to a
conferencing server. Nevertheless, it is recommended to use HTTP as conferencing server. Nevertheless, it is recommended to use HTTP as
a transport solution, including CCMP requests in HTTP POST messages a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies. Implementation details and CCMP responses in HTTP 200 OK replies. Implementation details
are presented in Section 5.2 are presented in Section 4.2
5.1. Protocol Operations 4.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 current conferences (active or used to obtain the XCON-URIs of the current conferences (active or
registered) handled by the conferencing server and/or the registered) handled by the conferencing server and/or the
available blueprints. 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
conference client completes prior to another client's operation on conference client completes prior to another client's operation on
the same conference object. The details for this data locking the same conference object. The details for this data locking
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. In order to invoking a specific operation on the conference server. In order to
effectively manage modifications to conference data, a versioning effectively manage modifications to conference data, a versioning
approach is exploited in the CCMP. More precisely, each conference approach is exploited in the CCMP. More precisely, each conference
object is associated with a version number indicating the most up to object is associated with a version number indicating the most up to
date view of the conference at the server's side. Such version date view of the conference at the server's side. Such version
number is reported to the clients when answering their requests. A number is reported to the clients when answering their requests. A
client willing to make modifications to a conference object has to client willing to make modifications to a conference object has to
send an update message to the server. In case the modifications are send an update message to the server. In case the modifications are
all successfully applied, the server sends back to the client a all successfully applied, the server sends back to the client a "200"
"success" response which also carries information about the current response which also carries information about the current server-side
server-side version of the modified object. With such approach, a version of the modified object. With such approach, a client which
client which is working on version "X" of a conference object and is working on version "X" of a conference object and finds inside a
finds inside a "success" response a version number which is "X+1" can "200" response a version number which is "X+1" can be sure that the
be sure that the version it was aware of was the most up to date. On version it was aware of was the most up to date. On the other hand,
the other hand, if the "success" response carries back a version if the "200" response carries back a version which is at least "X+2",
which is at least "X+2", the client can detect that the object that the client can detect that the object that has been modified at the
has been modified at the server's side was more up to date than the server's side was more up to date than the one it was working upon.
one it was working upon. This is clearly due to the effect of This is clearly due to the effect of concurrent modification requests
concurrent modification requests issued by independent clients. issued by independent clients. Hence, for the sake of having
Hence, for the sake of having available the latest version of the available the latest version of the modified object, the client can
modified object, the client can send to the conference server a send to the conference server a further "retrieve" request. In no
further "retrieve" request. In no case a copy of the conference case a copy of the conference object available at the server is
object available at the server is returned to the client as part of returned to the client as part of the update response message. Such
the update response message. Such a copy can always be obtained a copy can always be obtained through an ad-hoc "retrieve" message.
through an ad-hoc "retrieve" message.
Based on the above considerations, all CCMP response messages Based on the above considerations, all CCMP response messages
carrying in their body a conference document (or a fragment of it) carrying in their body a conference document (or a fragment of it)
MUST contain a "version" parameter. This does not hold for request must contain a "version" parameter. This does not hold for request
messages, for which the "version" parameter is not at all required, messages, for which the "version" parameter is not at all required,
since it represents useless information for the server: as long as since it represents useless information for the server: as long as
the required modifications can be applied to the target conference the required modifications can be applied to the target conference
object with no conflicts, the server does not care whether or not the object with no conflicts, the server does not care whether or not the
client had an up to date view of the information stored at its side. client had an up to date view of the information stored at its side.
This said, it stands clear that a client which has subscribed at the This said, it stands clear that a client which has subscribed at the
server, through the XCON event package [I-D.ietf-xcon-event-package], server, through the XCON event package [I-D.ietf-xcon-event-package],
to notifications about conference object modifications, will always to notifications about conference object modifications, will always
have the most up to date version of that object available at his have the most up to date version of that object available at his
side. side.
skipping to change at page 13, line 5 skipping to change at page 11, line 41
index initialized to a value of 1). Upon reception of the mentioned index initialized to a value of 1). Upon reception of the mentioned
kinds of requests, the server will: (i) generate the proper kinds of requests, the server will: (i) generate the proper
identifier(s); (ii) produce a response in which the received fake identifier(s); (ii) produce a response in which the received fake
identifier(s) carried in the request has (have) been replaced by the identifier(s) carried in the request has (have) been replaced by the
newly created one(s). With this approach we maintain compatibility newly created one(s). With this approach we maintain compatibility
with the data model requirements, at the same time allowing for with the data model requirements, at the same time allowing for
client-initiated manipulation of conference objects at the server's 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 side (which is, by the way, one of the main goals for which the CCMP
protocol has been conceived at the outset). protocol has been conceived at the outset).
5.2. Implementation Approach 4.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 single-verb transport plus CCMP body". With this to as "HTTP single-verb transport plus CCMP body". With this
approach, CCMP is able to take advantage of existing HTTP approach, CCMP is able to take advantage of existing HTTP
functionality. As with SOAP, the CCMP uses a "single HTTP verb" for functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
transport (i.e. a single transaction type for each request/response transport (i.e. a single transaction type for each request/response
skipping to change at page 13, line 29 skipping to change at page 12, line 17
processing and communication burden associated with further processing and communication burden associated with further
intermediaries. With this approach, no modification to the CCMP intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport messages/operations is required to use a different transport
protocol. 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 9 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 5. CCMP messages
CCMP messages are either requests or responses. The general CCMP CCMP messages are either requests or responses. The general CCMP
request message is defined in Section 6.1. The general CCMP response request message is defined in Section 5.1. The general CCMP response
message is defined in Section 6.2. The details of the specific message is defined in Section 5.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 5.3. CCMP response codes are
listed in Section 6.4 listed in Section 5.4
6.1. CCMP Request Message Type 5.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 subject: An optional parameter containing username and password of
the client registered at the conferencing system. Each user who the client registered at the conferencing system. Each user who
subscribes to the conferencing system is assumed to be equipped subscribes to the conferencing system is assumed to be equipped
with those credentials and SHOULD enclose them in each CCMP with those credentials and SHOULD enclose them in each CCMP
request she issues. These fields can be used to control that the request she issues. These fields can be used to control that the
user sending the CCMP request has the authority to perform the user sending the CCMP request has the authority to perform the
entailed operation. The same fields can also be exploited to entailed operation. The same fields can also be exploited to
skipping to change at page 14, line 38 skipping to change at page 13, line 5
confUserID: An optional parameter containing the XCON-USERID of the confUserID: An optional parameter containing the XCON-USERID of the
client. The XCON-USERID is used to identify any conferencing client. The XCON-USERID is used to identify any conferencing
client within the context of the conferencing system and it is client within the context of the conferencing system and it is
assinged by the conferencing server at each conferencing client assinged by the conferencing server at each conferencing client
who interacts with it. The "confUserID" parameter is REQUIRED in who interacts with it. The "confUserID" parameter is REQUIRED in
the CCMP request and response messages with the exception of the the CCMP request and response messages with the exception of the
case of a user who has no XCON-USERID and who wants to enter, via case of a user who has no XCON-USERID and who wants to enter, via
CCMP, a conference whose identifier is known. In such case, a CCMP, a conference whose identifier is known. In such case, a
side-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 5.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.
conference-password: An optional parameter that MUST be inserted in conference-password: An optional parameter that MUST be inserted in
all requests whose target conference object is password-protected all requests whose target conference object is password-protected
(as 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 5.3.
<!-- Definition of CCMP Request --> <!-- Definition of CCMP Request -->
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
<!-- Definition of ccmp-request-type--> <!-- 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"
skipping to change at page 16, line 5 skipping to change at page 14, line 41
<xs:element name="conference-password" type="xs:string" <xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 2: Structure of CCMP Request messages Figure 2: Structure of CCMP Request messages
6.2. CCMP Response Message Type 5.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.
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 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 5.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, in particular, such string can be response. In case of an error, in particular, such string can be
used to provide the client with detailed information about the used to provide the client with detailed information about the
error itself. error itself.
version: An optional parameter reflecting the current version number version: An optional parameter reflecting the current version number
of the conference object referred by the confObjID. This number of the conference object referred by the confObjID. This number
is contained in the "version" attribute of the <conference-info> is contained in the "version" attribute of the <conference-info>
element related to that conference. element related to that conference.
specialized response message: This is specialization of the generic specialized response message: This is specialization of the generic
response message, containing parameters that are dependent on the response message, containing parameters that are dependent on the
specific request sent to the server (e.g., blueprintsResponse). A specific request sent to the server (e.g., blueprintsResponse). A
specialized response message SHOULD be included in the CCMP specialized response message SHOULD be included in the CCMP
response message, except in an error situation where the CCMP response message, except in an error situation where the CCMP
request message did not contain a valid specialized message. In request message did not contain a valid specialized message. In
this case, the conference server MUST return a "response-code" of this case, the conference server MUST return a "response-code" of
"badRequest". The details for the specialized messages and "400". The details for the specialized messages and associated
associated parameters are provided in Section 6.3. parameters are provided in Section 5.3.
<!-- Definition of CCMP Response --> <!-- Definition of CCMP Response -->
<xs:element name="ccmpResponse" type="ccmp-response-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- Definition of ccmp-response-type --> <!-- 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"
skipping to change at page 17, line 43 skipping to change at page 16, line 43
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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 5.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 5.1 and Section 5.2, the following summarizes the specialized
CCMP request/response types described in this document: CCMP request/response types described in this document:
1. blueprintsRequest/blueprintsResponse 1. blueprintsRequest/blueprintsResponse
2. confsRequest/confsResponse 2. confsRequest/confsResponse
3. blueprintRequest/blueprintResponse 3. blueprintRequest/blueprintResponse
4. confRequest/confResponse 4. confRequest/confResponse
5. usersRequest/usersResponse 5. usersRequest/usersResponse
6. userRequest/userResponse 6. userRequest/userResponse
7. sidebarsByValRequest/sidebarsByValResponse 7. sidebarsByValRequest/sidebarsByValResponse
8. sidebarsByRefRequest/sidebarsByRefResponse 8. sidebarsByRefRequest/sidebarsByRefResponse
9. sidebarByValRequest/sidebarByValResponse 9. sidebarByValRequest/sidebarByValResponse
10. sidebarByRefRequest/sidebarByRefResponse 10. sidebarByRefRequest/sidebarByRefResponse
These CCMP request/response pairs use the fundamental CCMP operations These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 5.1 to manipulate the conference data. Table 1 as defined in Section 4.1 to manipulate the conference data. Table 1
summarizes the CCMP operations and corresponding actions that are summarizes the CCMP operations and corresponding actions that are
valid for a specific CCMP request type, noting that neither the valid for a specific CCMP request type, noting that neither the
blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse
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 | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprints | Get list | N/A | N/A | N/A | | blueprints | Get list | N/A | N/A | N/A |
| Request | of | | | | | Request | of | | | |
| | blueprints | | | | | | blueprints | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| blueprint | Get | N/A* | N/A* | N/A* | | blueprint | Get | N/A* | N/A* | N/A* |
| Request | 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 | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| confRequest | Gets | Creates | Changes | Deletes | | confRequest | Gets | Creates | Changes | Deletes |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object | object | object | object | | | object | object | object | object |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| usersRequest | Gets | N/A(**) | Changes | N/A(**) | | usersRequest | Gets | N/A(**) | Changes | N/A(**) |
| | <users> | | <users> | | | | <users> | | <users> | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| userRequest | Gets | Adds a | Changes | Deletes | | userRequest | Gets | Adds a | Changes | Deletes |
| | specified | <user> to | specified | specified | | | specified | <user> to | specified | specified |
| | <user> | a conf | <user> | <user> | | | <user> | a conf | <user> | <user> |
| | | (***) | | | | | | (***) | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarsByVal | Gets | N/A | N/A | N/A | | sidebarsByVal | Gets | N/A | N/A | N/A |
| Request | <sidebars- | | | | | Request | <sidebars- | | | |
| | by-val> | | | | | | by-val> | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarsByRef | Gets | N/A | N/A | N/A | | sidebarsByRef | Gets | N/A | N/A | N/A |
| Request | <sidebars- | | | | | Request | <sidebars- | | | |
| | by-ref> | | | | | | by-ref> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarByVal | Gets | Creates | Changes | Deletes | | sidebarByVal | Gets | Creates | Changes | Deletes |
| Request | sidebar- | sidebar- | sidebar- | sidebar- | | Request | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-val | by-val | by-val | by-val | | | by-val | by-val | by-val | by-val |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| sidebarByRef | Gets | Creates | Changes | Deletes | | sidebarByRef | Gets | Creates | Changes | Deletes |
| Request | sidebar- | sidebar- | sidebar- | sidebar- | | Request | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-ref | by-ref | by-ref | by-ref | | | by-ref | by-ref | by-ref | by-ref |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 1: Request Type Operation Specific Processing
(**): These operations are not allowed for a usersRequest message, (**): These operations are not allowed for a usersRequest message,
since the <users> section, which is the target element of such a since the <users> section, which is the target element of such a
request, is created and removed in conjuntcion with, respectively, request, is created and removed in conjuntcion with, respectively,
skipping to change at page 20, line 33 skipping to change at page 18, line 38
Thus, "update" and "retrieve" are the only semantically correct Thus, "update" and "retrieve" are the only semantically correct
operations for such message. operations for such message.
(***): This operation can involve the creation of an XCON-USERID, if (***): 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 sender does not add it in the "confUserID" parameter, and/or if
the "entity" field of the "userInfo" parameter is void. 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 5.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. The specific blueprintRequest message per Section 5.3.3. The
"confUserID" parameter MUST be included in every blueprintsRequest/ "confUserID" parameter MUST be included in every blueprintsRequest/
Response message and reflect the XCON-USERID of the conferencing Response message and reflect the XCON-USERID of the conferencing
client issuing the request. A blueprintsRequest message REQUIRES no client issuing the request. A blueprintsRequest message REQUIRES no
"confObjID" and "operation" parameters, since it is not targetted to "confObjID" and "operation" parameters, since it is not targetted to
a specific conference instance and it is conceived as a "retrieve- a specific conference instance and it is conceived as a "retrieve-
only" request. In order to obtain a specific subset of the available only" request. In order to obtain a specific subset of the available
blueprints, a client may specify a selection filter providing an blueprints, a client may specify a selection filter providing an
appropriate xpath query in the optional "xpathFilter" parameter of appropriate xpath query in the optional "xpathFilter" parameter of
the request. For example, to select blueprints having both audio and the request. For example, to select blueprints having both audio and
video stream support, a possible xpathFilter value could be: "/ video stream support, a possible xpathFilter value could be: "/
skipping to change at page 22, line 17 skipping to change at page 20, line 24
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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 5.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
currently handled by the conferencing system. The "confUserID" currently handled by the conferencing system. The "confUserID"
parameter MUST be included in every confsRequest/Response message and parameter MUST be included in every confsRequest/Response message and
reflect the XCON-USERID of the conferencing client issuing the reflect the XCON-USERID of the conferencing client issuing the
request. The "confObjID" parameter MUST NOT be included in the request. The "confObjID" parameter MUST NOT be included in the
confsRequest message. The "confsRequest" message is of a "retrieve- confsRequest message. The "confsRequest" message is of a "retrieve-
only" type, since the sole purpose is to collect information only" type, since the sole purpose is to collect information
available at the conference server. Thus, an "operation" parameter available at the conference server. Thus, an "operation" parameter
skipping to change at page 23, line 45 skipping to change at page 22, line 5
<xs:element name="confsInfo" type="info:uris-type" <xs:element name="confsInfo" type="info:uris-type"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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 5.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. Further than the object associated with a specified blueprint. Further than the
"confUserID" parameter, the request MUST include the "confObjID" and "confUserID" parameter, the request MUST include the "confObjID" and
the "operation" one. Again, the "confUserID" parameter MUST be the "operation" one. Again, the "confUserID" parameter MUST be
included in every blueprintRequest/Response message and reflect the included in every blueprintRequest/Response message and reflect the
XCON-USERID of the conferencing client issuing the request. 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. "blueprintsRequest" message.
skipping to change at page 24, line 20 skipping to change at page 22, line 27
The blueprintRequest message SHOULD NOT contain an "operation" The blueprintRequest message SHOULD NOT contain an "operation"
parameter other than "retrieve". The "create", "update" and "delete" parameter other than "retrieve". The "create", "update" and "delete"
operations SHOULD NOT be included in a "blueprintRequest" message operations SHOULD NOT be included in a "blueprintRequest" message
except in the case of privileged users (e.g. the conference server except in the case of privileged users (e.g. the conference server
administration staff), who might authenticate themselves by the mean administration staff), who might authenticate themselves by the mean
of the "subject" request parameter. of the "subject" request parameter.
A blueprintRequest/retrieve carrying a "confObjID" which is not A blueprintRequest/retrieve carrying a "confObjID" which is not
associated with one of the available system's blueprints will associated with one of the available system's blueprints will
generate, on the server's side, a blueprintResponse message generate, on the server's side, a blueprintResponse message
containing an "objectNotFound" error code. This holds also for the containing a "404" error code. This holds also for the case in which
case in which the mentioned "confObjID" is related to an existing the mentioned "confObjID" is related to an existing conference
conference document stored at the server, but associated with an document stored at the server, but associated with an actual
actual conference (be it active or registered) or with a sidebar conference (be it active or registered) or with a sidebar rather than
rather than a blueprint. a blueprint.
In the case of "response-code" of "success" for a "retrieve" In the case of "response-code" of "200" for a "retrieve" operation,
operation, the "blueprintInfo" parameter MUST be included in the 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.
<!-- 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>
skipping to change at page 25, line 41 skipping to change at page 24, line 5
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"> minOccurs="0" maxOccurs="unbounded">
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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 5.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. The objects associated with either active or registered conferences. The
"confUserID" parameter MUST be included in every confRequest/Response "confUserID" parameter MUST be included in every confRequest/Response
message and reflect the XCON-USERID of the conferencing client message and reflect the XCON-USERID of the conferencing client
issuing the request. ConfRequest and confResponse messages MUST also issuing the request. ConfRequest and confResponse messages MUST also
include an "operation" parameter. ConfResponse messages MUST return include an "operation" parameter. ConfResponse messages MUST return
to the requestor a "response-code" and MAY contain a "response- to the requestor a "response-code" and MAY contain a "response-
string" explaining it. Depending upon the type of "operation", a string" explaining it. Depending upon the type of "operation", a
"confObjID" and "confInfo" parameter MAY be included in the "confObjID" and "confInfo" parameter MAY be included in the
skipping to change at page 26, line 16 skipping to change at page 24, line 27
"confObjID" and "confInfo" parameter in the confRequest/confResponse "confObjID" and "confInfo" parameter in the confRequest/confResponse
messages and are detailed below for each "operation" case. messages and are detailed below for each "operation" case.
The creation case deserves care. To create a new conference through The creation case deserves care. To create a new conference through
a "confRequest" message, two 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 the blueprint or of the conference to be contain the XCON-URI of the blueprint or of the conference to be
cloned, while the "confInfo" parameter MUST NOT be included in cloned, while the "confInfo" parameter MUST NOT 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 using 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 default blueprint. created as a clone of the system default blueprint.
In both creation cases, the confResponse, for a successful completion In both creation cases, the confResponse, for a successful completion
of a "create" operation, contains a response-code of "success" and of a "create" operation, contains a response-code of "200" and MUST
MUST contain the XCON-URI of the newly created conference in the contain the XCON-URI of the newly created conference in the
"confObjID" parameter, in order to allow the conferencing client to "confObjID" parameter, in order to allow the conferencing client to
manipulate that conference through following CCMP requests. In manipulate that conference through following CCMP requests. In
addition, the "confInfo" parameter transporting the created addition, the "confInfo" parameter transporting the created
conference document MAY be included, at the discretion of the conference document MAY be included, at the discretion of the
conferencing system implementation, along with an optional version conferencing system implementation, along with an optional version
parameter initialized at "1", since immediatly upon the creation the parameter initialized at "1", since at creation time the conference
conference object is at its first version. object is at its first version.
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 MUST "confObjID" representing the XCON-URI of the target conference MUST
be included and the "confInfo" parameter MUST NOT be included in the be included and the "confInfo" parameter MUST NOT be included in the
request. The conferencing server MUST ignore any "confInfo" request. The conferencing server MUST ignore any "confInfo"
parameter that is received in a confRequest/retrieve. If the parameter that is received in a confRequest/retrieve. If the
confResponse for the "retrieve" operation contains a "response-code" confResponse for the "retrieve" operation contains a "response-code"
of "success", the "confInfo" parameter MUST be included in the of "200", the "confInfo" parameter MUST be included in the response.
response. The "confInfo" parameter MUST contain the entire The "confInfo" parameter MUST contain the entire conference document
conference document describing the target conference object in its describing the target conference object in its current state. The
current state. The current state of the retrieved conference object current state of the retrieved conference object MUST also be
MUST also be reported in the proper "version" response parameter. 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". Note that, in such a case, though the confInfo "confObjID". Note that, in such a case, though the confInfo
parameter has indeed to follow the rules indicated in the XCON data parameter has indeed to follow the rules indicated in the XCON data
model, it does not represent the entire updated version of the target model, it does not represent the entire updated version of the target
conference, since it rather conveys just the modifications to apply conference, since it rather conveys just the modifications to apply
to that conference. For example, in order to change the conference to that conference. For example, in order to change the conference
skipping to change at page 27, line 32 skipping to change at page 25, line 41
<confInfo entity="xcon:8977777@example.com"> <confInfo entity="xcon:8977777@example.com">
<conference-description> <conference-description>
<display-text/> <display-text/>
</conference-description> </conference-description>
</confInfo> </confInfo>
Figure 8: Updating a conference object: removing the title of a Figure 8: Updating a conference object: removing the title of a
conference conference
In the case of a confResponse/update with a response-code of In the case of a confResponse/update with a response-code of "200",
"success", no additional information is required in the response no additional information is required in the response message, which
message, which means the return of confInfo parameter is not means the return of confInfo parameter is not mandatory. A following
mandatory. A following confRequest/retrieve transaction might confRequest/retrieve transaction might provide the CCMP client with
provide the CCMP client with the current aspect of the conference the current aspect of the conference upon the modification, or the
upon the modification, or the Notification Protocol might address Notification Protocol might address that task as well. A "200"
that task as well. A "success" response-code indicates that the response-code indicates that the referenced conference document has
referenced conference document has been changed accordingly to the been changed accordingly to the request by the conferencing server.
request by the conferencing server. The "version" parameter MUST be The "version" parameter MUST be enclosed in the confResponse/update
enclosed in the confResponse/update message, in order to let the message, in order to let the client understand what is the actual
client understand what is the actual current conference-object current conference-object version, upon the applied modifications.
version, upon the applied modifications. An "updateFailed" response- An "409" response-code indicates that the changes reflected in the
code indicates that the changes reflected in the request "confInfo" request "confInfo" are not feasible. This could be due to policies,
are not feasible. This could be due to policies, requestor roles, requestor roles, specific privileges, unacceptable values etc., with
specific privileges, unacceptable values etc., with the reason the reason specific to a conferencing system and its configuration.
specific to a conferencing system and its configuration. Together Together with the "409" response-code, the "version" parameter MUST
with the "updateFailed" response-code, the "version" parameter MUST
be attached in the confResponse/update, by this way allowing the be attached in the confResponse/update, by this way allowing the
client to eventually retrieve the current version of the target client to eventually retrieve the current version of the target
conference if the one she attempted to modify was not the most up-to- conference if the one she attempted to modify was not the most up-to-
date. 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 while the "confInfo" MUST 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 within such a request. The confResponse MUST contain the received within such a request. The confResponse MUST contain the
same "confObjID" that was included in the confRequest. If the same "confObjID" that was included in the confRequest. If the
confResponse/delete operation contains a "success" response-code, the confResponse/delete operation contains a "200" response-code, the
conference indicated in the "confObjID" has been succesfully deleted. conference indicated in the "confObjID" has been successfully
A "success" confResponse/delete MUST NOT contain the "confInfo" deleted. A "200" confResponse/delete MUST NOT contain the "confInfo"
parameter. The "version" parameter SHOULD NOT be returned in any parameter. The "version" parameter SHOULD NOT be returned in any
confResponse/delete. If the conferencing server cannot delete the confResponse/delete. If the conferencing server cannot delete the
conference referenced by the "confObjID" received in the confRequest conference referenced by the "confObjID" received in the confRequest
because it is the parent of another conference object that is in use, because it is the parent of another conference object that is in use,
the conferencing server MUST return a response-code of the conferencing server MUST return a response-code of "425".
"deleteParentFailed".
A confRequest with an "operation" of "retrieve", "update" or "delete" A confRequest with an "operation" of "retrieve", "update" or "delete"
carrying a "confObjID" which is not associated with one of the carrying a "confObjID" which is not associated with one of the
conferences (active or registered) the system is holding will conferences (active or registered) the system is holding will
generate, on the server's side, a confResponse message containing an generate, on the server's side, a confResponse message containing a
"objectNotFound" error code. This holds also for the case in which "404" error code. This holds also for the case in which the
the mentioned "confObjID" is related to an existing conference object mentioned "confObjID" is related to an existing conference object
stored at the server, but associated with a blueprint or with a stored at the server, but associated with a blueprint or with a
sidebar rather than an actual conference. 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 9. Figure 9.
<!-- confRequest --> <!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
skipping to change at page 29, line 43 skipping to change at page 28, line 4
<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"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 9: Structure of the confRequest and confResponse messages Figure 9: Structure of the confRequest and confResponse messages
6.3.5. usersRequest and usersResponse 5.3.5. usersRequest and usersResponse
Through a "usersRequest" message the CCMP client manipulates the XML 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 complusory conference identified by the "confObjID" parameter complusory
included in the request. Inside the <users> element, along with the included in the request. Inside the <users> element, along with the
list of <user> elements associated with conference participants, list of <user> elements associated with conference participants,
there is information that the client may be interested in there is information that the client may be interested in
controlling, such the list of the users to which access to the controlling, such the list of the users to which access to the
conference is allowed/denied, conference participation policies, conference is allowed/denied, conference participation policies,
etc.; for this reason, a customized message has been designed to etc.; for this reason, a customized message has been designed to
skipping to change at page 30, line 19 skipping to change at page 28, line 26
etc.; for this reason, a customized message has been designed to etc.; for this reason, a customized message has been designed to
allow for the manipulation of this specific part of a conference allow for the manipulation of this specific part of a conference
document. 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 the 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 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 "200", 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 "426" indicates
"forbiddenChangeProtected" indicates that the conferencing client that the conferencing client is not allowed to make the changes
is not allowed to make the changes reflected in the "usersInfo" reflected in the "usersInfo" contained in the usersRequest
contained in the usersRequest message. This could be due to message. This could be due to policies, roles, specific
policies, roles, specific privileges, etc., with the reason privileges, etc., with the reason specific to a conferencing
specific to a conferencing system and its configuration. system and its configuration.
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 "403" 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: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">
skipping to change at page 31, line 48 skipping to change at page 30, line 4
<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"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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 5.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
conference server either create, modify, or delete information about conference server either create, modify, or delete information about
a user. A "userRequest" message MUST include the "confObjID", the a user. A "userRequest" message MUST include the "confObjID", the
"operation" parameter, and MAY include a "userInfo" parameter "operation" parameter, and MAY include a "userInfo" parameter
containing the detailed user's information depending upon the containing the detailed user's information depending upon the
operation and whether the "userInfo" has already been populated for a operation and whether the "userInfo" has already been populated for a
skipping to change at page 32, line 30 skipping to change at page 30, line 34
An XCON-USERID SHOULD be assigned to each and every user subscribed An XCON-USERID SHOULD be assigned to each and every user subscribed
to the system. In such a way, a user who is not a conference to the system. In such a way, a user who is not a conference
participant can make requests (provided she has successfully passed participant can make requests (provided she has successfully passed
AAA checks), like creating a conference, retrieving conference AAA checks), like creating a conference, retrieving conference
information, etc.. information, etc..
Conference users can be created in a number of different ways. In Conference users can be created in a number of different ways. In
each of these cases the operation MUST be set to "create" in the each of these cases the operation MUST be set to "create" in the
userRequest message. Each of the userResponse messages for these userRequest message. Each of the userResponse messages for these
cases MUST include the "confObjID", "confUserID", "operation" and cases MUST include the "confObjID", "confUserID", "operation" and
"response-code" parameters. In the case of a response code of "response-code" parameters. In the case of a response code of "200",
"success", the userResponse message MAY include the "userInfo" the userResponse message MAY include the "userInfo" parameter
parameter depending upon the manner in which the user was created: depending upon the manner in which the user was created:
o Conferencing client with an XCON-USERID adds itself to the o Conferencing client with an XCON-USERID adds itself to the
conference: In this case, the "userInfo" parameter MAY be included conference: In this case, the "userInfo" parameter MAY be included
in the userRequest. The "userInfo" parameter MUST contain a in the userRequest. The "userInfo" parameter MUST contain a
<user> element (compliant with the XCON data model) and the <user> element (compliant with the XCON data model) and the
"entity" attribute MUST be set to a value which represents the "entity" attribute MUST be set to a value which represents the
XCON-USERID of the user initiating the request. No additional XCON-USERID of the user initiating the request. No additional
parameters beyond those previously described are required in the parameters beyond those previously described are required in the
userResponse message, in the case of a "response-code" of userResponse message, in the case of a "response-code" of "200".
"success".
o Conferencing client acts on behalf of a third user whose XCON- o Conferencing client acts on behalf of a third user whose XCON-
USERID is known: in this case, the "userInfo" parameter MUST be USERID is known: in this case, the "userInfo" parameter MUST be
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 "200".
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 a new XCON-USERID (created by the server) carried inside the with a new XCON-USERID (created by the server) carried inside the
"confUserID" parameter of the response. This is the only case in "confUserID" parameter of the response. This is the only case in
which a CCMP request can be valid though carrying a void which a CCMP request can be valid though carrying a void
"confUserID" parameter. A "userInfo" parameter MUST be enclosed "confUserID" parameter. A "userInfo" parameter MUST be enclosed
in the request, providing at least a contact URI of the joining in the request, providing at least a contact URI of the joining
client, in order to let the focus instigate the signaling phase client, in order to let the focus instigate the signaling phase
needed to add her to the conference. The mandatory "entity" needed to add her to the conference. The mandatory "entity"
skipping to change at page 33, line 37 skipping to change at page 31, line 38
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <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=200;
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 XCON-USERID in the request "confUserID" is the In this case, the XCON-USERID in the request "confUserID" is the
sender's one and the "entity" attribute of the attached userInfo sender's one and the "entity" attribute of the attached userInfo
is filled with the pre-defined fake value is filled with the pre-defined fake value
"xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the "xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the
third user MUST be returned to the client issuing the request in third user MUST be returned to the client issuing the request in
the "entity" attribute of the response "userInfo" parameter, if the "entity" attribute of the response "userInfo" parameter, if
the "response-code" is "success". [RP] This scenario is intended the "response-code" is "200". [RP] This scenario is intended to
to support both the case where a brand new conferencing system support both the case where a brand new conferencing system user
user is added to a conference by a third party (i.e. a user who is is added to a conference by a third party (i.e. a user who is not
not yet provided with an XCON-USERID) and the case where the CCMP yet provided with an XCON-USERID) and the case where the CCMP
client issuing the request does not know the to-be-added user's client issuing the request does not know the to-be-added user's
XCON-USERID (which means such an identifier could already exist on XCON-USERID (which means such an identifier could already exist on
the server's side for that user). In this last case, the the server's side for that user). In this last case, the
conferencing server is in charge of avoiding XCON-URI duplicates conferencing server is in charge of avoiding XCON-URI duplicates
for the same conferencing client, looking at key fields in the for the same conferencing client, looking at key fields in the
request provided "userInfo" parameter, such as the signalling URI: request provided "userInfo" parameter, such as the signalling URI:
if the joining user is a brand new one, then the generation of a 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 new XCON identifier is needed; otherwise, if that user is an
existing one, the server must recover the corresponding XCON existing one, the server must recover the corresponding XCON
identifier. identifier.
skipping to change at page 34, line 34 skipping to change at page 32, line 38
"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 also be included in the userRequest message. If 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 info within the given conference, she MUST include in someone else's info within the given conference, she MUST include in
the userRequest/retrieve a "userInfo" parameter whose "entity" the userRequest/retrieve a "userInfo" parameter whose "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 "200", 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 "200", 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 "200" indicates that the referenced user element has been
been updated by the conference server. A "response-code" of updated by the conference server. A "response-code" of "426"
"forbiddenChangeProtected" indicates that the conferencing client is indicates that the conferencing client is not allowed to make the
not allowed to make the changes reflected in the "userInfo" in the changes reflected in the "userInfo" in the initial request. This
initial request. This could be due to policies, roles, specific could be due to policies, roles, specific privileges, etc., with the
privileges, etc., with the reason specific to a conferencing system reason specific to a conferencing system and its configuration.
and its configuration.
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 be included in the userRequest message. If the client userid, MUST be included in the userRequest message. If the client
wants to exit the specified conference, no "userInfo" parameter is wants to exit the specified conference, no "userInfo" parameter is
needed in the delete request. On the other hand, if the client wants needed in the delete request. On the other hand, if the client wants
to remove another participant from the given conference, she MUST to remove another participant from the given conference, she MUST
include in the userRequest/delete a "userInfo" parameter whose include in the userRequest/delete a "userInfo" parameter whose
"entity" attribute conveys the xcon-userid of that participant. The "entity" attribute conveys the xcon-userid of that participant. The
userResponse MUST contain the same "confObjID" that was included in userResponse MUST contain the same "confObjID" that was included in
the userRequest. The userResponse MUST contain a "response-code" of the userRequest. The userResponse MUST contain a "response-code" of
"success" if the target <user> element has been successfully deleted. "200" if the target <user> element has been successfully deleted. If
If the userResponse for the "delete" operation contains a "response- the userResponse for the "delete" operation contains a "response-
code" of "success", the userResponse MUST NOT contain the "userInfo" code" of "200", the userResponse MUST NOT contain the "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>
skipping to change at page 36, line 29 skipping to change at page 34, line 30
<xs:element name="userInfo" type="info:user-type <xs:element name="userInfo" type="info:user-type
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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 5.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. As with blueprints and included in a "sidebarsByValRequest" message. As with blueprints and
conferences, also with sidebars, CCMP allows for the use of xpath conferences, also with sidebars, CCMP allows for the use of xpath
filters whenever a selected subset of the sidebars available at the filters whenever a selected subset of the sidebars available at the
server's side has to be retrieved by the client. This applies both server's side has to be retrieved by the client. This applies both
to sidebars by reference and to sidebars by value. A to sidebars by reference and to sidebars by value. A
"sidebarsByValResponse" with a "response-code" of "success" MUST "sidebarsByValResponse" with a "response-code" of "200" MUST contain
contain a "sidebarsByValInfo" parameter containing the desired a "sidebarsByValInfo" parameter containing the desired <sidebars-by-
<sidebars-by-val> element. A "sidebarsByValResponse" message MUST val> element. A "sidebarsByValResponse" message MUST carry back to
carry back to the client a "version" element related to the current the client a "version" element related to the current version of the
version of the main conference object (i.e. the one whose identifier main conference object (i.e. the one whose identifier is contained in
is contained in the "confObjId" field of the request) to which the the "confObjId" field of the request) to which the sidebars in
sidebars in question are associated. The "sidebarsByValInfo" question are associated. The "sidebarsByValInfo" parameter contains
parameter contains the list of the conference objects associated with the list of the conference objects associated with the sidebars by
the sidebars by value derived from the main conference. The value derived from the main conference. The retrieved sidebars can
retrieved sidebars can then be updated or deleted using the then be updated or deleted using the "sidebarByValRequest" message,
"sidebarByValRequest" message, which is described in Section 6.3.8. which is described in Section 5.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>
skipping to change at page 38, line 4 skipping to change at page 36, line 7
<!-- 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" minOccurs="0"/> type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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 5.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 has to be created. If no "sidebarByValInfo" which the sidebar has to be created. If no "sidebarByValInfo"
skipping to change at page 38, line 37 skipping to change at page 36, line 39
following the implementation specific cloning rules. Otherwise, following the implementation specific cloning rules. Otherwise,
similarly to the case of direct creation, the sidebar conference similarly to the case of direct creation, the sidebar conference
object is built on the basis of the "sidebarByValInfo" parameter object is built on the basis of the "sidebarByValInfo" parameter
provided by the requestor. As a consequence of a sidebar-by-val provided by the requestor. As a consequence of a sidebar-by-val
creation, the conference server MUST update the main conference creation, the conference server MUST update the main conference
object reflected by the "confObjID" parameter in the object reflected by the "confObjID" parameter in the
sidebarbyValRequest/create message introducing the new sidebar object sidebarbyValRequest/create message introducing the new sidebar object
as a new new <entry> in the proper section <sidebars-by-val>. The as a new new <entry> in the proper section <sidebars-by-val>. The
newly created sidebar conference object MAY be included in the newly created sidebar conference object MAY be included in the
sidebarByValResponse in the "sidebarByValInfo" parameter, if the sidebarByValResponse in the "sidebarByValInfo" parameter, if the
"response-code" is "success". The XCON-URI of the newly created "response-code" is "200". The XCON-URI of the newly created sidebar
sidebar MUST appear in the "confObjID" parameter of the response. MUST appear in the "confObjID" parameter of the response. The
The conference server can notify any conferencing clients that have conference server can notify any conferencing clients that have
subscribed to the conference event package, and are authorized to subscribed to the conference event package, and are authorized to
receive the notifications, of the addition of the sidebar to the receive the notifications, of the addition of the sidebar to the
conference. 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 5.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. A included in a confRequest message as detailed in Section 5.3.4. A
"sidebarByValResponse" message MUST carry back to the client a "sidebarByValResponse" message MUST carry back to the client a
"version" element related to the current version of the sidebar whose "version" element related to the current version of the sidebar whose
identifier is contained in the "confObjId" field 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" If a sidebarByValRequest with an "operation" of "retrieve", "update"
or "delete" carries a "confObjID" which is not associated with any or "delete" carries a "confObjID" which is not associated with any
existing sidebar-by-val, a confResponse message containing an existing sidebar-by-val, a confResponse message containing a "404"
"objectNotFound" error code will be generated on the server's side. error code will be generated on the server's side. This holds also
This holds also for the case in which the mentioned "confObjID" is for the case in which the mentioned "confObjID" is related to an
related to an existing conference object stored at the server, but existing conference object stored at the server, but associated with
associated with a blueprint or with an actual conference or with a a blueprint or with an actual conference or with a sidebar-by-ref
sidebar-by-ref rather than a sidebar-by-val. 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:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
skipping to change at page 40, line 45 skipping to change at page 39, line 4
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<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:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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 5.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
"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 "200", the "sidebarsByRefInfo" parameter, containing the <sidebars-
<sidebars-by-ref> element of the conference object, MUST be included by-ref> element of the conference object, MUST be included in the
in the response. The <sidebars-by-ref> element represents the set of response. The <sidebars-by-ref> element represents the set of URIs
URIs of the sidebars associated with the main conference, whose 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. A "sidebarByRef" request message, described in Section 5.3.10. A
"sidebarsByRefResponse" message MUST carry back to the client a "sidebarsByRefResponse" message MUST carry back to the client a
"version" element related to the current version of the main "version" element related to the current version of the main
conference object (i.e. the one whose identifier is contained in the conference object (i.e. the one whose identifier is contained in the
"confObjId" field of the request) to which the sidebars in question "confObjId" field of the request) to which the sidebars in question
are associated. are associated.
<!-- sidebarsByRefRequest --> <!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
skipping to change at page 42, line 37 skipping to change at page 40, line 39
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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 5.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 a "create" operation, the "confObjID" parameter MUST In the case of a "create" operation, the "confObjID" parameter MUST
be included in the sidebyRefRequest message. In this case, the be included in the sidebyRefRequest 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 has to be created. If no "sidebarByRefInfo" which the sidebar has to be created. If no "sidebarByRefInfo"
skipping to change at page 43, line 12 skipping to change at page 41, line 15
([RFC5239]), the sidebar is created by cloning the main conference, ([RFC5239]), the sidebar is created by cloning the main conference,
following the implementation specific cloning rules. Otherwise, following the implementation specific cloning rules. Otherwise,
similarly to the case of direct creation, the sidebar conference similarly to the case of direct creation, the sidebar conference
object is built on the basis of the "sidebarByRefInfo" parameter object is built on the basis of the "sidebarByRefInfo" parameter
provided by the requestor. If the creation of the sidebar is provided by the requestor. If the creation of the sidebar is
successful, the conference server MUST update the "sidebars-by-ref" successful, the conference server MUST update the "sidebars-by-ref"
element in the conference object from which the sidebar was created element in the conference object from which the sidebar was created
(i.e., as identified by the "confObjID" in the original sidebarByRef (i.e., as identified by the "confObjID" in the original sidebarByRef
request), with the URI of the newly created sidebar. The newly request), with the URI of the newly created sidebar. The newly
created conference object MAY be included in the response in the created conference object MAY be included in the response in the
"sidebarByRefInfo" parameter with a "response-code" of "success". "sidebarByRefInfo" parameter with a "response-code" of "200". The
The URI for the conference object associated with the newly created URI for the conference object associated with the newly created
sidebar object MUST appear in the "confObjID" parameter of the sidebar object MUST appear in the "confObjID" parameter of the
response. The conference server can notify any conferencing clients response. The conference server can notify any conferencing clients
that have subscribed to the conference event package, and are that have subscribed to the conference event package, and are
authorized to receive the notifications, of the addition of the authorized to receive the notifications, of the addition of the
sidebar to the conference. 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 5.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. A confRequest message as detailed in Section 5.3.4. A
"sidebarByRefResponse" message MUST carry back to the client a "sidebarByRefResponse" message MUST carry back to the client a
"version" element related to the current version of the sidebar whose "version" element related to the current version of the sidebar whose
identifier is contained in the "confObjId" field 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
skipping to change at page 44, line 9 skipping to change at page 42, line 12
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" If a sidebarByRefRequest with an "operation" of "retrieve", "update"
or "delete" carries a "confObjID" which is not associated with any or "delete" carries a "confObjID" which is not associated with any
existing sidebar-by-ref, a confResponse message containing an existing sidebar-by-ref, a confResponse message containing a "404"
"objectNotFound" error code will be generated on the server's side. error code will be generated on the server's side. This holds also
This holds also for the case in which the mentioned "confObjID" is for the case in which the mentioned "confObjID" is related to an
related to an existing conference object stored at the server, but existing conference object stored at the server, but associated with
associated with a blueprint or with an actual conference or with a a blueprint or with an actual conference or with a sidebar-by-val
sidebar-by-val rather than a sidebar-by-ref. 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>
skipping to change at page 45, line 28 skipping to change at page 43, line 30
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <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 5.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. 200 Success: Successful completion of the requested operation.
400 Bad Request: Syntactically malformed request.
badRequest: Syntactically malformed request. 401 Unauthorized: User not allowed to perform the required
operation.
objectNotFound: Target conference object missing at the server (it 403 Forbidden: Operation not allowed (e.g., cancellation of a
refers to the "confObjID" parameter in the generic request blueprint).
404 Object Not Found: Target conference object missing at the server
(it refers to the "confObjID" parameter in the generic request
message) message)
409 Conflict: A generic error associated with all those situations
userNotFound: Target user missing at the server (it is related to in which a requested client operation cannot be successfully
the XCON-USERID in the "entity" attribute of the "userInfo" completed by the server. An example of such situation is when the
modification of an object cannot be applied due to conflicts
arising at the server's side, e.g. because the client version of
the object is an obsolete one and the requested modifications
collide with the up-to-date state of the object stored at the
server. Such code would also be used if a client attempts to
create an object (conference or user) with an entity that already
exists.
420 User Not Found: Target user missing at the server (it is related
to the XCON-USERID in the "entity" attribute of the "userInfo"
parameter when it is included in userRequests) parameter when it is included in userRequests)
421 Invalid confUserID: User missing at the server (this code is
invalidConfUserID: User missing at the server (this code is returned returned in the case of requests in which the "confUserID" of the
in the case of requests in which the "confUserID" of the sender is sender is invalid).
invalid). 422 Invalid Conference Password: Target conference object's password
contained in the request is wrong.
invalidConfPassword: Target conference object's password contained 423 Conference Password Required: "conference-password" missing in a
in the request is wrong. request to access a password-protected conference object.
424 Authentication Required: User's authentication information
confPasswordRequired: "conference-password" missing in a request to missing in a request to perform the requested operation. "subject"
access a password-protected conference object. parameter needed in the request.
425 Forbidden Delete Parent: Cancel operation failed since the
unauthorized: User not allowed to perform the required operation. target object is a parent of child objects which depend on it, or
because it effects, based on the "parent-enforceable" mechanism,
authenticationRequired: User's authentication information missing in the corresponding element in a child object.
a request to perform the requested operation. "subject" parameter 426 Forbidden Change Protected: Update refused by the server because
needed in the request. the target element cannot be modified due to its implicit
dependence on the value of a parent object ("parent-enforceable"
forbidden: Operation not allowed (e.g., cancellation of a mechanism).
blueprint). 500 Server Internal Error: The server cannot complete the required
service due to a system internal error.
forbiddenDeleteParent: Cancel operation failed since the target 501 Not Implemented: Operation envisaged in the protocol, but not
object is a parent of child objects which depend on it, or because
it effects, based on the "parent-enforceable" mechanism, the
corresponding element in a child object.
forbiddenChangeProtected: Update refused by the server because the
target element cannot be modified due to its implicit dependence
on the value of a parent object ("parent-enforceable" mechanism).
requestTimeout: The time required to serve the request has exceeded
the envisaged service threshold.
serverInternalError: The server cannot complete the required service
due to a system internal error.
notImplemented: Operation envisaged in the protocol, but not
implemented in the contacted server. implemented in the contacted server.
510 Request Timeout: The time required to serve the request has
exceeded the envisaged service threshold.
511 Resources Not Available: This code is used when the CCMP server
cannot execute a command because of resource issues, e.g. it
cannot create a sub conference because the system has reached its
limits on the number of sub conferences, or if a request for
adding a new user fails because the max number of users has been
reached for the conference or the max number of users has been
reached for the conferencing system.
updateFailed A generic error associated with all those situations in The handling of a "response-code" of "404", "409", "420", "421",
which a requested "update" cannot be successfully completed by the "425" and "426" are only applicable to specific operations for
server. An example of such situation is when the modification of specialized message responses and the details are provided in
an object cannot be applied due to conflicts arising at the Section 5.3. The following table summarizes these response codes and
server's side (e.g. because the client version of the object is an the specialized message and operation to which they are applicable:
obsolete one and the requested modifications collide with the up-
to-date state of the object stored at the server).
The handling of a "response-code" of "objectNotFound",
"userNotFound", "deleteParentFailed" and "forbiddenChangeProtected"
are only applicable to specific operations for specialized message
responses and the details are provided in Section 6.3. The following
table summarizes these response codes and the specialized message and
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 | | 404 | userReques | All | All update | All delete |
| | | | requests | | | | t, | retrieve | requests | requests |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| objectNotFoun | userReques | All | All update | All delete |
| d | t, | retrieve | requests | requests |
| | sidebarBy | requests, | | | | | sidebarBy | requests, | | |
| | ValRequest | EXCEPT: | | | | | ValRequest | EXCEPT: | | |
| | sidebars | blueprints | | | | | sidebars | blueprints | | |
| | ByRefReque | Request, | | | | | ByRefReque | Request, | | |
| | st | confsRequ | | | | | st | confsRequ | | |
| | | est | | | | | | est | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | 409 | N/A | N/A | All update | N/A |
| userNotFound | userReques | userReques | userReques | userReques | | | | | requests | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| 420 | userReques | userReques | userReques | userReques |
| | t(3rd part | t | t | t | | | t(3rd part | t | t | t |
| | yinvite | | | | | | yinvite | | | |
| | with thir | | | | | | with thir | | | |
| | duser | | | | | | duser | | | |
| | entity) | | | | | | entity) | | | |
| | (*) | | | | | | (*) | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | 421 | All create | All | All update | All delete |
| invalidConfUs | All create | All | All update | All delete | | | requests, | retrieve | requests | requests |
| erID | requests, | retrieve | requests | requests |
| | EXCEPT: | requests | | | | | EXCEPT: | requests | | |
| | userReques | | | | | | userReques | | | |
| | twith no | | | | | | twith no | | | |
| | confUserI | | | | | | confUserI | | | |
| | D(**) | | | | | | D(**) | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | 425 | N/A | N/A | N/A | All delete |
| forbiddenDele | N/A | N/A | N/A | All delete | | | | | | request |
| teParent | | | | request |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | 426 | N/A | N/A | All update | N/A |
| forbiddenChan | N/A | N/A | All update | N/A | | | | | requests | |
| geProtected | | | requests | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 2: Response codes and associated operations Table 2: Response codes and associated operations
(*) "userNotFound" in answer to a "userRequest/create" operation: in (*) "420" in answer to a "userRequest/create" operation: in the case
the case of a third-party invite, this code can be returned if the of a third-party invite, this code can be returned if the
"confUserID" (contained in the "entity" attribute of the "userInfo" "confUserID" (contained in the "entity" attribute of the "userInfo"
parameter) of the user to be added is unknown. In the case above, if parameter) of the user to be added is unknown. In the case above, if
instead it is the "confUserID" of the sender of the request that is instead it is the "confUserID" of the sender of the request that is
invalid, an "invalidConfUserID" error code is returned to the client. invalid, a "421" error code is returned to the client.
(**) "invalidConfUserID" is not sent in answers to "userRequest/ (**) "421" is not sent in answers to "userRequest/create" messages
create" messages having a "null" confUserID, since this case is having a "null" confUserID, since this case is associated with a user
associated with a user who is unaware of his own XCON-USERID, but who is unaware of his own XCON-USERID, but wants to enter a known
wants to enter a known conference. conference.
In the case of a response code of "requestTimeout", a conferencing In the case of a response code of "510", a conferencing client MAY
client MAY re-attempt the request within a period of time that would re-attempt the request within a period of time that would be specific
be specific to a conference control client or conference control to a conference control client or conference control server.
server.
A response code of "badRequest" indicates that the conference control A response code of "400" indicates that the conference control client
client sent a malformed request, which is indicative of an error in sent a malformed request, which is indicative of an error in the
the conference control client or in the conference control server. conference control client or in the conference control server. The
The handling is specific to the conference control client handling is specific to the conference control client implementation
implementation (e.g., generate a log, display an error message, (e.g., generate a log, display an error message, etc.). It is NOT
etc.). It is NOT RECOMMENDED that the client re-attempt the request RECOMMENDED that the client re-attempt the request in this case.
in this case.
Response codes such as "unauthorized" and "forbidden" indicate the Response codes such as "401" and "403" indicate the client does not
client does not have the appropriate permissions, or there is an have the appropriate permissions, or there is an error in the
error in the permissions: re-attempting the request would likely not permissions: re-attempting the request would likely not succeed and
succeed and thus it is NOT RECOMMENDED. thus it is NOT RECOMMENDED.
Any unexpected or unknown "response-code" SHOULD be treated by the Any unexpected or unknown "response-code" SHOULD be treated by the
client in the same manner as a "serverInternalError" "response-code", client in the same manner as a "500" "response-code", the handling of
the handling of which is specific to the conference control client which is specific to the conference control client implementation.
implementation.
7. A complete example of the CCMP in action 6. A complete example of the CCMP in action
In this section a typical scenario in which the CCMP comes into play In this section a typical, not normative, scenario in which the CCMP
is described, by showing the actual composition of the various CCMP comes into play is described, by showing the actual composition of
messages. In the call flows of the example, the Conference Control the various CCMP messages. In the call flows of the example, the
Client is a CCMP-enabled client, whereas the Conference Control Conference Control Client is a CCMP-enabled client, whereas the
Server is a CCMP-enabled server. The "confUserID" of the client, Conference Control Server is a CCMP-enabled server. The "confUserID"
Alice, is "xcon-userid:Alice@example.com" and appears in all of the client, Alice, is "xcon-userid:Alice@example.com" and appears
requests. The sequence of operations is as follows: in all requests. The sequence of operations is as follows:
1. Alice retrieves from the server the list of available blueprints 1. Alice retrieves from the server the list of available blueprints
(Section 7.1); (Section 6.1);
2. Alice asks for detailed information about a specific blueprint 2. Alice asks for detailed information about a specific blueprint
(Section 7.2); (Section 6.2);
3. Alice decides to create a new conference by cloning the retrieved 3. Alice decides to create a new conference by cloning the retrieved
blueprint (Section 7.3); blueprint (Section 6.3);
4. Alice modifies information (e.g. XCON-URI, name, description) 4. Alice modifies information (e.g. XCON-URI, name, description)
associated with the newly created blueprint (Section 7.4); associated with the newly created blueprint (Section 6.4);
5. Alice specifies a list of users to be contacted when the 5. Alice specifies a list of users to be contacted when the
conference is activated (Section 7.5); conference is activated (Section 6.5);
6. Alice joins the conference (Section 6.6);
6. Alice joins the conference (Section 7.6);
7. Alice lets a new user, Ciccio, (whose "confUserID" is 7. Alice lets a new user, Ciccio, (whose "confUserID" is
"xcon-userid:Ciccio@example.com") join the conference "xcon-userid:Ciccio@example.com") join the conference
(Section 7.7). (Section 6.7).
Note, the examples do not include any details beyond the basic Note, the examples do not include any details beyond the basic
operation. operation.
In the following sections we deal with each of the above mentioned In the following sections we deal with each of the above mentioned
actions separately. actions separately.
7.1. Alice retrieves the available blueprints 6.1. Alice retrieves the available blueprints
This section illustrates the transaction associated with retrieval of This section illustrates the transaction associated with retrieval of
the blueprints, together with a dump of the two messages exchanged the blueprints, together with a dump of the two messages exchanged
("blueprintsRequest" and "blueprintsResponse"). As it comes out from ("blueprintsRequest" and "blueprintsResponse"). As it comes out from
the figure, the "blueprintsResponse" message contains, in the the figure, the "blueprintsResponse" message contains, in the
"blueprintsInfo" parameter, information about the available "blueprintsInfo" parameter, information about the available
blueprints, in the form of the standard XCON-URI of the blueprint, blueprints, in the form of the standard XCON-URI of the blueprint,
plus additional (and optional) information, like its display-text and plus additional (and optional) information, like its display-text and
purpose. purpose.
skipping to change at page 50, line 17 skipping to change at page 47, line 37
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP blueprintsRequest message | | CCMP blueprintsRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: (null) | | - confObjID: (null) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CMP blueprintsResponse message | | CMP blueprintsResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: (null) | | - confObjID: (null) |
| - response-code: success | | - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. | | - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintsRequest message: 1. blueprintsRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
skipping to change at page 50, line 47 skipping to change at page 48, line 22
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri> <info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room: <info:purpose>Simple Room:
conference room with public access, conference room with public access,
where only audio is available, more users where only audio is available, more users
can talk at the same time can talk at the same time
and the requests for the AudioFloor and the requests for the AudioFloor
skipping to change at page 52, line 14 skipping to change at page 49, line 35
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
</blueprintsInfo> </blueprintsInfo>
</ccmp:blueprintsResponse> </ccmp:blueprintsResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 17: Getting blueprints from the server Figure 17: Getting blueprints from the server
7.2. Alice gets detailed information about a specific blueprint 6.2. Alice gets detailed information about a specific blueprint
This section illustrates the second transaction in the overall flow. This section illustrates the second transaction in the overall flow.
In this case, Alice, who now knows the XCON-URIs of the blueprints In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about CCMP "blueprintRequest" message, to get detailed information about
one of them (the one called with XCON-URI one of them (the one called with XCON-URI
"xcon:AudioRoom@example.com"). The picture shows such transaction. "xcon:AudioRoom@example.com"). The picture shows such transaction.
Notice that the response contains, in the "blueprintInfo" parameter, Notice that the response contains, in the "blueprintInfo" parameter,
a document compliant with the standard XCON data model. a document compliant with the standard XCON data model.
skipping to change at page 52, line 40 skipping to change at page 50, line 18
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: bp123 | | - confObjID: bp123 |
| - operation: retrieve | | - operation: retrieve |
| - blueprintInfo: (null) | | - blueprintInfo: (null) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP blueprintResponse message | | CCMP blueprintResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: bp123 | | - confObjID: bp123 |
| - operation: retrieve | | - operation: retrieve |
| - response-code: success | | - response-code: 200 |
| - blueprintInfo: bp123Info | | - blueprintInfo: bp123Info |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintRequest message: 1. blueprintRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
skipping to change at page 53, line 33 skipping to change at page 51, line 4
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type"> xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com"> <blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description> <info:conference-description>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count> <info:maximum-user-count>2</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="audioLabel"> <info:entry label="audioLabel">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
skipping to change at page 54, line 4 skipping to change at page 51, line 24
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:join-handling>allow</xcon:join-handling>
</info:users> </info:users>
<xcon:floor-information> <xcon:floor-information>
<xcon:floor-request-handling>confirm <xcon:floor-request-handling>confirm
</xcon:floor-request-handling> </xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</blueprintInfo> </blueprintInfo>
</ccmp:blueprintResponse> </ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 18: Getting info about a specific blueprint Figure 18: Getting info about a specific blueprint
7.3. Alice creates a new conference through a cloning operation 6.3. Alice creates a new conference through a cloning operation
This section illustrates the third transaction in the overall flow. This section illustrates the third transaction in the overall flow.
Alice decides to create a new conference by cloning the blueprint Alice decides to create a new conference by cloning the blueprint
having XCON-URI "xcon:AudioRoom@example.com", for which she just having XCON-URI "xcon:AudioRoom@example.com", for which she just
retrieved detailed information through the "blueprintRequest" retrieved detailed information through the "blueprintRequest"
message. This is achieved by sending a "confRequest/create" message message. This is achieved by sending a "confRequest/create" message
having the blueprint's URI in the "confObjID" parameter. The picture having the blueprint's URI in the "confObjID" parameter. The picture
shows such transaction. Notice that the response contains, in the shows such transaction. Notice that the response contains, in the
"confInfo" parameter, the document associated with the newly created "confInfo" parameter, the document associated with the newly created
conference, which is compliant with the standard XCON data model. conference, which is compliant with the standard XCON data model.
skipping to change at page 54, line 47 skipping to change at page 52, line 21
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: AudioRoom | | - confObjID: AudioRoom |
| - operation: create | | - operation: create |
| - confInfo: (null) | | - confInfo: (null) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP confResponse message | | CCMP confResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: newConfId | | - confObjID: newConfId |
| - operation: create | | - operation: create |
| - response-code: success | | - response-code: 200 |
| - version: 1 | | - version: 1 |
| - confInfo: newConfInfo | | - confInfo: newConfInfo |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
skipping to change at page 55, line 41 skipping to change at page 53, line 14
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-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>200</ccmp:response-code>
<ccmp:version>1</ccmp:version> <ccmp:version>1</ccmp:version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
skipping to change at page 56, line 32 skipping to change at page 54, line 4
<info:users> <info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:join-handling>allow</xcon:join-handling>
</info:users> </info:users>
<xcon:floor-information> <xcon:floor-information>
<xcon:floor-request-handling> <xcon:floor-request-handling>
confirm</xcon:floor-request-handling> confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="11"/> <xcon:floor id="11"/>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 19: Creating a new conference by cloning a blueprint Figure 19: Creating a new conference by cloning a blueprint
7.4. Alice updates conference information 6.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 "200", which
acknowledges the modifications requested by the client, while also acknowledges the modifications requested by the client, while also
updating the conference version number from 1 to 2, as reflected in updating the conference version number from 1 to 2, as reflected 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 |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP confResponse message | | CCMP confResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - response-code: success | | - response-code: 200 |
| - version: 2 | | - version: 2 |
| - confInfo: (null) | | - confInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?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 <ccmpRequest
skipping to change at page 58, line 24 skipping to change at page 55, line 44
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-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>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:version>2</ccmp:version> <ccmp:version>2</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 20: Updating conference information Figure 20: Updating conference information
7.5. Alice inserts a list of users in the conference object 6.5. Alice inserts a list of users in the conference object
This section illustrates the fifth transaction in the overall flow. This section illustrates the fifth transaction in the overall flow.
Alice modifies the <allowed-users-list> under the <users> element in Alice modifies the <allowed-users-list> under the <users> element in
the document associated with the conference she created. To the the document associated with the conference she created. To the
purpose, she exploits the "usersRequest" message provided by the purpose, she exploits the "usersRequest" message provided by the
CCMP. The picture below shows the transaction. CCMP. The picture below shows the transaction.
Alice updates information about the list of users to whom access to Alice updates information about the list of users to whom access to
the conference is permitted: the conference is permitted:
skipping to change at page 59, line 13 skipping to change at page 56, line 30
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - usersInfo: usersUpdates | | - usersInfo: usersUpdates |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP usersResponse message | | CCMP usersResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - response-code: success | | - response-code: 200 |
| - version: 3 | | - version: 3 |
| - usersInfo: (null) | | - usersInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. usersRequest message: 1. usersRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
skipping to change at page 60, line 13 skipping to change at page 57, line 31
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-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>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>200</ccmp:response-code>
<ccmp:version>3</ccmp:version> <ccmp:version>3</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 21: Updating the list of allowed users for the conference Figure 21: Updating the list of allowed users for the conference
'xcon:8977794@example.com' 'xcon:8977794@example.com'
7.6. Alice joins the conference 6.6. Alice joins the conference
This section illustrates the sixth transaction in the overall flow. This section illustrates the sixth transaction in the overall flow.
Alice uses the CCMP to add herself to the newly created conference. Alice uses the CCMP to add herself to the newly created conference.
This is achieved through a "userRequest/create" message containing, This is achieved through a "userRequest/create" message containing,
in the "userInfo" parameter, a <user> element compliant with the XCON in the "userInfo" parameter, a <user> element compliant with the XCON
data model representation. Notice that such element includes data model representation. Notice that such element includes
information about the user's Address of Records, as well as her information about the user's Address of Records, as well as her
current end-point. The picture below shows the transaction. Notice current end-point. The picture below shows the transaction. Notice
how the "confUserID" parameter is equal to the "entity" attribute of how the "confUserID" parameter is equal to the "entity" attribute of
the <userInfo> element, which indicates that the request issued by the <userInfo> element, which indicates that the request issued by
skipping to change at page 61, line 7 skipping to change at page 58, line 24
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: AliceUserInfo | | - userInfo: AliceUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - response-code: success | | - response-code: 200 |
| - version: 4 | | - version: 4 |
| - userInfo: (null) | | - userInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. userRequest message: 1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
skipping to change at page 62, line 8 skipping to change at page 59, line 27
<?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>200</ccmp:response-code>
<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 6.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 conferencing system overall flow. Alice uses the CCMP to add a new conferencing system
user, Ciccio, to the conference. This "third-party" request is user, Ciccio, to the conference. This "third-party" request is
realized through a "userRequest/create" message containing, in the realized through a "userRequest/create" message containing, in the
"userInfo" parameter, a <user> element compliant with the XCON data "userInfo" parameter, a <user> element compliant with the XCON data
model representation. Notice that such element includes information model representation. Notice that such element includes information
about Ciccio's Address of Records, as well as his current end-point, about Ciccio's Address of Records, as well as his current end-point,
but has a fake "entity" attribute, since it is unknown to Alice, in but has a fake "entity" attribute, since it is unknown to Alice, in
this example. Thus, the server is in charge of generating a new this example. Thus, the server is in charge of generating a new
skipping to change at page 63, line 4 skipping to change at page 60, line 21
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: CiccioUserInfo(with dummy "entity") | | - userInfo: CiccioUserInfo(with dummy "entity") |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - response-code: success | | - response-code: 200 |
| - version: 5 | | - version: 5 |
| - userInfo: CiccioUserInfo | | - userInfo: CiccioUserInfo |
| (with actual "entity") | | (with actual "entity") |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 1. "third party" userRequest message from Alice:
skipping to change at page 64, line 4 skipping to change at page 61, line 22
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>200</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: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>
</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 7. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. The result of the discovery process, is the address of the requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server. http: or https: URI, which identifies a conference server.
This document proposes the use of DNS to locate the conferencing This document proposes the use of DNS to locate the conferencing
server. U-NAPTR resolution for conferencing takes a domain name as server. U-NAPTR resolution for conferencing takes a domain name as
input and produces a URI that identifies the conferencing server. input and produces a URI that identifies the conferencing server.
This process also requires an Application Service tag and an This process also requires an Application Service tag and an
Application Protocol tag, which differentiate conferencing-related Application Protocol tag, which differentiate conferencing-related
NAPTR records from other records for that domain. NAPTR records from other records for that domain.
Section 13.4.1 defines an Application Service tag of "XCON", which is Section 12.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 13.4.2, is used to identify an XCON server that understands Section 12.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
The NAPTR records in the following example Figure 24 demonstrate the The NAPTR records in the following example Figure 24 demonstrate the
use of the Application Service and Protocol tags. Iterative NAPTR use of the Application Service and Protocol tags. Iterative NAPTR
resolution is used to delegate responsibility for the conferencing resolution is used to delegate responsibility for the conferencing
service from "zonea.example.com." and "zoneb.example.com." to service from "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.com. zonea.example.com.
;; order pref flags ;; order pref flags
skipping to change at page 66, line 4 skipping to change at page 62, line 45
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex "!*.!https://confs.example.com/!" ; regex
. ; replacement . ; replacement
) )
Figure 24: Sample XCON:CCMP Service NAPTR Records Figure 24: Sample XCON:CCMP Service NAPTR Records
Details for the "XCON" Application Service tag and the "CCMP" Details for the "XCON" Application Service tag and the "CCMP"
Application Protocol tag are included in Section 13.4. Application Protocol tag are included in Section 12.4.
9. Managing Notifications 8. Managing Notifications
In cases where the conference control client uses SIP [RFC3261] as When the conference control client uses SIP [RFC3261] as the
the signaling protocol to participate in the conference, SIP event signaling protocol to participate in the conference, SIP event
notification can be used. This would REQUIRE the conference control notification can be used. In such a case, the conference control
client to implement the Conference event package for XCON client MUST implement the Conference event package for XCON
[I-D.ietf-xcon-event-package]. This is the default mechanism for [I-D.ietf-xcon-event-package]. This is the default mechanism for
conferencing clients as is SIP for signaling per the XCON Framework conferencing clients as is SIP for signaling per the XCON Framework
[RFC5239]. [RFC5239].
In the case where the interface to the conference server is entirely In the case where the interface to the conference server is entirely
web based, there is a common mechanism for web-based systems that web based, there is a common mechanism for web-based systems that
could be used - a "call back". With this mechanism, the conference could be used - a "call back". With this mechanism, the conference
client provides the conference server with an HTTP URL which is client provides the conference server with an HTTP URL which is
invoked when a change occurs. This is a common implementation invoked when a change occurs. This is a common implementation
mechanism for e-commerce. This works well in the scenarios whereby mechanism for e-commerce. This works well in the scenarios whereby
the conferencing client is a web server that provides the graphical the conferencing client is a web server that provides the graphical
HTML user interface and uses CCMP as the backend interface to the HTML user interface and uses CCMP as the backend interface to the
conference server. And, this model can co-exist with the SIP event conference server. And, this model can co-exist with the SIP event
notification model. PC-based clients behind NATs could provide a SIP notification model. PC-based clients behind NATs could provide a SIP
event URI, whereas web servers would probably find the HTTP model event URI, whereas web-based clients using CCMP in the backend would
much easier to program. The details of this approach are out of probably find the HTTP call back approach much easier. The details
scope for the CCMP per se, thus the expectation is that a future of this approach are out of scope for the CCMP per se, thus the
specification will document this solution. expectation is that a future specification will document this
solution.
10. HTTP Transport 9. 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 be 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 "subject" field; carry their own authentication information (in the "subject" field;
see Section 6.1). see Section 5.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 70, line 5 skipping to change at page 65, line 23
transport over TLS [RFC2818]. TLS provides message integrity and transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between the conference control client and the confidentiality between the conference control client and the
conference control server. The conferencing client MUST implement conference control server. The conferencing client MUST implement
the server authentication method described in HTTPS [RFC2818]. The the server authentication method described in HTTPS [RFC2818]. The
device uses the URI obtained during conference server discovery to device uses the URI obtained during conference server discovery to
authenticate the server. The details of this authentication method authenticate the server. The details of this authentication method
are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used,
the conferencing client SHOULD fail a request if server the conferencing client SHOULD fail a request if server
authentication fails. authentication fails.
11. Security Considerations 10. Security Considerations
As identified in the XCON framework [RFC5239], there are a wide As identified in the XCON framework [RFC5239], there are a wide
variety of potential attacks related to conferencing, due to the variety of potential attacks related to conferencing, due to the
natural involvement of multiple endpoints and the capability to natural involvement of multiple endpoints and the capability to
manipulate the data on the conference server using CCMP. Examples of manipulate the data on the conference server using CCMP. Examples of
attacks include the following: an endpoint attempting to listen to attacks include the following: an endpoint attempting to listen to
conferences in which it is not authorized to participate, an endpoint conferences in which it is not authorized to participate, an endpoint
attempting to disconnect or mute other users, and theft of service by attempting to disconnect or mute other users, and theft of service by
an endpoint in attempting to create conferences it is not allowed to an endpoint in attempting to create conferences it is not allowed to
create. create.
skipping to change at page 70, line 18 skipping to change at page 65, line 36
variety of potential attacks related to conferencing, due to the variety of potential attacks related to conferencing, due to the
natural involvement of multiple endpoints and the capability to natural involvement of multiple endpoints and the capability to
manipulate the data on the conference server using CCMP. Examples of manipulate the data on the conference server using CCMP. Examples of
attacks include the following: an endpoint attempting to listen to attacks include the following: an endpoint attempting to listen to
conferences in which it is not authorized to participate, an endpoint conferences in which it is not authorized to participate, an endpoint
attempting to disconnect or mute other users, and theft of service by attempting to disconnect or mute other users, and theft of service by
an endpoint in attempting to create conferences it is not allowed to an endpoint in attempting to create conferences it is not allowed to
create. create.
The following summarizes the security considerations for CCMP: The following summarizes the security considerations for CCMP:
1. The client MUST determine the proper conference server. The 1. The client MUST determine the proper conference server. The
conference server discovery is described in Section 8. conference server discovery is described in Section 7.
2. The client MUST connect to the proper conference server. The 2. The client MUST connect to the proper conference server. The
mechanisms for addressing this security consideration are mechanisms for addressing this security consideration are
described in Section 11.1. described in Section 10.1.
3. The protocol MUST support a confidentiality and integrity 3. The protocol MUST support a confidentiality and integrity
mechanism. As described in Section 10, implementations of CCMP mechanism. As described in Section 9, implementations of CCMP
MUST implement the HTTP transport over TLS [RFC2818]. MUST implement the HTTP transport over TLS [RFC2818].
4. There are security issues associated with the authorization to 4. There are security issues associated with the authorization to
perform actions on the conferencing system to invoke specific perform actions on the conferencing system to invoke specific
capabilities. A conference server SHOULD ensure that only capabilities. A conference server SHOULD ensure that only
authorized entities can manipulate the conference data. The authorized entities can manipulate the conference data. The
mechanisms for addressing this security consideration are mechanisms for addressing this security consideration are
described in Section 11.2. described in Section 10.2.
5. The privacy and security of the identity of a user in the 5. The privacy and security of the identity of a user in the
conference MUST be assured. The mechanisms to ensure the conference MUST be assured. The mechanisms to ensure the
security and privacy of identity are discussed in Section 11.3. security and privacy of identity are discussed in Section 10.3.
6. A final issue is related to Denial of Service (DoS) attacks on 6. A final issue is related to Denial of Service (DoS) attacks on
the conferencing server itself. In order to minimize the the conferencing server itself. In order to minimize the
potential for DoS attacks, it is RECOMMENDED that conferencing potential for DoS attacks, it is RECOMMENDED that conferencing
systems require user authentication and authorization for any systems require user authentication and authorization for any
client participating in a conference. This can be accomplished client participating in a conference. This can be accomplished
through the use of the mechanisms described in Section 11.2, as through the use of the mechanisms described in Section 10.2, as
well as by using the security mechanisms associated with the well as by using the security mechanisms associated with the
specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). specific signaling (e.g., SIPS) and media protocols (e.g., SRTP).
11.1. Assuring that the Proper Conferencing Server has been contacted 10.1. Assuring that the Proper Conferencing Server has been contacted
When the CCMP transaction is conducted using TLS [RFC5246], the When the CCMP transaction is conducted using TLS [RFC5246], the
conference server can authenticate its identity, either as a domain conference server can authenticate its identity, either as a domain
name or as an IP address, to the conference client by presenting a name or as an IP address, to the conference client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). With the use of HTTP as a an iPAddress or dNSName, respectively). With the use of HTTP as a
transport for CCMP, this is exactly the authentication described by transport for CCMP, this is exactly the authentication described by
TLS [RFC2818]. If the client has external information as to the TLS [RFC2818]. If the client has external information as to the
expected identity or credentials of the proper conference server expected identity or credentials of the proper conference server
(e.g., a certificate fingerprint), these checks MAY be omitted. Any (e.g., a certificate fingerprint), these checks MAY be omitted. Any
implementation of CCMP MUST be capable of being transacted over TLS implementation of CCMP MUST be capable of being transacted over TLS
so that the client can request the above authentication, and a so that the client can request the above authentication, and a
conference server implementation MUST include this feature. Note conference server implementation MUST include this feature. Note
that in order for the presented certificate to be valid at the that in order for the presented certificate to be valid at the
client, the client must be able to validate the certificate. In client, the client must be able to validate the certificate. In
particular, the validation path of the certificate must end in one of particular, the validation path of the certificate must end in one of
the client's trust anchors, even if that trust anchor is the the client's trust anchors, even if that trust anchor is the
conference server certificate itself. conference server certificate itself.
11.2. User Authentication and Authorization 10.2. User Authentication and Authorization
Many policy authorization decisions are based on the identity of the Many policy authorization decisions are based on the identity of the
user or the role that a user may have. The conferencing server MUST user or the role that a user may have. The conferencing server MUST
implement mechanisms for authentication of users to validate their implement mechanisms for authentication of users to validate their
identity. There are several ways that a user might authenticate its identity. There are several ways that a user might authenticate its
identity to the system. For users joining a conference using one of identity to the system. For users joining a conference using one of
the call signaling protocols, the user authentication mechanisms for the call signaling protocols, the user authentication mechanisms for
the specific protocol can be used. For the case of users joining the the specific protocol can be used. For the case of users joining the
conference using the CCMP, TLS is RECOMMENDED. conference using the CCMP, TLS is RECOMMENDED.
skipping to change at page 72, line 4 skipping to change at page 67, line 16
the way the identity was proven or verified by the system. A the way the identity was proven or verified by the system. A
conference server can also allow a completely unauthenticated user conference server can also allow a completely unauthenticated user
into the system - this information SHOULD also be communicated to into the system - this information SHOULD also be communicated to
interested parties. interested parties.
Once a user is authenticated and authorized through the various Once a user is authenticated and authorized through the various
mechanisms available on the conference server, the conference server mechanisms available on the conference server, the conference server
MUST allocate a conference user identifier (XCON-USERID) and SHOULD MUST allocate a conference user identifier (XCON-USERID) and SHOULD
associate the XCON-USERID with any signaling specific user associate the XCON-USERID with any signaling specific user
identifiers that were used for authentication and authorization. identifiers that were used for authentication and authorization.
This XCON-USERID can be provided to a specific user through the This XCON-USERID can be provided to a specific user through the
conference notification interface and MUST be provided to users that conference notification interface and MUST be provided to users that
interact with the conferencing system using the CCMP (i.e., in the interact with the conferencing system using the CCMP (i.e., in the
appropriate CCMP response messages). This conference user identifier appropriate CCMP response messages). This conference user identifier
is REQUIRED for any subsequent operations on the conference object. is REQUIRED for any subsequent operations on the conference object.
11.3. Security and Privacy of Identity 10.3. Security and Privacy of Identity
An overview of the required privacy and anonymity for users of a An overview of the required privacy and anonymity for users of a
conferencing system are provided in the XCON Framework [RFC5239]. conferencing system are provided in the XCON Framework [RFC5239].
The security of the identity in the form of the XCON-USERID is The security of the identity in the form of the XCON-USERID is
provided in the CCMP protocol through the use of TLS. provided in the CCMP protocol through the use of TLS.
The conference server SHOULD provide mechanisms to ensure the privacy The conference server SHOULD provide mechanisms to ensure the privacy
of the XCON-USERID. This is accomplished by the conference client of the XCON-USERID. This is accomplished by the conference client
manipulation of the "provide-anonymity" element defined in the XCON manipulation of the "provide-anonymity" element defined in the XCON
data model ([I-D.ietf-xcon-common-data-model]. The "provide- data model ([I-D.ietf-xcon-common-data-model]. The "provide-
skipping to change at page 73, line 5 skipping to change at page 68, line 6
conferencing system can be configured such that an administrator can conferencing system can be configured such that an administrator can
see all users). To provide the required privacy, the conference see all users). To provide the required privacy, the conference
client SHOULD include the "provide-anonymity" element in the client SHOULD include the "provide-anonymity" element in the
"confInfo" parameter in a CCMP confRequest message with an "update" "confInfo" parameter in a CCMP confRequest message with an "update"
or "create" operation or in the "userInfo" parameter in a CCMP or "create" operation or in the "userInfo" parameter in a CCMP
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 11. 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"
skipping to change at page 85, line 47 skipping to change at page 80, line 49
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </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"> <xsd:restriction base="xsd:positiveInteger">
<xs:enumeration value="success"/> <xsd:pattern value="[0-9][0-9][0-9]" />
<xs:enumeration value="updateFailed"/> </xsd:restriction>
<xs:enumeration value="authorizationRequired"/>
<xs:enumeration value="badRequest"/> </xs:simpleType>
<xs:enumeration value="unauthorized"/>
<xs:enumeration value="forbidden"/>
<xs:enumeration value="objectNotFound"/>
<xs:enumeration value="userNotFound"/>
<xs:enumeration value="invalidConfUserID"/>
<xs:enumeration value="confPasswordRequired"/>
<xs:enumeration value="invalidConfPassword"/>
<xs:enumeration value="forbiddenDeleteParent"/>
<xs:enumeration value="forbiddenChangeProtected"/>
<xs:enumeration value="requestTimeout"/>
<xs:enumeration value="serverInternalError"/>
<xs:enumeration value="notImplemented"/>
<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>
<!-- subject-type --> <!-- subject-type -->
<xs:complexType name="subject-type"> <xs:complexType name="subject-type">
<xs:sequence> <xs:sequence>
<xs:element name="username" type="xs:string" <xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string" <xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- CCMP request extensions... -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- CCMP response extensions... -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema> </xs:schema>
Figure 25 Figure 25
13. IANA Considerations 12. 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.
13.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
""urn:ietf:params:xml:ns:xcon:ccmp"". ""urn:ietf:params:xml:ns:xcon:ccmp"".
URI: "urn:ietf:params:xml:ns:xcon:ccmp" URI: "urn:ietf:params:xml:ns:xcon:ccmp"
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Registrant Contact: IETF, XCON working group, (xcon@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>CCMP Messages</title> <title>CCMP Messages</title>
</head> </head>
skipping to change at page 87, line 43 skipping to change at page 83, line 5
<body> <body>
<h1>Namespace for CCMP Messages</h1> <h1>Namespace for CCMP Messages</h1>
<h2>urn:ietf:params:xml:ns:xcon:ccmp</h2> <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
13.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon:ccmp
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 12 of this document. Section 11 of this document.
13.3. MIME Media Type Registration for 'application/ccmp+xml' 12.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type. This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: ccmp+xml MIME subtype name: ccmp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML for which the Indicates the character encoding of enclosed XML for which the
default is UTF-8. default is UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2. 3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related conference control. Some of the data could protocol data related conference control. Some of the data could
be considered private and thus should be protected. be considered private and thus should be protected.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml. described there also apply to application/ccmp+xml.
13.4. DNS Registrations 12.4. DNS Registrations
Section 13.4.1 defines an Application Service tag of "XCON", which is Section 12.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 13.4.2, is used to identify an XCON server that understands Section 12.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
13.4.1. Registration of a Conference Control Server Application Service 12.4.1. Registration of a Conference Control Server Application Service
Tag Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag This section registers a new S-NAPTR/U-NAPTR Application Service tag
for XCON, as mandated by [RFC3958]. for XCON, as mandated by [RFC3958].
Application Service Tag: XCON Application Service Tag: XCON
Intended usage: Identifies a server that supports centralized Intended usage: Identifies a server that supports centralized
conferencing. conferencing.
Defining publication: RFCXXXX Defining publication: RFCXXXX
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
13.4.2. Registration of a Conference Control Server Application 12.4.2. Registration of a Conference Control Server Application
Protocol Tag for CCMP Protocol Tag for CCMP
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958]. for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol. Manipulation Protocol.
skipping to change at page 90, line 4 skipping to change at page 84, line 42
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958]. for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol. Manipulation Protocol.
Applicable Service Tag(s): XCON Applicable Service Tag(s): XCON
Terminal NAPTR Record Type(s): U Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX Defining Publication: RFCXXXX
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
13.5. CCMP Protocol Registry 12.5. CCMP Protocol Registry
This document requests that the IANA create a new registry for the This document requests that the IANA create a new registry for the
CCMP protocol including an initial registry for operation types and CCMP protocol including an initial registry for operation types and
response codes. response codes.
13.5.1. CCMP Message Types 12.5.1. CCMP Message Types
The CCMP messages are described in Section 5.1 and defined in the XML The CCMP messages are described in Section 4.1 and defined in the XML
schema in Section 12. The following summarizes the requested schema in Section 11. The following summarizes the requested
registry: registry:
Related Registry: CCMP Message Types Registry Related Registry: CCMP Message Types Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New CCMP message types are Registration/Assignment Procedures: New CCMP message types are
allocated on a specification required basis. allocated on a specification required basis.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following initial CCMP message types: This section pre-registers the following initial CCMP message types:
blueprintsRequest: Used by a conference control client to query a blueprintsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of available conferencing system for its capabilities, in terms of available
conference blueprints. conference blueprints.
blueprintsResponse: The blueprintsResponse returns a list of blueprintsResponse: The blueprintsResponse returns a list of
blueprints supported by the specific conference server. blueprints supported by the specific conference server.
confsRequest: Used by a conference control client to query a confsRequest: Used by a conference control client to query a
conferencing system for its scheduled/active conferences. conferencing system for its scheduled/active conferences.
confsResponse: The "confsResponse" returns the list of the currently confsResponse: The "confsResponse" returns the list of the currently
activated/scheduled conferences at the server. activated/scheduled conferences at the server.
confRequest: The "confRequest" is used to create a conference object confRequest: The "confRequest" is used to create a conference object
and/or to request an operation on the conference object as a and/or to request an operation on the conference object as a
whole. whole.
confResponse: The "confResponse" indicates the result of the confResponse: The "confResponse" indicates the result of the
operation on the conference object as a whole. operation on the conference object as a whole.
userRequest: The "userRequest" is used to request an operation on userRequest: The "userRequest" is used to request an operation on
the "user" element in the conference object. the "user" element in the conference object.
userResponse: The "userResponse" indicates the result of the userResponse: The "userResponse" indicates the result of the
requested operation on the "user" element in the conference requested operation on the "user" element in the conference
object. object.
usersRequest This "usersRequest" is used to manipulate the "users" usersRequest This "usersRequest" is used to manipulate the "users"
element in the conference object, including parameters such as the element in the conference object, including parameters such as the
"allowed-users-list", "join-handling", etc. "allowed-users-list", "join-handling", etc.
usersResponse: This "usersResponse" indicates the result of the usersResponse: This "usersResponse" indicates the result of the
request to manipulate the "users" element in the conference request to manipulate the "users" element in the conference
object. object.
sidebarRequest: This "sidebarRequest" is used to retrieve the sidebarRequest: This "sidebarRequest" is used to retrieve the
information related to a sidebar or to create, change or delete a information related to a sidebar or to create, change or delete a
specific sidebar. specific sidebar.
sidebarResponse: This "sidebarResponse" indicates the result of the sidebarResponse: This "sidebarResponse" indicates the result of the
sidebarRequest. sidebarRequest.
13.5.2. CCMP Response Codes 12.5.2. CCMP Response Codes
The following summarizes the requested registry for CCMP Response The following summarizes the requested registry for CCMP Response
codes: codes:
Related Registry: CCMP Response Code Registry Related Registry: CCMP Response Code Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New response codes are allocated Registration/Assignment Procedures: New response codes are allocated
on a first-come/first-serve basis with specification required. on a first-come/first-serve basis with specification required.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following thirteen initial response This section pre-registers the following thirteen initial response
codes as described above in Section 5.1: codes as described above in Section 4.1:
success: This code indicates that the request was successfully 200: This code indicates that the request was successfully
processed. processed.
409: This code indicates that a requested "update" cannot be
updateFailed: This code indicates that a requested "update" cannot successfully completed by the server. An example of such
be successfully completed by the server. An example of such
situation is when the modification of an object cannot be applied situation is when the modification of an object cannot be applied
due to conflicts arising at the server's side (e.g. because the due to conflicts arising at the server's side (e.g. because the
client version of the object is an obsolete one and the requested client version of the object is an obsolete one and the requested
modifications collide with the up-to-date state of the object modifications collide with the up-to-date state of the object
stored at the server). stored at the server).
400: This code indicates that the request was badly formed in some
badRequest: This code indicates that the request was badly formed in fashion.
some fashion. 401: This code indicates that the user was not authorized for the
specific operation on the conference object.
unauthorized: This code indicates that the user was not authorized 403: This code indicates that the specific operation is not valid
for the specific operation on the conference object. for the target conference object.
404: This code indicates that the specific conference object was not
forbidden: This code indicates that the specific operation is not found.
valid for the target conference object. 420: This code is returned in answer to a "userRequest/create"
operation, in the case of a third-party invite, when the
objectNotFound: This code indicates that the specific conference
object was not found.
userNotFound: This code is returned in answer to a "userRequest/
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 421: This code is returned in the case of requests in which the
which the "confUserID" of the sender is invalid. "confUserID" of the sender is invalid.
422: This code is returned in response to all requests wishing to
invalidConfPassword: This code is returned in response to all access/manipulate a password-protected conference object, when the
requests wishing to access/manipulate a password-protected "conference-password" parameter contained in the request is wrong.
conference object, when the "conference-password" parameter 423: This code is returned in response to all requests wishing to
contained in the request is wrong. access/manipulate a password-protected conference object, when the
"conference-password" parameter is missing in the request.
confPasswordRequired: This code is returned in response to all 424: This code is returned in response whenever the server wants to
requests wishing to access/manipulate a password-protected authenticate the requestor through the "subject" parameter and
conference object, when the "conference-password" parameter is such a parameter is not provided in the request.
missing in the request. 425: This code indicates that the conferencing system cannot delete
the specific conference object because it is a parent for another
authenticationRequired: This code is returned in response whenever conference object.
the server wants to authenticate the requestor through the 426: This code indicates that the target conference object cannot be
"subject" parameter and such a parameter is not provided in the changed (e.g., due to policies, roles, privileges, etc.).
request. 510: This code indicates that the request could not be processed
within a reasonable time, with the time specific to a conferencing
forbiddenDeleteParent: This code indicates that the conferencing system implementation.
system cannot delete the specific conference object because it is 500: This code indicates that the conferencing system experienced
a parent for another conference object. some sort of internal error.
501: This code indicates that the specific operation is not
forbiddenChangeProtected: This code indicates that the target implemented on that conferencing system.
conference object cannot be changed (e.g., due to policies, roles,
privileges, etc.).
requestTimeout: This code indicates that the request could not be
processed within a reasonable time, with the time specific to a
conferencing system implementation.
serverInternalError: This code indicates that the conferencing
system experienced some sort of internal error.
notImplemented: This code indicates that the specific operation is
not implemented on that conferencing system.
14. Acknowledgments 13. 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 and Simo Veikkolainen. Special Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special
thanks go to Roberta Presta for her invaluable contribution to this thanks go to Roberta Presta for her invaluable contribution to this
document. Roberta has worked on the specification of the CCMP document. Roberta has worked on the specification of the 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 6 have been
extracted. extracted.
15. Changes since last Version 14. 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 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.
skipping to change at page 95, line 21 skipping to change at page 88, line 12
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
request message for a userRequest with a "create" operation. request message for a userRequest with a "create" operation.
2. Added response-code (error cases) handling - a general section 2. Added response-code (error cases) handling - a general section
for each of the operations (as part of CCMP Response Code for each of the operations (as part of CCMP Response Code
section), so we don't need to re-iterate for each of the messages section), so we don't need to re-iterate for each of the messages
and message specific cases as appropriate (e.g., and message specific cases as appropriate (e.g., 425, modified)
deleteParentFailed, modified)
3. Moved "operation" parameter to be part of general CCMP request 3. Moved "operation" parameter to be part of general CCMP request
and response messages since it is used for more than one message and response messages since it is used for more than one message
type. And, it's necessary to define before describing the type. And, it's necessary to define before describing the
operation specific response-code handling. operation specific response-code handling.
4. Revised normative statements for the various protocol messages 4. Revised normative statements for the various protocol messages
and operations - e.g., messages MUST include parameter x versus and operations - e.g., messages MUST include parameter x versus
SHOULD, adding text for handling of cases where the SHOULDs don't SHOULD, adding text for handling of cases where the SHOULDs don't
happen and the SHOULD NOTs do. Added descriptions for all the happen and the SHOULD NOTs do. Added descriptions for all the
operation types, as appropriate. operation types, as appropriate.
5. Added lots more details in the security section. 5. Added lots more details in the security section.
6. Added section to describe requirements for an HTTP implementation 6. Added section to describe requirements for an HTTP implementation
to support CCMP. to support CCMP.
7. Updated section on notifications - XCON SIP event package is 7. Updated section on notifications - XCON SIP event package is
default, with some discussion of an HTTP callback mechanism default, with some discussion of an HTTP callback mechanism
(ffs). (ffs).
8. Misc editorial nits: qualifying message names in the text, etc., 8. Misc editorial nits: qualifying message names in the text, etc.,
etc., etc. etc., etc.
The following summarizes the changes between the WG 01 and the 02: The following summarizes the changes between the WG 01 and the 02:
1. Changed the basic approach from REST to HTTP as a transport. 1. Changed the basic approach from REST to HTTP as a transport.
This impacted most of the document - i.e., a major rewrite - 02 This impacted most of the document - i.e., a major rewrite - 02
is closer to 00 than the 01. is closer to 00 than the 01.
2. Added full example based on prototype. 2. Added full example based on prototype.
The following summarizes the changes between the WG 00 and the 01: The following summarizes the changes between the WG 00 and the 01:
1. Changed the basic approach from using SOAP to REST - the 1. Changed the basic approach from using SOAP to REST - the
fundamentals are the same in terms of schema, basic operations. fundamentals are the same in terms of schema, basic operations.
This impacted most sections, in particular introduction and This impacted most sections, in particular introduction and
motivation. motivation.
2. Added new request types - blueprintsRequest, blueprintRequest and 2. Added new request types - blueprintsRequest, blueprintRequest and
confsRequest. The first replaces the optionsRequest and the confsRequest. The first replaces the optionsRequest and the
latter allows the client to get a list of all active conferences. latter allows the client to get a list of all active conferences.
3. Merged all requests into the basic operations table. Added 3. Merged all requests into the basic operations table. Added
summary of RESTful examples (referenced by the basic operations summary of RESTful examples (referenced by the basic operations
table. table.
4. Added examples showing RESTful approach - i.e., HTTP methods for 4. Added examples showing RESTful approach - i.e., HTTP methods for
message exchange. message exchange.
5. Removed requestID from the schema (it should be handle by the 5. Removed requestID from the schema (it should be handle by the
transport - e.g., HTTP). Updated schema (based on current transport - e.g., HTTP). Updated schema (based on current
prototype - it still needs another revision. prototype - it still needs another revision.
6. Added placeholders for Notifications and Role Based Access 6. Added placeholders for Notifications and Role Based Access
Control. Control.
7. Added some text for discovery using DNS (including IANA 7. Added some text for discovery using DNS (including IANA
registrations) registrations)
8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to
informational section. informational section.
16. References 15. References
16.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 97, line 38 skipping to change at page 89, line 50
[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-16 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18
(work in progress), February 2010. (work in progress), February 2010.
16.2. Informative References 15.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 98, line 20 skipping to change at page 90, line 33
RFC 3966, December 2004. RFC 3966, December 2004.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-examples] [I-D.ietf-xcon-examples]
Barnes, M., Boulton, C., Miniero, L., Presta, R., and S. Barnes, M., Miniero, L., Presta, R., and S. Romano,
Romano, "Centralized Conferencing Manipulation Protocol "Centralized Conferencing Manipulation Protocol (CCMP)
(CCMP) Call Flow Examples", draft-ietf-xcon-examples-02 Call Flow Examples", draft-ietf-xcon-examples-04 (work in
(work in progress), December 2009. progress), April 2010.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Hadley, M., Moreau, J., and H. Gudgin, M., Nielsen, H., Hadley, M., Moreau, J., and N.
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
World Wide Web Consortium FirstEdition REC-soap12-part1- Framework", World Wide Web Consortium FirstEdition REC-
20030624, June 2003, soap12-part1-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., Hadley, M., Gudgin, M., Moreau, J., and H. Mendelsohn, N., Nielsen, H., Hadley, M., Moreau, J., and
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered 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
 End of changes. 300 change blocks. 
678 lines changed or deleted 540 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/