draft-ietf-xcon-ccmp-15.txt   rfc6503.txt 
XCON Working Group M. Barnes Internet Engineering Task Force (IETF) M. Barnes
Internet-Draft Polycom Request for Comments: 6503 Polycom
Intended status: Standards Track C. Boulton Category: Standards Track C. Boulton
Expires: February 4, 2012 NS-Technologies ISSN: 2070-1721 NS-Technologies
S P. Romano S. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
August 3, 2011 March 2012
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-15
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) allows an The Centralized Conferencing Manipulation Protocol (CCMP) allows a
XCON conferencing system client to create, retrieve, change, and Centralized Conferencing (XCON) system client to create, retrieve,
delete objects that describe a centralized conference. CCMP is a change, and delete objects that describe a centralized conference.
means to control basic and advanced conference features such as CCMP is a means to control basic and advanced conference features
conference state and capabilities, participants, relative roles, and such as conference state and capabilities, participants, relative
details. CCMP is a state-less, XML-based, client server protocol roles, and details. CCMP is a stateless, XML-based, client server
that carries, in its request and response messages, conference protocol that carries, in its request and response messages,
information in the form of XML documents and fragments conforming to conference information in the form of XML documents and fragments
the centralized conferencing data model schema. conforming to the centralized conferencing data model schema.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 4, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6503.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology .....................................5
3. XCON Conference Control System Architecture . . . . . . . . . 5 3. XCON Conference Control System Architecture .....................5
3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7 3.1. Conference Objects .........................................7
3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7 3.2. Conference Users ...........................................7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview ...............................................8
4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 4.1. Protocol Operations ........................................9
4.2. Data Management . . . . . . . . . . . . . . . . . . . . . 10 4.2. Data Management ...........................................10
4.3. Data Model Compliance . . . . . . . . . . . . . . . . . . 11 4.3. Data Model Compliance .....................................11
4.4. Implementation Approach . . . . . . . . . . . . . . . . . 12 4.4. Implementation Approach ...................................12
5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13 5. CCMP Messages ..................................................13
5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13 5.1. CCMP Request Message Type .................................13
5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 15 5.2. CCMP Response Message Type ................................15
5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17 5.3. Detailed Messages .........................................17
5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20 5.3.1. blueprintsRequest and blueprintsResponse ...........20
5.3.2. confsRequest and confsResponse . . . . . . . . . . . 22 5.3.2. confsRequest and confsResponse .....................22
5.3.3. blueprintRequest and blueprintResponse . . . . . . . 23 5.3.3. blueprintRequest and blueprintResponse .............24
5.3.4. confRequest and confResponse . . . . . . . . . . . . 25 5.3.4. confRequest and confResponse .......................26
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 5.3.5. usersRequest and usersResponse .....................30
5.3.6. userRequest and userResponse . . . . . . . . . . . . 31 5.3.6. userRequest and userResponse .......................32
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36 5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37 5.3.8. sidebarByValRequest and sidebarByValResponse .......39
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42 5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44
5.3.11. extendedRequest and extendedResponse . . . . . . . . 45 5.3.11. extendedRequest and extendedResponse ..............47
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46 5.3.12. optionsRequest and optionsResponse ................49
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50 5.4. CCMP Response Codes .......................................53
6. A complete example of the CCMP in action . . . . . . . . . . 53 6. A Complete Example of CCMP in Action ...........................57
6.1. Alice retrieves the available blueprints . . . . . . . . 54 6.1. Alice Retrieves the Available Blueprints ..................58
6.2. Alice gets detailed information about a specific 6.2. Alice Gets Detailed Information about a Specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57 Blueprint .................................................60
6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 59 6.3. Alice Creates a New Conference through a Cloning
6.4. Alice updates conference information . . . . . . . . . . 61 Operation .................................................62
6.5. Alice inserts a list of users in the conference object . 63 6.4. Alice Updates Conference Information ......................65
6.6. Alice joins the conference . . . . . . . . . . . . . . . 65 6.5. Alice Inserts a List of Users into the Conference Object ..66
6.7. Alice adds a new user to the conference . . . . . . . . . 67 6.6. Alice Joins the Conference ................................68
6.8. Alice asks for the CCMP server capabilities . . . . . . . 69 6.7. Alice Adds a New User to the Conference ...................70
6.9. Alice exploits a CCMP server extension . . . . . . . . . 72 6.8. Alice Asks for the CCMP Server Capabilities ...............72
7. Locating a Conference Control Server . . . . . . . . . . . . 74 6.9. Alice Makes Use of a CCMP Server Extension ................75
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76 7. Locating a Conference Server ...................................78
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77 8. Managing Notifications .........................................79
10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 9. HTTP Transport .................................................80
10.1. Assuring that the Proper Conferencing Server has been 10. Security Considerations .......................................82
contacted . . . . . . . . . . . . . . . . . . . . . . . . 80 10.1. Assuring That the Proper Conference Server Has
10.2. User Authentication and Authorization . . . . . . . . . . 80 Been Contacted ...........................................83
10.3. Security and Privacy of Identity . . . . . . . . . . . . 82 10.2. User Authentication and Authorization ....................84
10.4. Mitigating DoS Attacks . . . . . . . . . . . . . . . . . 83 10.3. Security and Privacy of Identity .........................85
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 83 10.4. Mitigating DoS Attacks ...................................86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 11. XML Schema ....................................................87
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 101 12. IANA Considerations ..........................................105
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 102 12.1. URN Sub-Namespace Registration ..........................105
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 102 12.2. XML Schema Registration .................................106
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 103 12.3. MIME Media Type Registration for
12.4.1. Registration of a Conference Control Server 'application/ccmp+xml' ..................................106
Application Service Tag . . . . . . . . . . . . . . . 104 12.4. DNS Registrations .......................................107
12.4.2. Registration of a Conference Control Server 12.4.1. Registration of a Conference Server
Application Protocol Tag for CCMP . . . . . . . . . . 104 Application Service Tag ..........................108
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 104 12.4.2. Registration of a Conference Server
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 105 Application Protocol Tag for CCMP ................108
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 107 12.5. CCMP Protocol Registry ..................................108
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 109 12.5.1. CCMP Message Types ...............................109
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 12.5.2. CCMP Response Codes ..............................111
14.1. Normative References . . . . . . . . . . . . . . . . . . 109 13. Acknowledgments ..............................................113
14.2. Informative References . . . . . . . . . . . . . . . . . 110 14. References ...................................................113
Appendix A. Appendix A: Evaluation of other protocol models 14.1. Normative References ....................................113
and transports considered for CCMP . . . . . . . . 111 14.2. Informative References ..................................114
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 112 Appendix A. Evaluation of Other Protocol Models and
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 113 Transports Considered for CCMP ......................116
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 A.1. Using SOAP for CCMP ......................................117
A.2. A RESTful Approach for CCMP ..............................117
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) "A 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.
The Centralized Conferencing Manipulation Protocol (CCMP) defined in The Centralized Conferencing Manipulation Protocol (CCMP) defined in
this document allows authenticated and authorized users to create, this document allows authenticated and authorized users to create,
manipulate and delete conference objects. Operations on conferences manipulate, and delete conference objects. Operations on conferences
include adding and removing participants, changing their roles, as include adding and removing participants, changing their roles, as
well as adding and removing media streams and associated end points. well as adding and removing media streams and associated endpoints.
The CCMP implements the client-server model within the XCON CCMP implements the client-server model within the XCON framework,
Framework, with the Conference Control Client and Conference Control with the conferencing client and conference server acting as client
Server acting as client and server, respectively. The CCMP uses HTTP and server, respectively. CCMP uses HTTP [RFC2616] as the protocol
[RFC2616] as the protocol to transfer requests and responses, which to transfer requests and responses, which contain the domain-specific
contain the domain-specific XML-encoded data objects defined in XML-encoded data objects defined in [RFC6501] "Conference Information
[I-D.ietf-xcon-common-data-model] Conference Information Data Model Data Model for Centralized Conferencing (XCON)".
for Centralized Conferencing (XCON Data Model).
Section 2 clarifies the conventions and terminology used in the Section 2 clarifies the conventions and terminology used in the
document. Section 3 provides an overview of the Conference Control 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 4 together with with protocol messages is given in Section 4 together with
implementation details. Section 5 delves into the details of the implementation details. Section 5 delves into the details of
specific CCMP messages. A complete, not normative, example of the specific CCMP messages. A complete, non-normative, example of the
operation of the CCMP, describing a typical call flow associated with operation of CCMP, describing a typical call flow associated with
conference creation and manipulation, is provided in Section 6. A conference creation and manipulation, is provided in Section 6. A
survey of the methods that can be used to locate a Conference Control survey of the methods that can be used to locate a conference server
Server is provided in Section 7, whereas Section 8 discusses is provided in Section 7, and Section 8 discusses potential
potential approaches to notifications management. CCMP transport approaches to notifications management. CCMP transport over HTTP is
over HTTP is highlighted in Section 9. Security considerations are highlighted in Section 9. Security considerations are presented in
presented in Section 10. Finally, Section 11 provides the XML Section 10. Finally, Section 11 provides the XML schema.
schema.
2. Conventions and Terminology 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
In additon to the terms defined in the Framework for Centralized In addition to the terms defined in "A 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 that is able
to issue CCMP requests. to issue CCMP requests.
First-Party Request: A request issued by the client to manipulate First-Party Request: A request issued by the client to manipulate
their own conferencing data. its own conferencing data.
Third-Party Request: A request issued by a client to manipulate the Third-Party Request: A request issued by a client to manipulate the
conference data of another client. conference data of another client.
3. 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 .
. . . .
. +---------------------------------------+ . . +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | . . | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | . . +-+-------------------------------------+ | .
skipping to change at page 6, line 43 skipping to change at page 6, line 43
. V . . V .
. +----------------+ . . +----------------+ .
. | Conference | . . | Conference | .
. | Control | . . | Control | .
. | Client | . . | Client | .
. +----------------+ . . +----------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
........................................................ ........................................................
Figure 1: Conference Client Interaction Figure 1: Conferencing Client Interaction
The Centralized Conferencing Manipulation Protocol (CCMP) allows the The Centralized Conferencing Manipulation Protocol (CCMP) allows the
conference control client to interface with the conference object conference control client (conferencing client) to interface with the
maintained by the conferencing system, as depicted in Figure 1. Note conference object maintained by the conferencing system, as depicted
that additional functionality of the Conference Control Client and in Figure 1. Note that additional functionality of the conferencing
Conferencing System is discussed in the XCON framework and related client and conferencing system is discussed in the XCON framework and
documents. related documents.
This section provides details of the identifiers REQUIRED to address This section provides details of the identifiers REQUIRED to address
and manage the clients associated with a conferencing system using and manage the clients associated with a conferencing system using
the CCMP. CCMP.
3.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 a
"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 (i.e., conference reservations). An resources associated with them (i.e., conference reservations). An
object can mark certain of its properties as unalterable, so that object can mark certain of its properties as unalterable, so that
they cannot be overridden. Per the framework, a client may specify a they cannot be overridden. Per the framework, a client may specify a
parent object (a conference or blueprint) from which to inherit parent object (a conference or blueprint) from which to inherit
values when a conference is created using the Conference Control values when a conference is created using the conference control
Protocol. 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. The XCON-URI is introduced in the scope of the conferencing system. The XCON-URI is introduced in the
XCON framework and defined in the XCON common data model. 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 [RFC6501]. The root element of such documents, called
documents, called "<conference-info>", is of type "conference-type". <conference-info>, is of type "conference-type". It encompasses
It encompasses other XML elements describing different conference other XML elements describing different conference features and users
features and users as well. Using the CCMP, conferencing clients can as well. Using CCMP, conferencing clients can use these XML
use these XML structures to express their preferences in creating or structures to express their preferences in creating or updating a
updating a conference. A conferencing server can convey conference conference. A conference server can convey conference information
information using the XML elements back to the clients. back to the clients using the XML elements.
3.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 server creates individual
individual users, assigning them a unique Conference User Identifier users, assigning them a unique conference user identifier (XCON-
(XCON-USERID). The XCON-USERID as identifier of each conferencing USERID). The XCON-USERID as identifier of each conferencing system
system client is introduced in the XCON framework and defined in the client is introduced in the XCON framework and defined in the XCON
XCON common data model. Each CCMP request, with an exception pointed common data model. Each CCMP request, with an exception pointed out
out in Section 5.3.6 representing the case of a user at his first 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 signaling 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 including the <users> element, as well as each <user> conference including the <users> element, as well as each <user>
element included within it. For example, it is possible to determine element included within it. For example, it is possible to determine
how a specific user expects and is allowed to join a conference by how a specific user expects and is allowed to join a conference by
looking at the <allowed-user-list> in <users>: each <target> element looking at the <allowed-users-list> in <users>: each <target> element
involved in such a list represents a user and shows a "method" involved in such a list represents a user and shows a 'method'
attribute defining how the user is expected to join the conference, attribute defining how the user is expected to join the conference,
i.e. "dial-in" for users that are allowed to dial, "dial-out" for i.e., "dial-in" for users that are allowed to dial, "dial-out" for
users that the conference focus will be trying to reach (with users that the conference focus will be trying to reach (with
"dial-in" being the default mode). If the conference is currently "dial-in" being the default mode). If the conference is currently
active, dial-out users are contacted immediately; otherwise, they are active, dial-out users are contacted immediately; otherwise, they are
contacted at the start of the conference. The CCMP, acting as the contacted at the start of the conference. CCMP, acting as the
Conference Control Protocol, provides a means to manipulate these and conference control protocol, provides a means to manipulate these and
other kinds of user-related features. 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. Thus, both username and password aware client issuing CCMP requests. Thus, both username and password
should be carried in a CCMP request as part of the "subject" should be carried in a CCMP request as part of the "subject"
parameter whenever a registered conferencing client wishes to contact parameter whenever a registered conferencing client wishes to contact
a CCMP server. The CCMP does not maintain user's subscriptions at a CCMP server. CCMP does not maintain a user's subscriptions at the
the conference server; hence, it does not provide any specific conference server; hence, it does not provide any specific mechanism
mechanism allowing clients to register their conferencing accounts. allowing clients to register their conferencing accounts. The
The "subject" parameter is just used for carrying authentication data "subject" parameter is just used for carrying authentication data
associated with pre-registered clients, with the specific associated with pre-registered clients, with the specific
registration modality outside the scope of this document. registration modality outside the scope of this document.
4. Protocol Overview 4. Protocol Overview
CCMP is a client-server, XML-based protocol for user creation, CCMP is a client-server, XML-based protocol for user creation,
retrieval, modification and deletion of conference objects. CCMP is retrieval, modification, and deletion of conference objects. CCMP is
a stateless protocol, such that implementations can safely handle a stateless protocol, such that implementations can safely handle
transactions independently from each other. CCMP messages are XML transactions independently from each other. CCMP messages are XML
documents or XML document fragments compliant with the XCON data documents or XML document fragments compliant with the XCON data
model representation [I-D.ietf-xcon-common-data-model]. model representation [RFC6501].
Section 4.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 includes conference. The core set of objects manipulated by CCMP includes
conference blueprints, the conference object, users, and sidebars. conference blueprints, the conference object, users, and sidebars.
Each operation in the protocol model, as summarized in Section 4.1 is Each operation in the protocol model, as summarized in Section 4.1,
atomic and either succeeds or fails as a whole. The conference is atomic and either succeeds or fails as a whole. The conference
server MUST ensure that the operations are atomic in that the server MUST ensure that the operations are atomic in that the
operation invoked by a specific conference client completes prior to operation invoked by a specific conferencing client completes prior
another client's operation on the same conference object. While the to another client's operation on the same conference object. While
details for this data locking functionality are out of scope for the the details for this data locking functionality are out of scope for
CCMP protocol specification and are implementation specific for a the CCMP specification and are implementation specific for a
conference server, some core functionality for ensuring the integrity conference server, some core functionality for ensuring the integrity
of the data is provided by the CCMP as described in Section 4.2. of the data is provided by CCMP as described in Section 4.2.
While the XML documents that are carried in the CCMP need to comply While the XML documents that are carried in CCMP need to comply with
with the XCON data model, there are situations in which the values the XCON data model, there are situations in which the values for
for mandatory elements are unknown by the client. The mechanism for mandatory elements are unknown by the client. The mechanism for
ensuring compliance with the data model in these cases is described ensuring compliance with the data model in these cases is described
in Section 4.3. in Section 4.3.
CCMP is completely independent from underlying protocols, which means CCMP is completely independent from underlying protocols, which means
that there can be different ways to carry CCMP messages from a that there can be different ways to carry CCMP messages from a
conferencing client to a conferencing server. The specification conferencing client to a conference server. The specification
describes the use of HTTP as a transport solution, including CCMP describes the use of HTTP as a transport solution, including CCMP
requests in HTTP POST messages and CCMP responses in HTTP 200 OK requests in HTTP POST messages and CCMP responses in HTTP 200 OK
replies. This implementation approach is further described in replies. This implementation approach is further described in
Section 4.4. Section 4.4.
4.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 object, a conference user, create: for the creation of a conference object, a conference user,
a sidebar, or a blueprint. a 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, 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 as follows:
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>)
external to it (i.e. whose xcon-uris are included in the <entry> and external to it (i.e., whose XCON-URIs are included in the
elements of <sidebars-by-ref>), <entry> elements of <sidebars-by-ref>),
o <user> elements associated with conference users, o <user> elements associated with conference users, and
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.
4.2. Data Management 4.2. Data Management
The XCON Framework defines a model whereby the conference server The XCON framework defines a model whereby the conference server
centralizes and maintains the conference information. Since multiple centralizes and maintains the conference information. Since multiple
clients can modify the same conference objects a conference client clients can modify the same conference objects, a conferencing client
might not have the latest version of a specific conference object might not have the latest version of a specific conference object
when they initiate operations. To determine whether the client has when it initiates operations. To determine whether the client has
the most up to date conference information, a versioning approach is the most up-to-date conference information, CCMP defines a versioning
defined for the CCMP. Each conference object is associated with a approach. Each conference object is associated with a version
version number. All CCMP response messages containing a conference number. All CCMP response messages containing a conference document
document (or a fragment thereof) MUST contain a "version" parameter. (or a fragment thereof) MUST contain a <version> parameter. When a
When a client sends an update message to the server, which includes client sends an update message to the server, which includes
modifications to a conference object, if the modifications are all modifications to a conference object, if the modifications are all
successfully applied, the server MUST return a "200" response successfully applied, the server MUST return a response, with a
containing the version number of the modified object. With this <response-code> of "200", containing the version number of the
approach, a client working on version "X" of a conference object that modified object. With this approach, a client working on version "X"
receives a "200" response with a version number which is "X+1" can be of a conference object that receives a response, with a <response-
certain that the version it manipulated was the most up to date. code> of "200", with a version number that is "X+1" can be certain
However, if the "200" response contains a version which is at least that the version it manipulated was the most up to date. However, if
"X+2", the client knows that the object modified by the server was the response contains a version that is at least "X+2", the client
more up to date than the object the client was manipulating. In knows that the object modified by the server was more up to date than
order to ensure that the client always has the latest version of the the object the client was manipulating. In order to ensure that the
modified object, the client can send a "retrieve" request to the client always has the latest version of the modified object, the
conference server. The client can then update the relevant data client can send a request to the conference server to retrieve the
conference object. The client can then update the relevant data
elements in the conference object prior to invoking a specific elements in the conference object prior to invoking a specific
operation. Note that a client subscribed to the XCON event package operation. Note that a client subscribed to the XCON event package
[I-D.ietf-xcon-event-package] notifications about conference object
modifications, will receive the most up to date version of that [RFC6502] notifications about conference object modifications, will
object upon receipt of a notification. receive the most up-to-date version of that object upon receipt of a
notification.
The "version" parameter is OPTIONAL for requests, since it is not The "version" parameter is OPTIONAL for requests, since it is not
needed by the server: as long as the required modifications can be needed by the server: as long as the required modifications can be
applied to the target conference object without conflicts, the server applied to the target conference object without conflicts, the server
does not care whether the client has stored an up to date view of the does not care whether the client has stored an up-to-date view of the
information. In addition, to ensure the integrity of the data, the information. In addition, to ensure the integrity of the data, 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. uris> and abort the remaining updates.
4.3. Data Model Compliance 4.3. Data Model Compliance
The XCON data model [I-D.ietf-xcon-common-data-model] identifies some The XCON data model [RFC6501] identifies some elements and attributes
elements/attributes as mandatory. Since the XML documents carried in as mandatory. Since the XML documents carried in the body of the
the body of the CCMP requests/responses need to be compliant with the CCMP requests and responses need to be compliant with the XCON data
XCON data model, there can be a problem in cases of client-initiated model, there can be a problem in cases of client-initiated
operations, such as the initial creation of conference objects and operations, such as the initial creation of conference objects and
cases whereby a client updates a conference object adding new cases whereby a client updates a conference object adding new
elements, such as a new user. In such cases, not all of the elements, such as a new user. In such cases, not all of the
mandatory data can be known in advance to the client issuing a CCMP mandatory data can be known in advance by the client issuing a CCMP
request. As an example, a client has no means to know, at the time request. As an example, a client cannot know, at the time it issues
it issues a conference creation request, the XCON-URI that the server a conference creation request, the XCON-URI that the server will
will assign to the yet-to-be-created conference and hence it is not assign to the yet-to-be-created conference; hence, it is not able to
able to appropriately fill with that value the mandatory "entity" populate the mandatory 'entity' attribute of the conference document
attribute of the conference document contained in the request. To contained in the request with the correct value. To solve this
solve this issue, the CCMP client fills all mandatory data model issue, the CCMP client fills all mandatory data model fields, for
fields, for which no value is available at the time the request is which no value is available at the time the request is constructed,
constructed, with fake values in the form of a wildcard string, with placeholder values in the form of a wildcard string,
AUTO_GENERATE_X (all uppercase), with X being a unique numeric index AUTO_GENERATE_X (all uppercase), with X being a unique numeric index
for each data model field for which the value is unknown. This form for each data model field for which the value is unknown. This form
of wildcard string is chosen, rather than the use of random unique of wildcard string is chosen, rather than the use of random unique
strings (e.g, FOO_BAR_LA) or non-numeric values for X, to simplify strings (e.g., FOO_BAR_LA) or non-numeric values for X, to simplify
processing at the server. The values of AUTO_GENERATE_X are only processing at the server. The values of AUTO_GENERATE_X are only
unique within the context of the specific request. The fake unique within the context of the specific request. The placeholder
AUTO_GENERATE_X values MUST be within the value part of an attribute/ AUTO_GENERATE_X values MUST be within the value part of an attribute
element (e.g., <userinfo entity= or element (e.g., <userinfo
"xcon-userid:AUTO_GENERATE_1@example.com">). entity="xcon-userid:AUTO_GENERATE_1@example.com">).
When the server receives requests containing values in the form of When the server receives requests containing values in the form of
AUTO_GENERATE_X, the server does the following: AUTO_GENERATE_X, the server does the following:
(a) Generates the proper identifier for each instance of (a) Generates the proper identifier for each instance of
AUTO_GENERATE_X in the document. If an instance of AUTO_GENERATE_X in the document. If an instance of
AUTO_GENERATE_X is not within the value part of the attribute/ AUTO_GENERATE_X is not within the value part of the attribute/
element, the server MUST respond with an error of 400 Bad element, the server MUST send a <response-code> of "400 Bad
Request. In cases where AUTO_GENERATE_X appears only in the Request". In cases where AUTO_GENERATE_X appears only in the
user part of a URI (i.e., in the case of XCON-USERIDs or XCON- user part of a URI (i.e., in the case of XCON-USERIDs or XCON-
URIs), the server needs to ensure that the domain name is one URIs), the server needs to ensure that the domain name is one
that is within the server's domain of responsibility. If the that is within the server's domain of responsibility. If the
domain name is not within the server's domain of responsibility, domain name is not within the server's domain of responsibility,
then the server MUST return a 427 Invalid Domain Name. The then the server MUST send a <response-code> of "427 Invalid
server MUST replace each instance of a specific wildcard field Domain Name". The server MUST replace each instance of a
(e.g., AUTO_GENERATE_1) with the same identifier. The specific wildcard field (e.g., AUTO_GENERATE_1) with the same
identifiers MUST be unique for each instance of AUTO_GENERATE_X identifier. The identifiers MUST be unique for each instance of
within the same XML document received in the request - e.g., the AUTO_GENERATE_X within the same XML document received in the
value that replaces AUTO_GENERATE_1 MUST NOT be the same as the request; for example, the value that replaces AUTO_GENERATE_1
value that replaces AUTO_GENERATE_2. Note that the values that MUST NOT be the same as the value that replaces AUTO_GENERATE_2.
replace the instances of AUTO_GENERATE_X are not the same across Note that the values that replace the instances of
all conference objects - e.g., different values can be used to AUTO_GENERATE_X are not the same across all conference objects;
replace AUTO_GENERATE_1 in two different documents. for example, different values can be used to replace
AUTO_GENERATE_1 in two different documents.
(b) Sends a response in which all values of AUTO_GENERATE_X received (b) Sends a response in which all values of AUTO_GENERATE_X received
in the request have been replaced by the newly created one(s). in the request have been replaced by the newly created one(s).
With this approach compatibility with the data model requirements is With this approach, compatibility with the data model requirements is
maintained, while allowing for client-initiated manipulation of maintained, while allowing for client-initiated manipulation of
conference objects at the server's side. Note that the use of this conference objects at the server's side. Note that the use of this
mechanism could be avoided in come cases by using multiple mechanism could be avoided in come cases by using multiple
operations, such as creating a new user and then adding the new user operations, such as creating a new user and then adding the new user
to an existing conference. However, the AUTO_GENERATE_X mechanism to an existing conference. However, the AUTO_GENERATE_X mechanism
allows a single operation to be used to effect the same change on the allows a single operation to be used to effect the same change on the
conference object. conference object.
4.4. Implementation Approach 4.4. Implementation Approach
CCMP is implemented using HTTP, placing the CCMP request messages CCMP is implemented using HTTP, placing the CCMP request messages
into the body of an HTTP POST operation and placing the CCMP into the body of an HTTP POST operation and placing the CCMP
responses into the body of the HTTP response messages. A non- responses into the body of the HTTP response messages. A non-
exhaustive summary of the other approaches that were considered and exhaustive summary of the other approaches that were considered and
the perceived advantages of the HTTP solution described in this the perceived advantages of the HTTP solution described in this
document are provided in Appendix A. document are provided in Appendix A.
Most CCMP commands can pend indefinitely, thus increasing the Most CCMP commands can pend indefinitely, thus increasing the
potential that pending requests can continue to increase when a potential that pending requests can continue to increase when a
server is receiving more requests than it can process within a server is receiving more requests than it can process within a
specific time period. In this case a server SHOULD return a 510 specific time period. In this case, a server SHOULD return a
response code to the pending requests. In addition, to mitigate the <response-code> of "510" to the pending requests. In addition, to
situation clients MUST NOT wait indefinitely for a response and MUST mitigate the situation, clients MUST NOT wait indefinitely for a
implement a timer such that when it expires, the client MUST close response and MUST implement a timer such that when it expires, the
the connection. Thirty seconds is RECOMMENDED as the default value client MUST close the connection. Thirty seconds is RECOMMENDED as
for this timer. Sixty seconds is considered a reasonable upper the default value for this timer. Sixty seconds is considered a
range. Note, that there may be cases where a response message is reasonable upper range. Note that there may be cases where a
lost and a request has been successful (e.g., user added to a response message is lost and a request has been successful (e.g.,
conference), yet the client will be unaware and close the connection. user added to a conference); yet, the client will be unaware and
However, as described in Section 4.2, there is a versioning mechanism close the connection. However, as described in Section 4.2, there is
for the conference objects, thus there is a mechanism for the a versioning mechanism for the conference objects; thus, there is a
conference object stored by the client to be brought up to date. mechanism for the conference object stored by the client to be
brought up to date.
CCMP messages have a MIME-type of "application/ccmp+xml", which CCMP messages have a MIME-type of "application/ccmp+xml", which
appears inside the "Content-Type" and "Accept" fields of HTTP appears inside the Content-Type and Accept header fields of HTTP
requests and responses. The XML documents in the CCMP messages MUST requests and responses. The XML documents in the CCMP messages MUST
be encoded in UTF-8. This specification follows the recommendations be encoded in UTF-8. This specification follows the recommendations
and conventions described in [RFC3023], including the naming and conventions described in [RFC3023], including the naming
convention of the type ('+xml' suffix) and the usage of the 'charset' convention of the type ('+xml' suffix) and the usage of the 'charset'
parameter. The 'charset' parameter MUST be included with the XML parameter. The 'charset' parameter MUST be included with the XML
document. Section 9 provides the complete requirements for an HTTP document. Section 9 provides the complete requirements for an HTTP
implementation to support the CCMP. implementation to support CCMP.
5. 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 5.1. The general CCMP response request message is defined in Section 5.1. The general CCMP response
message is defined in Section 5.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 that is carried in the CCMP request and response
messages are described in Section 5.3. CCMP response codes are messages are described in Section 5.3. CCMP response codes are
listed in Section 5.4 listed in Section 5.4.
5.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 the username and password
the client registered at the conferencing system. Each user who of the client registered at the conferencing system. Each user
subscribes to the conferencing system is assumed to be equipped who subscribes to the conferencing system is assumed to be
with those credentials and SHOULD enclose them in each CCMP equipped with those credentials and SHOULD enclose them in each
request she issues. These fields can be used to control that the CCMP request she issues. These fields can be used to control that
user sending the CCMP request has the authority to perform the the user sending the CCMP request has the authority to perform the
entailed operation. The same fields can also be exploited to requested operation. The same fields can also be used for other
carry out other authorization and authentication procedures. authorization and authentication procedures.
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
assigned by the conferencing server at each conferencing client assigned by the conference server for each conferencing client who
who interacts with it. The "confUserID" parameter is REQUIRED in interacts with it. The <confUserID> parameter is REQUIRED in the
the CCMP request and response messages with the exception of the CCMP request and response messages with the exception of the case
case of a user who has no XCON-USERID and who wants to enter, via of a user who has no XCON-USERID and who wants to enter, via CCMP,
CCMP, a conference whose identifier is known. In such case, a a conference whose identifier is known. In such case, a side
side-effect of the request is that the user is provided with an 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 aforementioned case
will be provided in Section 5.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: The parameter is OPTIONAL except that it MUST
all requests whose target conference object is password-protected be inserted in all requests whose target conference object is
(as per the <conference-password> element in password-protected i.e., contains the <conference-password>
[I-D.ietf-xcon-common-data-model]). A CCMP response code of "423" element in [RFC6501]). A CCMP <response-code> of "423" MUST be
MUST be returned if a conference-password is not included in the returned if a conference-password is not included in the request
request when required. when required.
specialized request message: This is specialization of the generic specialized request message: This is a 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 5.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" />
skipping to change at page 15, line 39 skipping to change at page 15, line 39
<xs:element name="operation" type="operationType" <xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<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
5.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 REQUIRED parameter in CCMP response messages confUserID: A REQUIRED parameter in CCMP response messages
containing the XCON-USERID of the conferencing client who issued containing the XCON-USERID of the conferencing client that 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 REQUIRED parameter containing the response code response-code: A REQUIRED 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 5.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, this string can be response. In case of an error, in particular, this 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. This parameter is REQUIRED in element related to that conference. This parameter is REQUIRED in
CCMP response messages and SHOULD NOT be included in CCMP request CCMP response messages and SHOULD NOT be included in CCMP request
messages. messages.
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").
specialized response message SHOULD be included in the CCMP A 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
"400". The details for the specialized messages and associated "400". The details for the specialized messages and associated
parameters are provided in Section 5.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">
skipping to change at page 17, line 42 skipping to change at page 17, line 42
<xs:element name="response-string" type="xs:string" <xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs: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
5.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 5.1 and Section 5.2, the following summarizes the specialized Sections 5.1 and 5.2, the following summarizes the specialized CCMP
CCMP request/response types described in this document: request and 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
skipping to change at page 18, line 35 skipping to change at page 18, line 30
11. extendedRequest/extendedResponse 11. extendedRequest/extendedResponse
12. optionsRequest/optionsResponse 12. optionsRequest/optionsResponse
These CCMP request/response pairs use the fundamental CCMP operations These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 4.1 to manipulate the conference data. These as defined in Section 4.1 to manipulate the conference data. These
request/response pairs are included in an IANA registry as defined in request/response pairs are included in an IANA registry as defined in
Section 12.5. Table 1 summarizes the remaining CCMP operations and Section 12.5. Table 1 summarizes the remaining CCMP operations and
corresponding actions that are valid for a specific CCMP request corresponding actions that are valid for a specific CCMP request
type, noting that neither the blueprintsRequest/blueprintsResponse type, noting that neither the blueprintsRequest/blueprintsResponse
nor confsRequest/confsResponse require an "operation" parameter. An nor confsRequest/confsResponse require an <operation> parameter. An
entity MUST support the response message for each of the request entity MUST support the response message for each of the request
messages that are supported. The corresponding response message MUST messages that is supported. The corresponding response message MUST
contain the same operation. Note that some entries are labeled "N/A" contain the same <operation> parameter. Note that some entries are
indicating the operation is invalid for that request type. In the labeled "N/A", indicating that the operation is invalid for that
case of an "N/A*", the operation MAY be allowed for specific request type. In the case of an "N/A*" label, the operation MAY be
privileged users or system administrators, but is not part of the allowed for specific privileged users or system administrators but is
functionality included in this document. not part of the 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 | Get | Create | Change | Delete |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object | object | object | object | | | object | object | object | object |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Gets | N/A(**) | Changes | N/A(**) | | usersRequest | Get | N/A(**) | Change | N/A(**) |
| | <users> | | <users> | | | | <users> | | <users> | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Gets | Adds a | Changes | Deletes | | userRequest | Get | Add a | Change | Delete |
| | 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 | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | | | Request | <sidebars- | | | |
| | by-val> | | | | | | by-val> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByRef | Gets | N/A | N/A | N/A | | sidebarsByRef | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | | | Request | <sidebars- | | | |
| | by-ref> | | | | | | by-ref> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByVal | Gets | Creates | Changes | Deletes | | sidebarByValR | Get | Create | Change | Delete |
| Request | sidebar- | sidebar- | sidebar- | sidebar- | | equest | 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 | | sidebarByRefR | Get | Create | Change | Delete |
| Request | sidebar- | sidebar- | sidebar- | sidebar- | | equest | 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 conjunction with, respectively, request, is created and removed in conjunction with the creation and
the creation and deletion of the associated conference document. deletion, respectively, of the associated conference document. Thus,
Thus, "update" and "retrieve" are the only semantically correct "update" and "retrieve" are the only semantically correct operations
operations for such message. 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 and
response messages are detailed in the subsequent sections. If a response messages are detailed in the subsequent sections. If a
required parameter is not included in a request, the conference required parameter is not included in a request, the conference
server MUST return a 400 response code per Section 5.4. server MUST return a <response-code> of "400" per Section 5.4.
5.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
of XCON-URIs associated with the available blueprints from the XCON-URIs associated with the available blueprints from the
conference server. These XCON-URIs can be subsequently used by the conference server. These XCON-URIs can be subsequently used by the
client to access detailed information about a specified blueprint client to access detailed information about a specified blueprint
with a specific blueprintRequest message per Section 5.3.3. with a specific blueprintRequest message per Section 5.3.3.
The "confUserID" parameter MUST be included in every The <confUserID> parameter MUST be included in every
blueprintsRequest/Response message and reflect the XCON-USERID of the blueprintsRequest/Response message and reflect the XCON-USERID of the
conferencing client issuing the request. Since a blueprintsRequest conferencing client issuing the request. Since a blueprintsRequest
message is not targetted to a specific conference instance and is a message is not targeted to a specific conference instance and is a
"retrieve-only" request, the "confObjID" and "operation" MUST NOT be "retrieve-only" request, the <confObjID> and <operation> parameters
included in the blueprintsRequest/Response messages. MUST NOT be included in the blueprintsRequest/Response messages.
In order to obtain a specific subset of the available blueprints, a In order to obtain a specific subset of the available blueprints, a
client may specify a selection filter providing an appropriate xpath client may specify a selection filter providing an appropriate xpath
query in the OPTIONAL "xpathFilter" parameter of the request. The query in the OPTIONAL "xpathFilter" parameter of the request. The
information in the blueprints typically represents general information in the blueprints typically represents general
capabilities and characteristics. For example, to select blueprints capabilities and characteristics. For example, to select blueprints
having both audio and video stream support, a possible xpathFilter having both audio and video stream support, a possible xpathFilter
value could be: "/conference-info[conference-description/ value could be: "/conference-info[conference-description/
available-media/entry/type='audio' and conference-description/ available-media/entry/type='audio' and conference-description/
available-media/entry/type='video']". A conference server SHOULD NOT available-media/entry/type='video']". A conference server SHOULD NOT
provide any sensitive information (e.g., passwords) in the provide any sensitive information (e.g., passwords) in the
blueprints. blueprints.
The associated "blueprintsResponse" message SHOULD contain, as shown The associated blueprintsResponse message SHOULD contain, as shown in
in Figure 4, a "blueprintsInfo" parameter containing the above Figure 4, a "blueprintsInfo" parameter containing the above mentioned
mentioned XCON-URI list. XCON-URI list.
<!-- blueprintsRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsRequest" /> <xs:element ref="blueprintsRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
skipping to change at page 22, line 4 skipping to change at page 22, line 17
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintsInfo" <xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <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
messages Figure 4: Structure of the blueprintsRequest and
blueprintsResponse Messages
5.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
list of XCON-URIs associated with active and registered conferences 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
only" type, since the sole purpose is to collect information type, since the sole purpose is to collect information available at
available at the conference server. Thus, an "operation" parameter the conference server. Thus, an <operation> parameter MUST NOT be
MUST NOT be included in a "confsRequest" message. In order to included in a confsRequest message. In order to retrieve a specific
retrieve a specific subset of the available conferences, a client may subset of the available conferences, a client may specify a selection
specify a selection filter providing an appropriate xpath query in filter providing an appropriate xpath query in the OPTIONAL
the OPTIONAL "xpathFilter" parameter of the request. For example, to "xpathFilter" parameter of the request. For example, to select only
select only the registered conferences, a possible xpathFilter value the registered conferences, a possible xpathFilter value could be "/
could be: "/conference-info[conference-description/conference-state/ conference-info[conference-description/conference-state/
active='false']". The associated "confsResponse" message SHOULD active='false']". The associated confsResponse message SHOULD
contain the list of XCON-URIs in the "confsInfo" parameter. A user, contain the list of XCON-URIs in the "confsInfo" parameter. A user,
upon receipt of the response message, can interact with the available upon receipt of the response message, can interact with the available
conference objects through further CCMP messages. conference objects through further CCMP messages.
<!-- confsRequest --> <!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
skipping to change at page 23, line 33 skipping to change at page 24, line 18
<xs:complexType name="confsResponseType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<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
5.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. Along with 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> parameters. Again, the <confUserID> parameter MUST
included in every blueprintRequest/Response message and reflect the be included in every blueprintRequest/Response message and reflect
XCON-USERID of the conferencing client issuing the request. The 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.
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 with a value other than "retrieve". An <operation>
operations SHOULD NOT be included in a "blueprintRequest" message parameter with a value of "create", "update", or "delete" SHOULD NOT
except in the case of privileged users (e.g. the conference server be included in a blueprintRequest message except in the case of
administration staff), who might authenticate themselves by the mean privileged users (e.g., the conference server administration staff),
of the "subject" request parameter. who might authenticate themselves by the mean of the "subject"
request parameter.
A blueprintRequest/retrieve carrying a "confObjID" which is not A blueprintRequest/retrieve carrying a <confObjID> parameter whose
associated with one of the available system's blueprints will value is not associated with one of the available system's
generate, on the server's side, a blueprintResponse message blueprints, will generate, on the server's side, a blueprintResponse
containing a "404" error code. This holds also for the case in which message containing a <response-code> of "404". This also holds for
the mentioned "confObjID" is related to an existing conference the case in which the mentioned <confObjID> parameter value is
document stored at the server, but associated with an actual related to an existing conference document stored at the server, but
conference (be it active or registered) or with a sidebar rather than associated with an actual conference (be it active or registered) or
a blueprint. with a sidebar rather than a blueprint.
In the case of "response-code" of "200" for a "retrieve" operation, For a <response-code> of "200" in a "retrieve" operation, the
the "blueprintInfo" parameter MUST be included in the <blueprintInfo> parameter MUST be included in the blueprintResponse
"blueprintResponse" message. The "blueprintInfo" parameter contains message. The <blueprintInfo> parameter contains the conference
the conference document associated with the blueprint as identified document associated with the blueprint as identified by the
by the "confObjID" parameter specified in the blueprintRequest. <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>
<xs:element ref="blueprintRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 25, line 28 skipping to change at page 26, line 18
<xs:complexType name="blueprintResponseType"> <xs:complexType name="blueprintResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type" <xs:element name="blueprintInfo" 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 6: Structure of the blueprintRequest and blueprintResponse Figure 6: Structure of the blueprintRequest and
messages blueprintResponse Messages
5.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
confRequest and response. The requirements for inclusion of confRequest and response. For each type of operation, the text below
"confObjID" and "confInfo" parameter in the confRequest/confResponse describes whether the <confObjID> and <confInfo> parameters need to
messages and are detailed below for each "operation" case. be included in the confRequest and confResponse messages.
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. Note that cloning of an active conference is the confRequest. Note that cloning of an active conference is
only done in the case of a sidebar operation per the XCON only done in the case of a sidebar operation per the XCON
framework and as described in Section 5.3.8. framework and as described in Section 5.3.8.
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 "200" and MUST of a "create" operation, contains a <response-code> of "200" and 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 containing the conference document
conference document MAY be included, at the discretion of the created MAY be included, at the discretion of the conferencing system
conferencing system implementation, along with the REQUIRED "version" implementation, along with the REQUIRED <version> parameter
parameter initialized at "1", since at creation time the conference initialized at "1", since, at creation time, the conference object is
object is at its first version. at its first version.
In the case of a confRequest with a "retrieve" operation, the In the case of a confRequest with an <operation> parameter of
"confObjID" representing the XCON-URI of the target conference MUST "retrieve", the <confObjID> parameter representing the XCON-URI of
be included and the "confInfo" parameter MUST NOT be included in the the target conference MUST be included and the <confInfo> parameter
request. The conferencing server MUST ignore any "confInfo" MUST NOT be included in the request. The conference server MUST
parameter that is received in a confRequest/retrieve. If the ignore any <confInfo> parameter that is received in a confRequest
confResponse for the "retrieve" operation contains a "response-code" "retrieve" operation. If the confResponse for the retrieve operation
of "200", the "confInfo" parameter MUST be included in the response. contains a <response-code> of "200", the <confInfo> parameter MUST be
The "confInfo" parameter MUST contain the entire conference document included in the response. The <confInfo> parameter MUST contain the
describing the target conference object in its current state. The entire conference document describing the target conference object in
current state of the retrieved conference object MUST also be its current state. The current state of the retrieved conference
reported in the proper "version" response parameter. object MUST also be reported in the proper "version" response
parameter.
In case of a confRequest with an "update" operation, the "confInfo" In case of a confRequest with an <operation> parameter of "update",
and "confObjID" MUST be included in the request. The "confInfo" the <confInfo> and <confObjID> parameters MUST be included in the
represents an object of type "conference-type" containing all the request. The <confInfo> represents an object of type
changes to be applied to the conference whose identifier is "conference-type" containing all the changes to be applied to the
"confObjID". Note that, in such a case, though the confInfo conference whose identifier has the same value as the <confObjID>
parameter has indeed to follow the rules indicated in the XCON data parameter. Note that, in such a case, though the <confInfo>
parameter indeed has 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 conveys just the modifications to apply to that
to that conference. For example, in order to change the conference conference. For example, in order to change the conference title,
title, the confInfo parameter will be of the form: the <confInfo> parameter will be of the form:
<confInfo entity="xcon:8977777@example.com"> <confInfo entity="xcon:8977777@example.com">
<conference-description> <conference-description>
<display-text> *** NEW CONFERENCE TITLE *** </display-text> <display-text> *** NEW CONFERENCE TITLE *** </display-text>
</conference-description> </conference-description>
</confInfo> </confInfo>
Figure 7: Updating a conference object: modifying the title of a Figure 7: Updating a Conference Object: Modifying the
conference Title of a Conference
Similarly, to remove the title of an existing conference, a Similarly, to remove the title of an existing conference, a
confRequest/update carrying the following "confInfo" parameter would confRequest/update carrying the following <confInfo> parameter would
do the job.: do the job.
<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:
conference Removing the Title of a Conference
In the case of a confResponse/update with a response-code of "200", In the case of a confResponse/update with a <response-code> of "200",
no additional information is REQUIRED in the response message, which no additional information is REQUIRED in the response message, which
means the return of confInfo parameter is OPTIONAL. A subsequent means the return of a <confInfo> parameter is OPTIONAL. A subsequent
confRequest/retrieve transaction might provide the CCMP client with confRequest/retrieve transaction might provide the CCMP client with
the current aspect of the conference upon the modification, or the the current status of the conference after the modification, or the
Notification Protocol might address that task as well. A "200" notification protocol might address that task as well. A <response-
response-code indicates that the conference object has been changed code> of "200" indicates that the conference object has been changed
accordingly to the request by the conferencing server. The "version" according to the request by the conference server. The <version>
parameter MUST be enclosed in the confResponse/update message, in parameter MUST be enclosed in the confResponse/update message, in
order to let the client understand what is the actual current order to let the client understand what is the current conference-
conference-object version, upon the applied modifications. An "409" object version, upon the applied modifications. A <response-code> of
response-code indicates that the changes reflected in the request "409" indicates that the changes reflected in the <confInfo>
"confInfo" are not feasible. This could be due to policies, parameter of the request are not feasible. This could be due to
requestor roles, specific privileges, unacceptable values etc., with policies, requestor roles, specific privileges, unacceptable values,
the reason specific to a conferencing system and its configuration. etc., with the reason specific to a conferencing system and its
Together with the "409" response-code, the "version" parameter MUST configuration. Together with a <response-code> of "409", the
be attached in the confResponse/update, by this way allowing the <version> parameter MUST be attached in the confResponse/update,
client to eventually retrieve the current version of the target allowing the client to later retrieve the current version of the
conference if the one she attempted to modify was not the most up-to- target conference if the one she attempted to modify was not the most
date. up to date.
In the case of a confRequest with a "delete" operation, the In the case of a confRequest with an <operation> parameter of
"confObjID" representing the XCON-URI of the target conference MUST "delete", the <confObjID> parameter representing the XCON-URI of the
be included while the "confInfo" MUST NOT be included in the request. target conference MUST be included while the <confInfo> parameter
The conferencing server MUST ignore any "confInfo" parameter that is MUST NOT be included in the request. The conference server MUST
received within such a request. The confResponse MUST contain the ignore any <confInfo> parameter that is received within such a
same "confObjID" that was included in the confRequest. If the request. The confResponse MUST contain the same value for the
confResponse/delete operation contains a "200" response-code, the <confObjID> parameter that was included in the confRequest. If the
conference indicated in the "confObjID" has been successfully confResponse/delete operation contains a <response-code> of "200",
deleted. A "200" confResponse/delete MUST NOT contain the "confInfo" the conference indicated in the <confObjID> parameter has been
parameter. The "version" parameter SHOULD NOT be returned in any successfully deleted. A confResponse/delete with a <response-code>
confResponse/delete. If the conferencing server cannot delete the of "200" MUST NOT contain the <confInfo> parameter. The <version>
conference referenced by the "confObjID" received in the confRequest parameter SHOULD NOT be returned in any confResponse/delete. If the
because it is the parent of another conference object that is in use, conference server cannot delete the conference referenced by the
the conferencing server MUST return a response-code of "425". <confObjID> parameter received in the confRequest because it is the
parent of another conference object that is in use, the conference
server MUST return a <response-code> of "425".
A confRequest with an "operation" of "retrieve", "update" or "delete" A confRequest with an <operation> parameter of "retrieve", "update",
carrying a "confObjID" which is not associated with one of the or "delete" carrying a <confObjID> parameter which is not associated
conferences (active or registered) the system is holding will with one of the conferences (active or registered) that the system is
generate, on the server's side, a confResponse message containing a holding will generate, on the server's side, a confResponse message
"404" error code. This holds also for the case in which the containing a <response-code> of "404". This also holds for the case
mentioned "confObjID" is related to an existing conference object in which the mentioned <confObjID> parameter is related to an
stored at the server, but associated with a blueprint or with a existing conference object stored at the server, but associated with
sidebar rather than an actual conference. a blueprint or with a sidebar rather than an actual conference.
The schema for the confRequest/confResponse pair is shown in The schema for the confRequest/confResponse pair is shown in
Figure 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>
<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 29, line 35 skipping to change at page 30, line 30
<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
5.3.5. usersRequest and usersResponse 5.3.5. usersRequest and usersResponse
The "usersRequest" message allows a client to manipulate the <users> The usersRequest message allows a client to manipulate the <users>
element of the conference object represented by the "confObjID". The element of the conference object represented by the <confObjID>
<users> element contains the list of <user> elements associated with parameter. The <users> element contains the list of <user> elements
conference participants, the list of the users to which access to the associated with conference participants, the list of the users to
conference is allowed/denied, conference participation policies, etc. which access to the conference is allowed/denied, conference
The "confObjID" MUST be included in a "usersRequest" message. participation policies, etc. The <confObjID> parameter MUST be
included in a usersRequest message.
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 the 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 an <operation> parameter of
"retrieve".
2. update: In this case, the "usersInfo" parameter MUST contain the 2. "update": In this case, the <usersInfo> parameter MUST contain
modifications to be applied to the referred <users> element. If the modifications to be applied to the <users> element indicated.
the "response-code" is "200", then the "usersInfo" parameter If 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 "426" indicates returned SHOULD be ignored. A <response-code> of "426" indicates
that the conferencing client is not allowed to make the changes that the conferencing client is not allowed to make the changes
reflected in the "usersInfo" contained in the usersRequest reflected in the <usersInfo> contained in the usersRequest
message. This could be due to policies, roles, specific message. This could be due to policies, roles, specific
privileges, etc., with the reason specific to a conferencing privileges, etc., with the reason being specific to a
system and its configuration. conferencing 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 "403" 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>
skipping to change at page 31, line 35 skipping to change at page 32, line 30
<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
5.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
a conference document associated with a conference identified by the 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> and the
"operation" parameter, and MAY include a "userInfo" parameter <operation> parameters, and it 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
specific user. Note that a user may not necessarily be a specific user. Note that a user may not necessarily be a
conferencing control client (i.e., some participants in a conference conferencing control client (i.e., some participants in a conference
are not "XCON aware"). are not "XCON aware").
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
authorization and authentication checks), like creating a conference, authorization and authentication checks), like creating a conference
retrieving conference information, etc.. or retrieving conference information.
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> parameter MUST be set to
userRequest message. Each of the userResponse messages for these "create" in the userRequest message. Each of the userResponse
cases MUST include the "confObjID", "confUserID", "operation" and messages for these cases MUST include the <confObjID>, <confUserID>,
"response-code" parameters. In the case of a response code of "200", <operation>, and <response-code> parameters. In the case of a
the userResponse message MAY include the "userInfo" parameter <response-code> of "200", the userResponse message MAY include the
depending upon the manner in which the user was created: <userInfo> parameter depending upon the manner in which the user was
created:
o Conferencing client with an XCON-USERID adds itself to the o A 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 that 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 "200". userResponse message, in the case of a <response-code> of "200".
o Conferencing client acts on behalf of a third user whose XCON- o A conferencing client acts on behalf of another 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 other 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 "200". 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 this enter, via CCMP, a conference whose identifier is known: In this
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 initiate the signaling phase
needed to add her to the conference. The mandatory "entity" needed to add her to the conference. The mandatory 'entity'
attribute of the "userInfo" parameter in the request MUST be attribute of the <userInfo> parameter in the request MUST be
filled with a fake value with the user part of the XCON-USERID filled with a placeholder value with the user part of the XCON-
containing a value of AUTO_GENERATE_X as described in Section 4.3, USERID containing a value of AUTO_GENERATE_X as described in
to conform to the rules contained in the XCON data model XML Section 4.3, to conform to the rules contained in the XCON data
schema. The messages (userRequest and userResponse) in this case model XML schema. The messages (userRequest and userResponse) in
should look like the following: this case should look like the following:
Request fields: Request fields:
confUserID=null; confUserID=null;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
userInfo= userInfo=
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<endpoint entity="sip:GHIL345@example.com"> <endpoint entity="sip:GHIL345@example.com">
... ...
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=200; 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
userid Absence of an xcon-userid
o Conferencing client is unaware of the XCON-USERID of a third user: o A conferencing client is unaware of the XCON-USERID of a third
In this case, the XCON-USERID in the request "confUserID" is the user: In this case, the XCON-USERID in the request, <confUserID>,
sender's one and the "entity" attribute of the attached userInfo is the sender's and the 'entity' attribute of the attached
is filled with the fake value <userInfo> parameter is filled with the placeholder value
"xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for
the third user MUST be returned to the client issuing the request the third user MUST be returned to the client issuing the request
in the "entity" attribute of the response "userInfo" parameter, if in the 'entity' attribute of the response <userInfo> parameter, if
the "response-code" is "200". This scenario is intended to the <response-code> is "200". This scenario is intended to
support both the case where a brand new conferencing system user support both the case where a brand new conferencing system user
is added to a conference by a third party (i.e. a user who is not is added to a conference by a third party (i.e., a user who has
yet provided with an XCON-USERID) and the case where the CCMP not yet been provided with an XCON-USERID) and the case where the
client issuing the request does not know the to-be-added user's CCMP client issuing the request does not know the to-be-added
XCON-USERID (which means such an identifier could already exist on user's XCON-USERID (which means such an identifier could already
the server's side for that user). In this last case, the exist on the server's side for that user). In this last case, the
conferencing server is in charge of avoiding XCON-URI duplicates conference server is in charge of avoiding XCON-URI duplicates for
for the same conferencing client, looking at key fields in the 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 signaling URI.
if the joining user is a brand new one, then the generation of a If the joining user is brand new, then the generation of a new
new XCON identifier is needed; otherwise, if that user is an XCON-USERID is needed; otherwise, if that user exists already, the
existing one, the server must recover the corresponding XCON server must recover the corresponding XCON-USERID.
identifier.
In the case of a userRequest with a "retrieve" operation, the In the case of a userRequest with an <operation> parameter of
"confObjID" representing the XCON-URI of the target conference MUST "retrieve", the <confObjID> parameter representing the XCON-URI of
be included. The "confUserID", containing the CCMP client's xcon- the target conference MUST be included. The <confUserID>, containing
userid, MUST also be included in the userRequest message. If the the CCMP client's XCON-USERID, MUST also be included in the
client wants to retrieve information about her profile in the userRequest message. If the client wants to retrieve information
specified conference, no "userInfo" parameter is needed in the about her profile in the specified conference, no <userInfo>
retrieve request. On the other hand, if the client wants to obtain parameter is needed in the retrieve request. On the other hand, if
someone else's info within the given conference, she MUST include in the client wants to obtain someone else's info within the given
the userRequest/retrieve a "userInfo" parameter whose "entity" conference, she MUST include in the userRequest/retrieve a <userInfo>
attribute conveys the desired user's xcon-userid. If the parameter whose 'entity' attribute conveys the desired user's XCON-
userResponse for the "retrieve" operation contains a "response-code" USERID. If the userResponse for the retrieve operation contains a
of "200", the "userInfo" parameter MUST be included in the response. <response-code> of "200", the <userInfo> parameter MUST be included
in the response.
In case of a userRequest with an "update" operation, the "confObjID", In case of a userRequest with an <operation> parameter of "update",
"confUserID" and "userInfo" MUST be included in the request. The the <confObjID>, <confUserID>, and <userInfo> parameters MUST be
"userInfo" is of type "user-type" and contains all the changes to be included in the request. The <userInfo> parameter is of type "user-
applied to a specific <user> element in the conference object type" and contains all the changes to be applied to a specific <user>
identified by the "confObjID" in the userRequest message. The user element in the conference object identified by the <confObjID>
to be modified is identified through the "entity" attribute of the parameter in the userRequest message. The user to be modified is
"userInfo" parameter included in the request. In the case of a identified through the 'entity' attribute of the <userInfo> parameter
userResponse with a "response-code" of "200", no additional included in the request. In the case of a userResponse with a
information is required in the "userResponse" message. A "response- <response-code> of "200", no additional information is required in
code" of "200" indicates that the referenced user element has been the userResponse message. A <response-code> of "200" indicates that
updated by the conference server. A "response-code" of "426" the referenced <user> element has been updated by the conference
indicates that the conferencing client is not allowed to make the server. A <response-code> of "426" indicates that the conferencing
changes reflected in the "userInfo" in the initial request. This client is not allowed to make the changes reflected in the <userInfo>
could be due to policies, roles, specific privileges, etc., with the in the initial request. This could be due to policies, roles,
reason specific to a conferencing system and its configuration. specific privileges, etc., with the reason specific to a conferencing
system and its configuration.
In the case of a userRequest with a "delete" operation, the In the case of a userRequest with an <operation> parameter of
"confObjID" representing the XCON-URI of the target conference MUST "delete", the <confObjID> representing the XCON-URI of the target
be included. The "confUserID", containing the CCMP client's xcon- conference MUST be included. The <confUserID> parameter, containing
userid, MUST be included in the userRequest message. If the client the CCMP client's XCON-USERID, MUST be included in the userRequest
wants to exit the specified conference, no "userInfo" parameter is message. If the client wants to exit the specified conference, no
needed in the delete request. On the other hand, if the client wants <userInfo> parameter is needed in the delete request. On the other
to remove another participant from the given conference, she MUST hand, if the client wants to remove another participant from the
include in the userRequest/delete a "userInfo" parameter whose given conference, she MUST include in the userRequest/delete a
"entity" attribute conveys the xcon-userid of that participant. The <userInfo> parameter whose 'entity' attribute conveys the XCON-USERID
userResponse MUST contain the same "confObjID" that was included in of that participant. The userResponse MUST contain the same value
the userRequest. The userResponse MUST contain a "response-code" of for the <confObjID> parameter that was included in the <confObjID>
"200" if the target <user> element has been successfully deleted. If parameter in the userRequest. The userResponse MUST contain a
the userResponse for the "delete" operation contains a "response- <response-code> of "200" if the target <user> element has been
code" of "200", the userResponse MUST NOT contain the "userInfo" successfully deleted. If the userResponse for the delete operation
parameter. contains a <response-code> of "200", the userResponse MUST NOT
contain the <userInfo> parameter.
<!-- userRequest --> <!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 35, line 39 skipping to change at page 37, line 4
<xs:complexType name="ccmp-user-response-message-type"> <xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userResponse" /> <xs:element ref="userResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponseType --> <!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type <xs:element name="userInfo" type="info:user-type"
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
5.3.7. sidebarsByValRequest and sidebarsByValResponse 5.3.7. sidebarsByValRequest and sidebarsByValResponse
A "sidebarsByValRequest" is used to execute a retrieve-only operation A sidebarsByValRequest message is used to execute a retrieve-only
on the <sidebars-by-val> field of the conference object represented operation on the <sidebars-by-val> field of the conference object
by the "confObjID". The "sidebarsByValRequest" message is of a represented by the <confObjID>. The sidebarsByValRequest message is
"retrieve-only" type, so an "operation" parameter MUST NOT be of a 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, CCMP allows for the use of xpath filters whenever a
filters whenever a selected subset of the sidebars available at the selected subset of the sidebars available at the server's side has to
server's side has to be retrieved by the client. This applies both be retrieved by the client. This applies both to sidebars by
to sidebars by reference and to sidebars by value. A reference and sidebars by value. A sidebarsByValResponse message
"sidebarsByValResponse" with a "response-code" of "200" MUST contain with a <response-code> of "200" MUST contain a <sidebarsByValInfo>
a "sidebarsByValInfo" parameter containing the desired <sidebars-by- parameter containing the desired <sidebars-by-val> element. A
val> element. A "sidebarsByValResponse" message MUST carry back to sidebarsByValResponse message MUST return to the client a <version>
the client a "version" element related to the current version of the element related to the current version of the main conference object
main conference object (i.e. the one whose identifier is contained in (i.e., the one whose identifier is contained in the <confObjID> field
the "confObjId" field of the request) to which the sidebars in of the request) with which the sidebars in question are associated.
question are associated. The "sidebarsByValInfo" parameter contains The <sidebarsByValInfo> parameter contains the list of the conference
the list of the conference objects associated with the sidebars by objects associated with the sidebars by value derived from the main
value derived from the main conference. The retrieved sidebars can conference. The retrieved sidebars can then be updated or deleted
then be updated or deleted using the "sidebarByValRequest" message, using the sidebarByValRequest message, which is described in
which is described in Section 5.3.8. 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 37, line 39 skipping to change at page 39, line 20
<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
5.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 distinguishes 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"
parameter is included, as envisaged in the XCON framework parameter is included, the sidebar is created by cloning the main
([RFC5239]), the sidebar is created by cloning the main conference, conference, as envisioned in the XCON framework [RFC5239] following
following the implementation specific cloning rules. Otherwise, the implementation specific cloning rules. Otherwise, similar to the
similarly to the case of direct creation, the sidebar conference case of direct creation, the sidebar conference object is built on
object is built on the basis of the "sidebarByValInfo" parameter the basis of the "sidebarByValInfo" parameter provided by the
provided by the requestor. As a consequence of a sidebar-by-val requestor. As a consequence of a sidebar-by-val creation, the
creation, the conference server MUST update the main conference conference server MUST update the main conference object reflected by
object reflected by the "confObjID" parameter in the the <confObjID> parameter in the sidebarbyValRequest/create message
sidebarbyValRequest/create message introducing the new sidebar object introducing the new sidebar object as a new <entry> in the proper
as a new new <entry> in the proper section <sidebars-by-val>. The section <sidebars-by-val>. The newly created sidebar conference
newly created sidebar conference object MAY be included in the object MAY be included in the sidebarByValResponse in the
sidebarByValResponse in the "sidebarByValInfo" parameter, if the <sidebarByValInfo> parameter, if the <response-code> is "200". The
"response-code" is "200". The XCON-URI of the newly created sidebar XCON-URI of the newly created sidebar MUST appear in the <confObjID>
MUST appear in the "confObjID" parameter of the response. The parameter of the response. The conference server can notify any
conference server can notify any conferencing clients that have conferencing clients that have subscribed to the conference event
subscribed to the conference event package, and are authorized to package and that are authorized to receive the notification of the
receive the notifications, of the addition of the sidebar to 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 sidebarByValRequest message with an <operation>
"retrieve", the URI for the conference object created for the sidebar parameter of "retrieve", the URI for the conference object created
(received in the response to a "create" operation or in a for the sidebar (received in 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
the conference server in the same manner as a "retrieve" operation conference server in the same manner as in the case of an <operation>
included in a confRequest message as detailed in Section 5.3.4. parameter of "retrieve" included in a confRequest message, as
described in Section 5.3.4.
In the case of a "sidebarByVal" request with an operation of In the case of a sidebarByValRequest message with an <operation>
"update", the "sidebarByValInfo" MUST also be included in the parameter of "update", the <sidebarByValInfo> MUST also be included
request. The "confObjID" parameter contained in the request message in the request. The <confObjID> parameter contained in the request
identifies the specific sidebar instance to be updated. An "update" message identifies the specific sidebar instance to be updated. An
operation on the "sidebarByValInfo" is handled by the conference update operation on the specific sidebar instance contained in the
server in the same manner as an "update" operation on the confInfo <sidebarByValInfo> parameter is handled by the conference server in
included in a confRequest message as detailed in Section 5.3.4. A the same manner as an update operation on the conference instance as
"sidebarByValResponse" message MUST carry back to the client a reflected by the <confInfo> parameter included in a confRequest
"version" element related to the current version of the sidebar whose message as detailed in Section 5.3.4. A sidebarByValResponse message
identifier is contained in the "confObjId" field of the request. MUST return to the client a <version> element related to the current
version of the sidebar whose identifier is contained in the
<confObjID> field of the request.
If an "operation" of "delete" is included in the sidebarByVal If an <operation> parameter of "delete" is included in the
request, the "sidebarByValInfo" parameter MUST NOT be included in the sidebarByVal request, the <sidebarByValInfo> parameter MUST NOT be
request. Any "sidebarByValInfo" included in the request MUST be included in the request. Any <sidebarByValInfo> included in the
ignored by the conference server. The URI for the conference object request MUST be ignored by the conference server. The URI for the
associated with the sidebar MUST be included in the "confObjID" conference object associated with the sidebar MUST be included in the
parameter in the request. If the specific conferencing user as <confObjID> parameter in the request. If the specific conferencing
reflected by the "confUserID" in the request is authorized to delete user, as reflected by the <confUserID> parameter, in the request is
the conference, the conference server deletes the conference object authorized to delete the conference, the conference server deletes
reflected by the "confObjID" parameter and updates the data in the the conference object reflected by the <confObjID> parameter and
conference object from which the sidebar was cloned. The conference updates the data in the conference object from which the sidebar was
server can notify any conferencing clients that have subscribed to cloned. The conference server can notify any conferencing clients
the conference event package, and are authorized to receive the that have subscribed to the conference event package and that are
notifications, of the deletion of the sidebar to the conference. authorized to receive the notification of the deletion of the sidebar
from the conference.
If a sidebarByValRequest with an "operation" of "retrieve", "update" If a sidebarByValRequest with an <operation> parameter of "retrieve",
or "delete" carries a "confObjID" which is not associated with any "update", or "delete" carries a <confObjID> parameter which is not
existing sidebar-by-val, a confResponse message containing a "404" associated with any existing sidebar-by-val, a confResponse message
error code will be generated on the server's side. This holds also containing a <response-code> of "404" will be generated on the
for the case in which the mentioned "confObjID" is related to an server's side. This also holds for the case in which the mentioned
existing conference object stored at the server, but associated with <confObjID> parameter is related to an existing conference object
a blueprint or with an actual conference or with a sidebar-by-ref stored at the server, but associated with a blueprint or with an
rather than a sidebar-by-val. actual conference or with a sidebar-by-ref rather than a sidebar-by-
val.
<!-- sidebarByValRequest --> <!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type"> <xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValRequest"/> <xs:element ref="sidebarByValRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 40, line 4 skipping to change at page 41, line 33
<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>
<!-- sidebarByValResponse --> <!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValResponse"/> <xs:element ref="sidebarByValResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponseType --> <!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse" <xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" /> type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type 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
5.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
"sidebarsByRefRequest" message. In the case of a "response-code" of message. In the case of a <response-code> of "200", the
"200", the "sidebarsByRefInfo" parameter, containing the <sidebars- <sidebarsByRefInfo> parameter, containing the <sidebars-by-ref>
by-ref> element of the conference object, MUST be included in the element of the conference object, MUST be included in the response.
response. The <sidebars-by-ref> element represents the set of URIs The <sidebars-by-ref> element represents the set of URIs of the
of the sidebars associated with the main conference, whose sidebars associated with the main conference, whose description (in
description (in the form of a standard XCON conference document) is the form of a standard XCON conference document) is external to the
external to the main conference itself. Through the retrieved URIs, main conference itself. Through the retrieved URIs, it is then
it is then possible to access single sidebars using the possible to access single sidebars using the sidebarByRefRequest
"sidebarByRef" request message, described in Section 5.3.10. A message, described in Section 5.3.10. A sidebarsByRefResponse
"sidebarsByRefResponse" message MUST carry back to the client a message MUST carry back to the client a <version> element related to
"version" element related to the current version of the main the current version of the main conference object (i.e., the one
conference object (i.e. the one whose identifier is contained in the whose identifier is contained in the <confObjId> field of the
"confObjId" field of the request) to which the sidebars in question request) with 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>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefRequest"/> <xs:element ref="sidebarsByRefRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 42, line 16 skipping to change at page 44, line 19
<xs:complexType name="sidebarsByRefResponseType"> <xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo"
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
sidebarsByRefResponse messages and sidebarsByRefResponse Messages
5.3.10. sidebarByRefRequest and sidebarByRefResponse 5.3.10. sidebarByRefRequest and sidebarByRefResponse
A sidebarByRefRequest message MUST contain the "operation" parameter A sidebarByValResponse message MUST return to the client a <version>
which discriminates among retrieval, creation, modification and element related to the current version of the sidebar whose
deletion of a specific sidebar. The other required parameters depend identifier is contained in the <confObjID> field of the request.
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
be included in the sidebyRefRequest message. In this case, the 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>
parameter is included, as envisaged in the XCON framework parameter is included, following the XCON framework [RFC5239], the
([RFC5239]), the sidebar is created by cloning the main conference, sidebar is created by cloning the main conference, observing the
following the implementation specific cloning rules. Otherwise, implementation-specific cloning rules. Otherwise, similar to the
similarly to the case of direct creation, the sidebar conference case of direct creation, the sidebar conference object is built on
object is built on the basis of the "sidebarByRefInfo" parameter the basis of the <sidebarByRefInfo> parameter provided by the
provided by the requestor. If the creation of the sidebar is requestor. If the creation of the sidebar is successful, the
successful, the conference server MUST update the "sidebars-by-ref" conference server MUST update the <sidebars-by-ref> element in the
element in the conference object from which the sidebar was created conference object from which the sidebar was created (i.e., as
(i.e., as identified by the "confObjID" in the original sidebarByRef identified by the <confObjID> in the original sidebarByRefRequest),
request), with the URI of the newly created sidebar. The newly with the URI of the newly created sidebar. The newly created
created conference object MAY be included in the response in the conference object MAY be included in the response in the
"sidebarByRefInfo" parameter with a "response-code" of "200". The <sidebarByRefInfo> parameter with a <response-code> of "200". 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 that are
authorized to receive the notifications, of the addition of the authorized to receive the notification of the addition of the sidebar
sidebar to the conference. to the conference.
In the case of a "sidebarByRef" request with an operation of In the case of a sidebarByRefRequest message with an <operation>
"retrieve", the URI for the conference object created for the sidebar parameter of "retrieve", the URI for the conference object created
MUST be included in the "confObjID" parameter in the request. A for the sidebar MUST be included in the <confObjID> parameter in the
"retrieve" operation on the "sidebarByRefInfo" is handled by the request. A retrieve operation on the <sidebarByRefInfo> is handled
conference server in the same manner as a "retrieve" operation on the by the conference server in the same manner as a retrieve operation
confInfo included in a confRequest message as detailed in on the confInfo included in a confRequest message as detailed in
Section 5.3.4. Section 5.3.4.
In the case of a "sidebarByRef" request with an operation of In the case of a sidebarByRefRequest message with an <operation>
"update", the URI for the conference object created for the sidebar parameter of "update", the URI for the conference object created for
MUST be included in the "confObjID" parameter in the request. The the sidebar MUST be included in the <confObjID> parameter in the
"sidebarByRefInfo" MUST also be included in the request in the case request. The <sidebarByRefInfo> MUST also be included in the request
of an "operation" of "update". An "update" operation on the in the case of an "update" operation. 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 5.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> parameter of "delete" is included in the
request, the "sidebarByRefInfo" parameter MUST NOT be included in the sidebarByRefRequest, the <sidebarByRefInfo> parameter MUST NOT be
request. Any "sidebarByRefInfo" included in the request MUST be included in the request. Any <sidebarByRefInfo> included in the
ignored by the conference server. The URI for the conference object request MUST be ignored by the conference server. The URI for the
for the sidebar MUST be included in the "confObjID" parameter in the conference object for the sidebar MUST be included in the <confObjID>
request. If the specific conferencing user as reflected by the parameter in the request. If the specific conferencing user as
"confUserID" in the request is authorized to delete the conference, reflected by the <confUserID> parameter in the request is authorized
the conference server SHOULD delete the conference object reflected to delete the conference, the conference server SHOULD delete the
by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" conference object reflected by the <confObjID> parameter and SHOULD
element in the conference object from which the sidebar was update the <sidebars-by-ref> element in the conference object from
originally cloned. The conference server can notify any conferencing which the sidebar was originally cloned. The conference server can
clients that have subscribed to the conference event package, and are notify any conferencing clients that have subscribed to the
authorized to receive the notifications, of the deletion of the conference event package and that are authorized to receive the
sidebar. notification of the deletion of the sidebar.
If a sidebarByRefRequest with an "operation" of "retrieve", "update" If a sidebarByRefRequest with an <operation> parameter of "retrieve",
or "delete" carries a "confObjID" which is not associated with any "update", or "delete" carries a <confObjID> parameter that is not
existing sidebar-by-ref, a confResponse message containing a "404" associated with any existing sidebar-by-ref, a confResponse message
error code will be generated on the server's side. This holds also containing a <response-code> of "404" will be generated on the
for the case in which the mentioned "confObjID" is related to an server's side. This also holds for the case in which the value of
existing conference object stored at the server, but associated with the mentioned <confObjID> parameter is related to an existing
a blueprint or with an actual conference or with a sidebar-by-val conference object stored at the server, but associated with a
blueprint or with an actual conference or with a sidebar-by-val
rather than a sidebar-by-ref. 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>
skipping to change at page 45, line 4 skipping to change at page 47, line 17
type="sidebarByRefResponseType" /> type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" 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
sidebarByRefResponse messages and sidebarByRefResponse Messages
5.3.11. extendedRequest and extendedResponse 5.3.11. extendedRequest and extendedResponse
In order to facilitate the possibility of specifying new request/ In order to allow specifying new request and response pairs for
response pairs for conference control, CCMP makes available the conference control, CCMP defines the extendedRequest and
"extendedRequest" and "extendedResponse" messages. Such messages extendedResponse messages. Such messages constitute a CCMP skeleton
constitute a CCMP skeleton in which implementors can transport the in which implementers can transport the information needed to realize
information needed to realize conference control mechanisms not conference control mechanisms not explicitly envisioned in the CCMP
explicitly envisioned in the CCMP specification; these mechanisms are specification; these mechanisms are called, in this context,
called, in this context, "extensions". Each extension is assumed to "extensions". Each extension is assumed to be characterized by an
be characterized by an appropriate name that MUST be carried in the appropriate name that MUST be carried in the extendedRequest/
extendedRequest/extendedResponse pair in the provided <extensionName> extendedResponse pair in the provided <extensionName> field.
field. Extension-specific information can be transported in the form Extension-specific information can be transported in the form of
of schema-defined XML elements inside the <any> element present in schema-defined XML elements inside the <any> element present in both
both extendedRequest and extendedResponse. extendedRequest and extendedResponse.
The conferencing client SHOULD be able to be informed about the The conferencing client SHOULD be able to determine the extensions
extensions supported by a CCMP server and to recover the XML Schema supported by a CCMP server and to recover the XML schema defining the
defining the related specific elements by means of an optionsRequest/ related specific elements by means of an optionsRequest/
optionsResponse CCMP transaction (see Section 5.3.12). optionsResponse CCMP transaction (see Section 5.3.12).
The meaning of the common CCMP parameters inherited by the The meaning of the common CCMP parameters inherited by the
extendedRequest and extendedResponse from the basic CCMP request and extendedRequest and extendedResponse from the basic CCMP request and
response messages SHOULD be preserved and exploited appropriately response messages SHOULD be preserved and exploited appropriately
while defining an extension. while defining an extension.
<!-- extendedRequest --> <!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type"> <xs:complexType name="ccmp-extended-request-message-type">
skipping to change at page 46, line 41 skipping to change at page 49, line 19
<xs:sequence> <xs:sequence>
<xs:element name="extensionName" <xs:element name="extensionName"
type="xs:string" type="xs:string"
minOccurs="1"/> minOccurs="1"/>
<xs:any namespace="##other" <xs:any namespace="##other"
processContents="lax" processContents="lax"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 17: Structure of the extendedRequest and extendedResponse Figure 17: Structure of the extendedRequest and
messages extendedResponse Messages
5.3.12. optionsRequest and optionsResponse 5.3.12. optionsRequest and optionsResponse
The "optionsRequest" (Figure 18) message is used to retrieve general The optionsRequest message (Figure 18) retrieves general information
information about conference server capabilities. These capabilities about conference server capabilities. These capabilities include the
include the standard CCMP messages (request/response pairs) and standard CCMP messages (request/response pairs) and potential
potential extension messages supported by the conference server. As extension messages supported by the conference server. As such, it
such it is a basic CCMP message, rather than a specialization of the is a basic CCMP message, rather than a specialization of the general
general CCMP request. CCMP request.
The "optionsResponse" returns, in the appropriate <options> field, a The optionsResponse returns, in the appropriate <options> field, a
list of the supported CCMP message pairs as defined in this list of the supported CCMP message pairs as defined in this
specification. These messages are in the form of a list, <standard- specification. These messages are in the form of a list: <standard-
message-list> including each of the supported messages as reflected message-list> including each of the supported messages as reflected
by <standard-message> elements. The "optionsResponse" message also by <standard-message> elements. The optionsResponse message also
allows for an <extended-message-list>, which is a list of additional allows for an <extended-message-list>, which is a list of additional
message types in the form of <extended-message-list> elements that message types in the form of <extended-message-list> elements that
are currently undefined, to allow for future extensibility. The are currently undefined, to allow for future extensibility. The
following information is provided for both types of messages: following information is provided for both types of messages:
o <name> (REQUIRED): in case of standard messages, it can be one of o <name> (REQUIRED): in case of standard messages, it can be one of
the ten standard message names defined in this document (i.e. the 10 standard message names defined in this document (i.e.,
"blueprintsRequest", "confsRequest", etc.). In case of "blueprintsRequest", "confsRequest", etc.). In case of
extensions, this element MUST carry the same value of the extensions, this element MUST carry the same value of the
<extension-name> inserted in the corresponding extendedRequest/ <extension-name> inserted in the corresponding extendedRequest/
extendedResponse message pair extendedResponse message pair.
o <operations> (OPTIONAL): this field is a list of <operation> o <operations> (OPTIONAL): this field is a list of <operation>
entries, each representing the CRUD operation supported by the entries, each representing the Create, Read, Update, Delete (CRUD)
server for the message. If this element is absent, the client operation supported by the server for the message. If this
SHOULD assume the server is able to handle the entire set of CRUD element is absent, the client SHOULD assume the server is able to
operations or, in case of standard messages, all the operations handle the entire set of CRUD operations or, in case of standard
envisioned for that message in this document. messages, all the operations envisioned for that message in this
document.
o <schema-ref> (OPTIONAL): since all CCMP messages can potentially o <schema-ref> (OPTIONAL): since all CCMP messages can potentially
contain XML elements not envisioned in the CCMP schema (due to the contain XML elements not envisioned in the CCMP schema (due to the
presence of <any> elements and attributes), a reference to a presence of <any> elements and attributes), a reference to a
proper schema definition specifying such new elements/attributes proper schema definition specifying such new elements/attributes
can also be sent back to the clients by means of such field. If can also be sent back to the clients by means of such field. If
this element is absent, no new elements are introduced in the this element is absent, no new elements are introduced in the
messages further than those explicitly defined in the CCMP messages other than those explicitly defined in the CCMP
specification. specification.
o <description> (OPTIONAL): human readable information about the o <description> (OPTIONAL): human-readable information about the
related message related message.
The only parameter needed in the optionsRequest is the sender The only parameter needed in the optionsRequest is the sender
confUserID, which is mirrored in the homologous parameter of the confUserID, which is mirrored in the same parameter of the
corresponding optionsResponse. corresponding optionsResponse.
The CCMP server MUST include the <standard-message-list> containing The CCMP server MUST include the <standard-message-list> containing
at least one <operation> element in the optionsResponse, since a CCMP at least one <operation> element in the optionsResponse, since a CCMP
server is REQUIRED to be able to handle both the request and response server is REQUIRED to be able to handle both the request and response
messages for at least one of the operations. messages for at least one of the operations.
<!-- optionsRequest --> <!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type"> <xs:complexType name="ccmp-options-request-message-type">
skipping to change at page 50, line 19 skipping to change at page 53, line 14
<!-- operations-type --> <!-- operations-type -->
<xs:complexType name="operations-type"> <xs:complexType name="operations-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType" <xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/> minOccurs="1" maxOccurs="4"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 18: Structure of the optionsRequest and optionsResponse Figure 18: Structure of the optionsRequest and
messages optionsResponse Messages
5.4. CCMP Response Codes 5.4. CCMP Response Codes
All CCMP response messages MUST include a "response-code". This All CCMP response messages MUST include a <response-code>. This
document defines an IANA registry for the CCMP response codes as document defines an IANA registry for the CCMP response codes, as
described in Section 12.5.2. The following summarizes the CCMP described in Section 12.5.2. The following summarizes the CCMP
response codes: response codes:
200 Success: Successful completion of the requested operation. 200 Success:
400 Bad Request: Syntactically malformed request. Successful completion of the requested operation.
401 Unauthorized: User not allowed to perform the required 400 Bad Request:
operation.
403 Forbidden: Operation not allowed (e.g., cancellation of a Syntactically malformed request.
blueprint).
404 Object Not Found: Target conference object missing at the server 401 Unauthorized:
(it refers to the "confObjID" parameter in the generic request
message)
409 Conflict: A generic error associated with all those situations User not allowed to perform the required operation.
in which a requested client operation cannot be successfully
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 403 Forbidden:
to the XCON-USERID in the "entity" attribute of the "userInfo"
parameter when it is included in userRequests)
421 Invalid confUserID: User missing at the server (this code is Operation not allowed (e.g., cancellation of a blueprint).
returned in the case of requests in which the "confUserID" of the
sender is invalid).
422 Invalid Conference Password: Target conference object's password 404 Object Not Found:
contained in the request is wrong.
423 Conference Password Required: "conference-password" missing in a The target conference object does not exist at the server (The
request to access a password-protected conference object. object in the error message refers to the <confObjID> parameter in
the generic request message).
424 Authentication Required: User's authentication information is 409 Conflict:
missing or invalid.
425 Forbidden Delete Parent: Cancel operation failed since the A generic error associated with all those situations in which a
target object is a parent of child objects which depend on it, or requested client operation cannot be successfully completed by the
because it effects, based on the "parent-enforceable" mechanism, server. An example of such a situation is when the modification
the corresponding element in a child object. 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.
426 Forbidden Change Protected: Update refused by the server because 420 User Not Found:
the target element cannot be modified due to its implicit
dependence on the value of a parent object ("parent-enforceable"
mechanism).
427 Invalid Domain Name: The domain name in an AUTO_GENERATE_X Target user missing at the server (it is related to the XCON-
instance in the conference object is not within the CCMP server's USERID in the 'entity' attribute of the <userInfo> parameter when
domain of responsibility. it is included in userRequests).
500 Server Internal Error: The server cannot complete the required 421 Invalid confUserID:
service due to a system internal error.
501 Not Implemented: Operation envisaged in the protocol, but not User does not exist at the server (This code is returned for
implemented in the contacted server. requests where the <confUserID> parameter is invalid).
510 Request Timeout: The time required to serve the request has 422 Invalid Conference Password:
exceeded the envisaged service threshold.
511 Resources Not Available: This code is used when the CCMP server The password for the target conference object contained in the
cannot execute a command because of resource issues, e.g. it request is wrong.
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.
The handling of a "response-code" of "404", "409", "420", "421", 423 Conference Password Required:
"425", "426" and "427" are only applicable to specific operations for
"conference-password" missing in a request to access a password-
protected conference object.
424 Authentication Required:
User's authentication information is missing or invalid.
425 Forbidden Delete Parent:
Cancel operation failed since the target object is a parent of
child objects that depend on it, or because it affects, based on
the "parent-enforceable" mechanism, the corresponding element in a
child object.
426 Forbidden Change Protected:
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).
427 Invalid Domain Name:
The domain name in an AUTO_GENERATE_X instance in the conference
object is not within the CCMP server's domain of responsibility.
500 Server Internal Error:
The server cannot complete the required service due to a system
internal error.
501 Not Implemented:
Operation defined by the protocol, but not implemented by this
server.
510 Request Timeout:
The time required to serve the request has exceeded the configured
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.
The handling of a <response-code> of "404", "409", "420", "421",
"425", "426", or "427" is only applicable to specific operations for
specialized message responses and the details are provided in specialized message responses and the details are provided in
Section 5.3. The following table summarizes these response codes and Section 5.3. The following table summarizes these response codes and
the specialized message and operation to which they are applicable: the specialized message and operation to which they are applicable:
+----------+-------------+--------------+-------------+-------------+ +----------+-------------+--------------+-------------+-------------+
| Response | Create | Retrieve | Update | Delete | | Response | Create | Retrieve | Update | Delete |
| code | | | | | | code | | | | |
+----------+-------------+--------------+-------------+-------------+ +----------+-------------+--------------+-------------+-------------+
| 404 | userRequest | All retrieve | All update | All delete | | 404 | userRequest | All retrieve | All update | All delete |
| | sidebarBy | requests | requests | requests | | | sidebarBy | requests | requests | requests |
| | ValRequest, | EXCEPT: | | | | | ValRequest, | EXCEPT: | | |
| | sidebarsBy | blueprints | | | | | sidebarsBy | blueprints | | |
| | RefRequest | Request, | | | | | RefRequest | Request, | | |
| | | confsRequest | | | | | | confsRequest | | |
| -------- | ----------- | ------------ | ----------- | ----------- | | -------- | ----------- | ------------ | ----------- | ----------- |
| | - | | | |
| 409 | N/A | N/A | All update | N/A | | 409 | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 420 | userRequest | userRequest | userRequest | userRequest | | 420 | userRequest | userRequest | userRequest | userRequest |
| | (3rd party | | | | | | (third- | | | |
| | party | | | |
| | invite with | | | | | | invite with | | | |
| | third user | | | | | | third-user | | | |
| | entity) (*) | | | | | | entity) (*) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 421 | All create | All retrieve | All update | All delete | | 421 | All create | All retrieve | All update | All delete |
| | requests | requests | requests | requests | | | requests | requests | requests | requests |
| | EXCEPT: | | | | | | EXCEPT: | | | |
| | userRequest | | | | | | userRequest | | | |
| | with no | | | | | | with no | | | |
| | confUserID | | | | | | confUserID | | | |
| | (**) | | | | | | (**) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 425 | N/A | N/A | N/A | All delete | | 425 | N/A | N/A | N/A | All delete |
| | | | | request | | | | | | request |
| -------- | ----------- | ----------- | ----------- | ----------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 426 | N/A | N/A | All update | N/A | | 426 | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 427 | ConfRequest | N/A | All update | N/A | | 427 | ConfRequest | N/A | All update | N/A |
| | UserRequest | | requests | | | | UserRequest | | requests | |
+----------+-------------+--------------+-------------+-------------+ +----------+-------------+--------------+-------------+-------------+
Table 2: Response codes and associated operations
(*) "420" in answer to a "userRequest/create" operation: in the case Table 2: Response Codes and Associated Operations
(*) "420" in answer to a "userRequest/create" operation: In 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> parameter of the sender of the request
invalid, a "421" error code is returned to the client. that is invalid, a <response-code> of "421" is returned to the
client.
(**) "421" is not sent in answers to "userRequest/create" messages (**) "421" is not sent in answer to userRequest/create messages
having a "null" confUserID, since this case is associated with a user having a "null" confUserID, since this case is associated with a user
who is unaware of his own XCON-USERID, but wants to enter a known who is unaware of his own XCON-USERID, but wants to enter a known
conference. conference.
In the case of a response code of "510", a conferencing client MAY In the case of a <response-code> of "510", a conferencing client MAY
re-attempt the request within a period of time that would be specific re-attempt the request within a period of time that would be specific
to a conference control client or conference control server. to a conferencing client or conference server.
A response code of "400" indicates that the conference control client A <response-code> of "400" indicates that the conferencing client
sent a malformed request, which is indicative of an error in the sent a malformed request, which is indicative of an error in the
conference control client or in the conference control server. The conferencing client or in the conference server. The handling is
handling is specific to the conference control client implementation specific to the conferencing client implementation (e.g., generate a
(e.g., generate a log, display an error message, etc.). It is NOT log, display an error message, etc.). It is NOT RECOMMENDED that the
RECOMMENDED that the client re-attempt the request in this case. client re-attempt the request in this case.
Response codes such as "401" and "403" indicate the client does not A <response-code> of "401" or "403" indicates the client does not
have the appropriate permissions, or there is an error in the have the appropriate permissions, or there is an error in the
permissions: re-attempting the request would likely not succeed and permissions: re-attempting the request would likely not 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 "500" "response-code", the handling of client in the same manner as a <response-code> of "500", the handling
which is specific to the conference control client implementation. of which is specific to the conferencing client implementation.
6. A complete example of the CCMP in action 6. A Complete Example of CCMP in Action
In this section a typical, not normative, scenario in which the CCMP In this section a typical, non-normative, scenario in which CCMP
comes into play is described, by showing the actual composition of comes into play is described, by showing the actual composition of
the various CCMP messages. In the call flows of the example, the the various CCMP messages. In the call flows of the example, the
Conference Control Client is a CCMP-enabled client, whereas the conferencing client is a CCMP-enabled client, and the conference
Conference Control Server is a CCMP-enabled server. The "confUserID" server is a CCMP-enabled server. The XCON-USERID of the client,
of the client, Alice, is "xcon-userid:alice@example.com" and appears Alice, is "xcon-userid:alice@example.com" and it appears in the
in all requests. The sequence of operations is as follows: <confUserID> parameter in all requests. The sequence of operations
is as follows:
1. Alice retrieves from the server the list of available blueprints 1. Alice retrieves the list of available blueprints from the server
(Section 6.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 6.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 6.3); blueprint (Section 6.3);
4. Alice modifies information (e.g. XCON-URI, name, description) 4. Alice modifies information (e.g., XCON-URI, name, and
associated with the newly created blueprint (Section 6.4); description) 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 6.5); conference is activated (Section 6.5);
6. Alice joins the conference (Section 6.6); 6. Alice joins the conference (Section 6.6);
7. Alice lets a new user, Ciccio, (whose "confUserID" is 7. Alice lets a new user, Ciccio, (whose XCON-USERID is
"xcon-userid:Ciccio@example.com") join the conference "xcon-userid:Ciccio@example.com") join the conference
(Section 6.7). (Section 6.7).
8. Alice asks for the CCMP server capabilities (Section 6.8); 8. Alice asks for the CCMP server capabilities (Section 6.8);
9. Alice exploits an extension of the CCMP server (Section 6.9). 9. Alice exploits an extension of the CCMP server (Section 6.9).
Note, the examples do not include any details beyond the basic Note that 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 aforementioned
actions separately. actions separately.
6.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 shown in the figure,
the figure, the "blueprintsResponse" message contains, in the the blueprintsResponse message contains, in the <blueprintsInfo>
"blueprintsInfo" parameter, information about the available parameter, information about the available blueprints, in the form of
blueprints, in the form of the standard XCON-URI of the blueprint, the standard XCON-URI of the blueprint, plus additional (and
plus additional (and optional) information, like its display-text and optional) information, like its display-text and purpose.
purpose.
Alice retrieves from the server the list of available blueprints: Alice retrieves from the server the list of available blueprints:
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 | | CCMP blueprintsResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: (null) | | - confObjID: (null) |
| - response-code: 200 | | - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. | | - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintsRequest message: 1. blueprintsRequest message:
skipping to change at page 56, line 35 skipping to change at page 60, line 22
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri> <info:uri>xcon:VideoConference1@example.com</info:uri>
<info:display-text>VideoConference1</info:display-text> <info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference <info:purpose>Public Video Conference: conference
where both audio and video are available, where both audio and video are available,
only one user can talk only one user can talk.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:AudioConference2@example.com</info:uri> <info:uri>xcon:AudioConference2@example.com</info:uri>
<info:display-text>AudioConference2</info:display-text> <info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference: <info:purpose>Basic Audio Conference:
conference with private access, conference with private access,
where only audio is available, where only audio is available,
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
skipping to change at page 57, line 4 skipping to change at page 60, line 39
conference with private access, conference with private access,
where only audio is available, where only audio is available,
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
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 19: Getting blueprints from the server Figure 19: Getting Blueprints from the Server
6.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
one of them (the one called with XCON-URI of them (the one called with XCON-URI "xcon:AudioRoom@example.com").
"xcon:AudioRoom@example.com"). The picture shows such transaction. The picture shows such a transaction. Notice that the response
Notice that the response contains, in the "blueprintInfo" parameter, contains, in the <blueprintInfo> parameter, a document compliant with
a document compliant with the standard XCON data model. the standard XCON data model.
Alice retrieves detailed information about a specified blueprint: Alice retrieves detailed information about a specified blueprint:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP blueprintRequest message | | CCMP blueprintRequest message |
| - 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: 200 | | - 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
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type"> xsi:type="ccmp:ccmp-blueprint-request-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:blueprintRequest/> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintResponse message from the server: 2. blueprintResponse message from 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: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>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<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:available-media> <info:available-media>
<info:entry label="audioLabel"> <info:entry label="audioLabel">
<info:display-text>audio stream</info:display-text> <info:display-text>audio stream</info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</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> <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioFloor"> <xcon:floor id="audioFloor">
<xcon:media-label>audioLabel</xcon:media-label> <xcon:media-label>audioLabel</xcon:media-label>
</xcon:floor> </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 20: Getting info about a specific blueprint Figure 20: Getting Information about a Specific Blueprint
6.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.
message. This is achieved by sending a "confRequest/create" message This is achieved by sending a confRequest/create message having the
having the blueprint's URI in the "confObjID" parameter. The picture blueprint's URI in the <confObjID> parameter. The picture shows such
shows such transaction. Notice that the response contains, in the a transaction. Notice that the response contains, in the <confInfo>
"confInfo" parameter, the document associated with the newly created parameter, the document associated with the newly created conference,
conference, which is compliant with the standard XCON data model. which is compliant with the standard XCON data model. The
The "confObjID" in the response is set to the XCON-URI of the new <confObjID> parameter in the response is set to the XCON-URI of the
conference (in this case, "xcon:8977794@example.com"). We also new conference (in this case, "xcon:8977794@example.com"). We also
notice that this value is equal to the value of the "entity" notice that this value is equal to the value of the 'entity'
attribute of the <conference-info> element of the document attribute of the <conference-info> element of the document
representing the newly created conference object. representing the newly created conference object.
Alice creates a new conference by cloning the Alice creates a new conference by cloning the
"xcon:AudioRoom@example.com" blueprint: "xcon:AudioRoom@example.com" blueprint:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP confRequest message | | CCMP confRequest message |
| - confUserID: Alice | | - confUserID: Alice |
skipping to change at page 61, line 4 skipping to change at page 64, line 31
<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:available-media> <info:available-media>
<info:entry label="333"> <info:entry label="333">
<info:display-text>audio stream</info:display-text> <info:display-text>audio stream</info:display-text>
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</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> <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:media-label>333</xcon:media-label> <xcon:media-label>333</xcon:media-label>
</xcon:floor> </xcon:floor>
</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 21: Creating a new conference by cloning a blueprint Figure 21: Creating a New Conference by Cloning a Blueprint
6.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 "200", 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
| | | |
skipping to change at page 63, line 15 skipping to change at page 66, line 37
<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>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<version>2</version> <version>2</version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Updating conference information Figure 22: Updating Conference Information
6.5. Alice inserts a list of users in the conference object 6.5. Alice Inserts a List of Users into 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 achieve
purpose, she exploits the "usersRequest" message provided by the this, she makes use of the usersRequest message provided by CCMP.
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:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP usersRequest message | | CCMP usersRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
skipping to change at page 65, line 4 skipping to change at page 68, line 22
xsi:type="ccmp:ccmp-users-response-message-type"> xsi:type="ccmp:ccmp-users-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>retrieve</operation> <operation>retrieve</operation>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<version>3</version> <version>3</version>
<ccmp:usersResponse/> <ccmp:usersResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 23: Updating the list of allowed users for the conference
'xcon:8977794@example.com'
6.6. Alice joins the conference Figure 23: Updating the List of Allowed Users for the
Conference 'xcon:8977794@example.com'
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 CCMP to add herself to the newly created conference. This
This is achieved through a "userRequest/create" message containing, is achieved through a userRequest/create message containing, in the
in the "userInfo" parameter, a <user> element compliant with the XCON <userInfo> parameter, a <user> element compliant with the XCON data
data model representation. Notice that such element includes model representation. Notice that such an element includes
information about the user's Address of Records, as well as her information about the user's Addresses of Record, as well as her
current end-point. The picture below shows the transaction. Notice current endpoint. 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
the client is a first-party one. the client is a first-party one.
Alice joins the conference by issuing a "userRequest/create" message Alice joins the conference by issuing a userRequest/create message
with her own id to the server: with her own ID to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: AliceUserInfo | | - userInfo: AliceUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
skipping to change at page 66, line 45 skipping to change at page 70, line 23
<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>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<version>4</version> <version>4</version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 24: Alice joins the conference through the CCMP Figure 24: Alice Joins the Conference through CCMP
6.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 CCMP to add a new conferencing system user,
user, Ciccio, to the conference. This "third-party" request is Ciccio, to the conference. This "third-party" request is realized
realized through a "userRequest/create" message containing, in the through a userRequest/create message containing, in the <userInfo>
"userInfo" parameter, a <user> element compliant with the XCON data parameter, a <user> element compliant with the XCON data model
model representation. Notice that such element includes information representation. Notice that such an element includes information
about Ciccio's Address of Records, as well as his current end-point, about Ciccio's Addresses of Record, as well as his current endpoint,
but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as but has a placeholder 'entity' attribute,
discussed in Section 4.3, since the XCON-USERID is initially unknown "AUTO_GENERATE_1@example.com" as discussed in Section 4.3, since the
to Alice. Thus, the conference server is in charge of generating a XCON-USERID is initially unknown to Alice. Thus, the conference
new XCON-USERID for the user Alice indicates (i.e, Ciccio), and server is in charge of generating a new XCON-USERID for the user
returning it in the "entity" attribute of the "userInfo" parameter Alice indicates (i.e., Ciccio), and returning it in the 'entity'
carried in the response, as well as adding the user to the attribute of the <userInfo> parameter carried in the response, as
conference. The picture below shows the transaction. well as adding the user to the conference. The picture below shows
the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server: userRequest/create message to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: dummyUserID, CiccioUserInfo | | - userInfo: dummyUserID, CiccioUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
skipping to change at page 67, line 48 skipping to change at page 71, line 28
| - response-code: 200 | | - response-code: 200 |
| - version: 5 | | - version: 5 |
| - userInfo: userIDCiccio, | | - userInfo: userIDCiccio, |
| CiccioUserInfo | | CiccioUserInfo |
| | | |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 1. "third-party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
skipping to change at page 68, line 25 skipping to change at page 72, line 4
<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:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. "third party" userResponse message from the server: 2. "third-party" userResponse message from 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>
skipping to change at page 69, line 4 skipping to change at page 72, line 31
<response-code>200</response-code> <response-code>200</response-code>
<version>5</version> <version>5</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 25: Alice adds a new user to the conference through the CCMP Figure 25: Alice Adds a New User to the Conference through CCMP
6.8. Alice asks for the CCMP server capabilities 6.8. Alice Asks for the CCMP Server Capabilities
This section illustrates how Alice can discover which standard CCMP This section illustrates how Alice can discover which standard CCMP
messages and what extensions are supported by the CCMP server she messages and what extensions are supported by the CCMP server with
interacts with through an optionsRequest/optionsResponse transaction. which she interacts through an optionsRequest/optionsResponse
transaction.
To prepare the optionsRequest, Alice just puts her XCON-USERID in the To prepare the optionsRequest, Alice just puts her XCON-USERID in the
confUserID parameter. Looking at the <options> element in the <confUserID> parameter. Looking at the <options> element in the
received optionsResponse, Alice infers the following server received optionsResponse, Alice infers the following server
capabilities as regards standard CCMP messages: capabilities as regards standard CCMP messages:
o the server doesn't support sidebarsByValRequest nor o the server doesn't support sidebarsByValRequest nor the
sidebarByValRequest messages, since they do not appear in the sidebarByValRequest messages, since they do not appear in the
<standard-message-list>; <standard-message-list>;
o the only implemented operation for the blueprintRequest message is o the only implemented operation for the blueprintRequest message is
"retrieve", since no other <operation> entries are included in the "retrieve", since no other <operation> entries are included in the
related <operations> field. related <operations> field.
By analyzing the <extended-message-list>, Alice discovers the server By analyzing the <extended-message-list>, Alice discovers the server
implements a bluePrint extension, referred to as "confSummaryRequest" implements a bluePrint extension, referred to as "confSummaryRequest"
in this example. This extension allows Alice to recover via CCMP a in this example. This extension allows Alice to recover via CCMP a
brief description of a specific conference; the XML elements involved brief description of a specific conference; the XML elements involved
in this extended conference control transaction are available at the in this extended conference control transaction are available at the
URL indicated in the <schema-ref> element and the only operation URL indicated in the <schema-ref> element, and the only operation
provided by this extension is "retrieve". To better understand how provided by this extension is "retrieve". To better understand how
Alice can exploit the "confSummaryRequest" extension via CCMP, see Alice can exploit the "confSummaryRequest" extension via CCMP, see
Section 6.9. Section 6.9.
The figure below shows the optionsRequest/optionsResponse message The figure below shows the optionsRequest/optionsResponse message
exchange between Alice and the CCMP server. exchange between Alice and the CCMP server.
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP optionsRequest message | | CCMP optionsRequest message |
skipping to change at page 71, line 41 skipping to change at page 75, line 13
<extended-message-list> <extended-message-list>
<extended-message> <extended-message>
<name>confSummaryRequest</name> <name>confSummaryRequest</name>
<operations> <operations>
<operation>retrieve</operation> <operation>retrieve</operation>
</operations> </operations>
<schema-def> <schema-def>
http://example.com/ccmp-extension-schema.xsd http://example.com/ccmp-extension-schema.xsd
</schema-def> </schema-def>
<description> <description>
confSummaryRequest is intented confSummaryRequest is intended
to allow the requestor to retrieve to allow the requestor to retrieve
a brief description a brief description
of the conference indicated in the of the conference indicated in the
confObjID request parameter confObjID request parameter
</description> </description>
</extended-message> </extended-message>
</extended-message-list> </extended-message-list>
</options> </options>
</ccmp:optionsResponse> </ccmp:optionsResponse>
</ccmpResponse> </ccmpResponse>
skipping to change at page 72, line 4 skipping to change at page 75, line 24
to allow the requestor to retrieve to allow the requestor to retrieve
a brief description a brief description
of the conference indicated in the of the conference indicated in the
confObjID request parameter confObjID request parameter
</description> </description>
</extended-message> </extended-message>
</extended-message-list> </extended-message-list>
</options> </options>
</ccmp:optionsResponse> </ccmp:optionsResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 26: Alice asks for the server control capabilities Figure 26: Alice Asks for the Server Control Capabilities
6.9. Alice exploits a CCMP server extension 6.9. Alice Makes Use of a CCMP Server Extension
In this section, a very simple example of CCMP extension support is In this section, a very simple example of CCMP extension support is
provided. Alice can recover information about this and other server- provided. Alice can recover information about this and other server-
supported extensions by issuing an optionsRequest (see Section 6.8). supported extensions by issuing an optionsRequest (see Section 6.8).
The extension in question is named "confSummaryRequest" and allows a The extension in question is named "confSummaryRequest" and allows a
CCMP client to obtain from the CCMP server synthetic information CCMP client to obtain from the CCMP server synthetic information
about a specific conference. The conference summary is carried in about a specific conference. The conference summary is carried in
the form of an XML element as follows: the form of an XML element as follows:
skipping to change at page 72, line 33 skipping to change at page 76, line 4
xmlns="http://example.com/ccmp-extension"> xmlns="http://example.com/ccmp-extension">
<xs:element name="confSummary" type="conf-summary-type"/> <xs:element name="confSummary" type="conf-summary-type"/>
<xs:complexType name="conf-summary-type"> <xs:complexType name="conf-summary-type">
<xs:sequence> <xs:sequence>
<xs:element name="title" type="xs:string"/> <xs:element name="title" type="xs:string"/>
<xs:element name="status" type="xs:string"/> <xs:element name="status" type="xs:string"/>
<xs:element name="public" type="xs:boolean"/> <xs:element name="public" type="xs:boolean"/>
<xs:element name="media" type="xs:string"/> <xs:element name="media" type="xs:string"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 27: Example of XML Schema defining an extension parameter Figure 27: Example of XML Schema defining an extension
(ccmp-extension-schema.xsd) parameter (ccmp-extension-schema.xsd)
As it can be inferred from the schema file, the <confSummary> element As can be inferred from the schema file, the <confSummary> element
contains conference information related to: contains conference information related to the following:
o title o title
o status (active or registered) o status (active or registered)
o participation modality (if everyone is allowed to participate, the o participation modality (if everyone is allowed to participate, the
boolean <public> element is set to "true") boolean <public> element is set to "true")
o involved media o involved media
In order to retrieve a conference summary related to the conference In order to retrieve a conference summary related to the conference
she participates in, Alice then sends to the CCMP server an she participates in, Alice sends to the CCMP server an
extendedRequest with a "confSummaryRequest" <extensionName>, extendedRequest with a "confSummaryRequest" <extensionName>,
specifying the conference xcon-uri in the confObjID request specifying the conference XCON-URI in the confObjID request
parameter, as depicted in the figure below. parameter, as depicted in the figure below.
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP extendedRequest message | | CCMP extendedRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: retrieve | | - operation: retrieve |
| - extensionName: confSummaryRequest | | - extensionName: confSummaryRequest |
|------------------------------------------------------>| |------------------------------------------------------>|
skipping to change at page 74, line 36 skipping to change at page 77, line 50
<example:confSummary> <example:confSummary>
<title> Alice's conference </title> <title> Alice's conference </title>
<status> active </status> <status> active </status>
<public> true </public> <public> true </public>
<media> audio </media> <media> audio </media>
</example:confSummary> </example:confSummary>
</ccmp:extendedResponse> </ccmp:extendedResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 28: Alice exploits the 'confSummaryRequest' extension Figure 28: Alice Exploits the 'confSummaryRequest' Extension
7. Locating a Conference Control Server 7. Locating a Conference Server
If a conference control client is not pre-configured to use a If a conferencing client is not pre-configured to use a specific
specific conference control server for the requests, the client MUST conference server for the requests, the client MUST first discover
first discover the conference control server before it can send any the conference server before it can send any requests. The result of
requests. The result of the discovery process, is the address of the the discovery process, is the address of the server supporting
server supporting conferencing. In this document, the result is an conferencing. In this document, the result is an http: or https:
http: or https: URI, which identifies a conference server. URI, which identifies a conference server.
DNS is RECOMMENDED to be used to locate a conference server in the DNS is RECOMMENDED to be used to locate a conference server in the
case that the client is not pre-configured to use a specific case that the client is not pre-configured to use a specific
conference server. U-NAPTR resolution for conferencing takes a conference server. URI-Enabled NAPTR (U-NAPTR) resolution for
domain name as input and produces a URI that identifies the conferencing takes a domain name as input and produces a URI that
conferencing server. This process also requires an Application identifies the conference server. This process also requires an
Service tag and an Application Protocol tag, which differentiate Application Service tag and an Application Protocol tag, which
conferencing-related NAPTR records from other records for that differentiate conferencing-related NAPTR records from other records
domain. for that domain.
Section 12.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 12.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. CCMP.
The NAPTR records in the following example Figure 29 demonstrate the The NAPTR records in the following example (Figure 29) demonstrate
use of the Application Service and Protocol tags. Iterative NAPTR the use of the Application Service and Application Protocol tags.
resolution is used to delegate responsibility for the conferencing Iterative NAPTR resolution is used to delegate responsibility for the
service from "zonea.example.com." and "zoneb.example.com." to conferencing service from "zonea.example.com." and
"outsource.example.com.". "zoneb.example.com." to "outsource.example.com.".
zonea.example.com. zonea.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
zoneb.example.com. zoneb.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
skipping to change at page 76, line 7 skipping to change at page 79, line 31
. ; replacement . ; replacement
) )
Figure 29: Sample XCON-CCMP Service NAPTR Records Figure 29: 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 12.4. Application Protocol tag are included in Section 12.4.
8. Managing Notifications 8. Managing Notifications
As per [RFC5239], the CCMP is one of the following four protocols As per [RFC5239], CCMP is one of the following four protocols, which
which have been formally identified within the XCON framework: have been formally identified within the XCON framework:
Conference Control Protocol: between Conference and Media Control Conference Control Protocol:
Client and Conference Server. Such protocol is the subject of the
present document.
Binary floor Control Protocol: between the Floor Control Client and mediates between conference and media control client (conferencing
the Floor Control Server. Such protocol is the BFCP, specified in client) and conference server. This document describes such a
[RFC4582]. protocol.
Call Signaling Protocol: between the Call Signaling Client and the Binary floor Control Protocol:
Focus. Such protocol can be either SIP or any other call
signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating
a conferencing session.
Notification Protocol: between the Notification Client and the XCON operates between the floor control client and the floor control
Notification Service. This specification does not define a new server. An example of such a protocol is the Binary Floor Control
notification protocol. For clients that use SIP as the call Protocol (BFCP), specified in [RFC4582].
signaling protocol, the XCON event package
[I-D.ietf-xcon-event-package] MUST be used by the client for
notifications of changes in the conference data as described
below.
The CCMP protocol specified in this document is a pro-active one and Call Signaling Protocol:
is used by a conferencing client to send requests to a conferencing
server in order to retrieve information about the conference objects
stored by the server and to potentially manipulate them. However, a
complete conferencing solution is not prohibited from providing
clients with a means for receiving asynchronous updates about the
status of the objects available at the server. The notification
protocol, while conceptually independent of all the mentioned
companion protocols, can nonetheless be chosen in a way that is
consistent with the overall protocol architecture characterizing a
specific deployment, as discussed in the following.
When the conference control client uses SIP [RFC3261] as the operates between the Call Signaling Client and the focus.
Examples of call signaling protocols include SIP, H.323 and IAX.
Such protocols are capable of negotiating a conferencing session.
Notification Protocol:
operates between the Notification Client and the XCON Notification
Service. This specification does not define a new notification
protocol. For clients that use SIP as the call signaling
protocol, the XCON event package [RFC6502] MUST be used by the
client for notifications of changes in the conference data as
described below.
The protocol specified in this document is a proactive one and is
used by a conferencing client to send requests to a conference server
in order to retrieve information about the conference objects stored
by the server and to possibly manipulate them. However, a complete
conferencing solution is not prohibited from providing clients with a
means for receiving asynchronous updates about the status of the
objects available at the server. The notification protocol, while
conceptually independent of all the mentioned companion protocols,
can nonetheless be chosen in a way that is consistent with the
overall protocol architecture characterizing a specific deployment,
as discussed in the following.
When the conferencing control client uses SIP [RFC3261] as the
signaling protocol to participate in the conference, SIP event signaling protocol to participate in the conference, SIP event
notification can be used. In such a case, the conference control notification can be used. In such a case, the conferencing control
client MUST 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 [RFC6502]. This is the default mechanism for conferencing clients as
conferencing clients as is SIP for signaling per the XCON Framework 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
client provides the conference server with an HTTP URL which is conferencing client provides the conference server with an HTTP URL
invoked when a change occurs. This is a common implementation that is invoked when a change occurs. This is a common
mechanism for e-commerce. This works well in the scenarios whereby implementation mechanism for e-commerce. This works well in the
the conferencing client is a web server that provides the graphical scenarios whereby the conferencing client is a web server that
HTML user interface and uses CCMP as the backend interface to the provides the graphical HTML user interface and uses CCMP as the back-
conference server. And, this model can co-exist with the SIP event end interface to the conference server. This model can coexist with
notification model. PC-based clients behind NATs could provide a SIP the SIP event notification model. PC-based clients behind NATs could
event URI, whereas web-based clients using CCMP in the backend would provide a SIP event URI, whereas web-based clients using CCMP in the
probably find the HTTP call back approach much easier. The details back end would probably find the HTTP call back approach much easier.
of this approach are out of scope for the CCMP per se, thus the The details of this approach are out of scope for CCMP; thus, we
expectation is that a future specification will document this expect a future specification will document this solution.
solution.
9. 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 CCMP, which a conforming
conforming conference Server and Conferencing client MUST support. 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 might not be a fully compliant HTTP server. It conferencing server might not be a fully compliant HTTP server. It
is intended that a conference server can easily be built using an is intended that a conference server can easily be built using an
HTTP server with extensibility mechanisms, and that a conferencing HTTP server with extensibility mechanisms, and that a conferencing
client can trivially use existing HTTP libraries. This subset of client can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options requirements helps implementers avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
Support of HTTP authentication [RFC2617] and cookies [RFC6265] is Support of HTTP authentication [RFC2617] and cookies [RFC6265] is
OPTIONAL for a conferencing client that conforms to this OPTIONAL for a conferencing client that conforms to this
specification. These mechanism are unnecessary because CCMP requests specification. These mechanisms are unnecessary because CCMP
carry their own authentication information (in the "subject" field; requests carry their own authentication information (in the "subject"
see Section 5.1). A conferencing client SHOULD include support for field; see Section 5.1). A conferencing client SHOULD include
HTTP proxy authentication. support for HTTP proxy authentication.
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
SHOULD include a Content-Length header. SHOULD include a Content-Length header.
Conferencing clients MUST NOT use the "Expect" header or the "Range" Conferencing clients MUST NOT use the Expect header or the Range
header in CCMP requests. The conference server MAY return 501 (not header in CCMP requests. The conference server MAY return 501 (Not
implemented) errors if either of these HTTP features are used. In Implemented) errors if either of these HTTP features are used. In
the case that the conference server receives a request from the the case that the conference server receives a request from the
conferencing client containing a If-* (conditional) header, the conferencing client containing an If-* (conditional) header, the
conference server SHOULD return a 412 (precondition failed) response. conference server SHOULD return a 412 (precondition failed) response.
The POST method is the only method REQUIRED for CCMP. If a The POST method is the only method REQUIRED for CCMP. If a
conference server chooses to support GET or HEAD, it SHOULD consider conference server chooses to support GET or HEAD, it SHOULD consider
the kind of application doing the GET. Since a conferencing client the kind of application doing the GET. Since a conferencing client
only uses a POST method, the GET or HEAD MUST be either an escaped only uses a POST method, the GET or HEAD MUST be either a URL that
URL (e.g., somebody found a URL in protocol traces or log files and was found outside its normal context (e.g., somebody found a URL in
fed it into their browser) or somebody doing testing/ debugging. The protocol traces or log files and fed it into their browser) or
conference server could provide information in the CCMP response somebody is testing or debugging a system. The conference server
indicating that the URL corresponds to a conference server and only could provide information in the CCMP response indicating that the
responds to CCMP POST requests or the conference server could instead URL corresponds to a conference server and only responds to CCMP POST
try to avoid any leak of information by returning a very generic HTTP requests or the conference server could instead try to avoid any leak
error message such as 405 (method not allowed). of information by returning a very generic HTTP error message such as
405 (Method Not Allowed).
The conference server populates the HTTP headers of responses so that The conference server populates the HTTP headers of responses so that
they are consistent with the contents of the message. In particular, they are consistent with the contents of the message. In particular,
the "CacheControl" header SHOULD be set to disable caching of any the CacheControl header SHOULD be set to disable caching of any
conference information by HTTP intermediaries. Otherwise, there is conference information by HTTP intermediaries. Otherwise, there is
the risk of stale information and/or the unauthorized disclosure of the risk of stale information and/or the unauthorized disclosure of
the information. The HTTP status code MUST indicate a 2xx series the information. The HTTP status code MUST indicate a 2xx series
response for all CCMP Response and Error messages. response for all CCMP Response and Error messages.
The conference server MAY redirect a CCMP request. A conference The conference server MAY redirect a CCMP request. A conference
server MUST NOT include CCMP responses in a 3xx response. A server MUST NOT include CCMP responses in a 3xx response. A
conferencing client MUST handle redirects, by using the Location conferencing client MUST handle redirects by using the Location
header provided by the server in a 3xx response. When redirecting, header provided by the server in a 3xx response. When redirecting,
the conferencing client MUST observe the delay indicated by the the conferencing client MUST observe the delay indicated by the
Retry-After header. The conferencing client MUST authenticate the Retry-After header. The conferencing client MUST authenticate the
server that returns the redirect response before following the server that returns the redirect response before following the
redirect. A conferencing client SHOULD authenticate the conference redirect. A conferencing client SHOULD authenticate the conference
server indicated in a redirect. server indicated in a redirect.
The conference server SHOULD support persistent connections and The conference server SHOULD support persistent connections and
request pipelining. If pipelining is not supported, the conference request pipelining. If pipelining is not supported, the conference
server MUST NOT allow persistent connections. The conference server server MUST NOT allow persistent connections. The conference server
MUST support termination of a response by the closing of a MUST support termination of a response by the closing of a
connection. connection.
Implementations of CCMP that implement HTTP transport MUST implement Implementations of CCMP that implement HTTP transport MUST implement
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 conferencing client and the conference
conference control server. The conferencing client MUST implement server. The conferencing client MUST implement the server
the server authentication method described in HTTPS [RFC2818]. The authentication method described in HTTPS [RFC2818]. The device uses
device uses the URI obtained during conference server discovery to the URI obtained during conference server discovery to authenticate
authenticate the server. The details of this authentication method the server. The details of this authentication method are provided
are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used, in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the
the conferencing client SHOULD fail a request if server conferencing client SHOULD fail a request if server authentication
authentication fails. fails.
10. 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 an endpoint theft
an endpoint in attempting to create conferences it is not allowed to of service 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 7. 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 10.1. described in Section 10.1.
skipping to change at page 79, line 46 skipping to change at page 83, line 29
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 10.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 10.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. The recommendations to minimize the conference server itself. The recommendations to minimize
the potential and impact of DoS attacks are discussed in the potential and impact of DoS attacks are discussed in
Section 10.4. Section 10.4.
Of the considerations listed above, items 1 and 3 are addressed Of the considerations listed above, items 1 and 3 are addressed
within the referenced sections earlier in this document. The within the referenced sections earlier in this document. The
remaining security considerations are addressed in detail in the remaining security considerations are addressed in detail in the
following sections. following sections.
10.1. Assuring that the Proper Conferencing Server has been contacted 10.1. Assuring That the Proper Conference Server Has Been Contacted
Section 7 describes a mechanism using DNS by which a conference Section 7 describes a mechanism using DNS by which a conferencing
client discovers a conference server. A primary concern is spoofed client discovers a conference server. A primary concern is spoofed
DNS replies, thus the use of DNSSEC is RECOMMENDED to ensure that the DNS replies; thus, the use of DNS Security (DNSSEC) is RECOMMENDED to
client receives a valid response from the DNS server in cases where ensure that the client receives a valid response from the DNS server
this is a concern. in cases where this is a concern.
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 conferencing 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). Any implementation of CCMP an iPAddress or dNSName, respectively). Any implementation of CCMP
MUST be capable of being transacted over TLS so that the client can MUST be capable of being transacted over TLS so that the client can
request the above authentication. Note that in order for the request the above authentication. Note that, in order for the
presented certificate to be valid at the client, the client MUST be presented certificate to be valid at the client, the client MUST be
able to validate the certificate following the procedures in able to validate the certificate following the procedures in
[RFC2818] in the case of HTTP as a transport. In particular, the [RFC2818] in the case of HTTP as a transport. In particular, the
validation path of the certificate must end in one of the client's validation path of the certificate must end in one of the client's
trust anchors, even if that trust anchor is the conference server trust anchors, even if that trust anchor is the conference server
certificate itself. If the client has external information as to the certificate itself. If the client has external information as to the
expected identity or credentials of the proper conference server, the expected identity or credentials of the proper conference server, the
authentication checks described above MAY be omitted. authentication checks described above MAY be omitted.
10.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 conference 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 example, in the case of a the specific protocol can be used. For example, in the case of a
user joining the conference using SIP signaling, the user user joining the conference using SIP signaling, the user
authentication as defined in [RFC3261] MUST be used. For the case of authentication as defined in [RFC3261] MUST be used. For the case of
users joining the conference using the CCMP, the CCMP Request users joining the conference using CCMP, the CCMP Request messages
messages provide a subject field which contains a username and provide a subject field that contains a username and password, which
password, which can be used for authentication. Since the CCMP can be used for authentication. Since the CCMP messages are
messages are RECOMMENDED to be carried over TLS, this information can RECOMMENDED to be carried over TLS, this information can be sent
be sent securely. securely.
The XCON Framework [RFC5239] provides an overview of other The XCON framework [RFC5239] provides an overview of other
authorization mechanisms. In the cases where a user is authorized authorization mechanisms. In the cases where a user is authorized
via multiple mechanisms, it is RECOMMENDED that the conference server via multiple mechanisms, it is RECOMMENDED that the conference server
associate the authorization of the CCMP interface with other associate the authorization of the CCMP interface with other
authorization mechanisms - e.g., PSTN users that join with a PIN and authorization mechanisms; for example, Public Switched Telephone
control the conference using CCMP. When a conference server presents Network (PSTN) users that join with a PIN and control the conference
the identity of authorized users, it MAY provide information about using CCMP. When a conference server presents the identity of
the way the identity was proven or verified by the system. A authorized users, it MAY provide information about the way the
conference server can also allow a completely unauthenticated user identity was proven or verified by the system. A conference server
into the system - this information SHOULD also be communicated to can also allow a completely unauthenticated user into the system --
interested parties. this information SHOULD also be communicated to 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 CCMP (i.e., in the
appropriate CCMP response messages). The XCON-USERIDs for each user/ appropriate CCMP response messages). The XCON-USERIDs for each user/
participant in the conference are contained in the "entity" attribute participant in the conference are contained in the 'entity' attribute
in the "user" element in the conference object. The XCON-USERID is in the <user> element in the conference object. The XCON-USERID is
REQUIRED for any subsequent operations by the user on the conference REQUIRED for any subsequent operations by the user on the conference
object and is carried in the confUserID parameter in the CCMP object and is carried in the confUserID parameter in the CCMP
requests and responses. requests and responses.
Note that the policy management of an XCON-compliant conference Note that the policy management of an XCON-compliant conferencing
system is out of the scope of this document, as well as of the XCON system is out of the scope of this document, as well as of the XCON
WG. However, the specification of a policy management framework is working group (WG). However, the specification of a policy
realizable with the overall XCON architecture, in particular with management framework is realizable with the overall XCON
regards to a Role Based Access Control (RBAC) approach. In RBAC, the architecture, in particular with regard to a Role-Based Access
following elements are identified: (i) Users; (ii) Roles; (iii) Control (RBAC) approach. In RBAC, the following elements are
Objects; (iv) Operations; (v) Permissions. For all of the above identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations;
elements a direct mapping exists onto the main XCON entities. As an (v) Permissions. For all of the above elements, a direct mapping
example, RBAC objects map onto XCON data model objects and RBAC exists onto the main XCON entities. As an example, RBAC objects map
operations map onto CCMP operations. onto XCON data model objects and RBAC operations map onto CCMP
operations.
Future documents can define an RBAC framework for XCON, by first Future documents can define an RBAC framework for XCON, by first
focusing on the definition of roles and then specifying the needed focusing on the definition of roles and then specifying the needed
permission policy sets and role policy sets (used to associate policy permission policy sets and role policy sets (used to associate policy
permission sets with specific roles). With these policies in place, permission sets with specific roles). With these policies in place,
access to a conference object compliant with the XCON data model can access to a conference object compliant with the XCON data model can
be appropriately controlled. As far as assigning users to roles, the be appropriately controlled. As far as assigning users to roles, the
Users in the RBAC model relate directly to the "users" element in the Users in the RBAC model relate directly to the <users> element in the
conference object. The "users" element is comprised of "user" conference object. The <users> element is comprised of <user>
elements representing a specific user in the conferencing system. elements representing a specific user in the conferencing system.
Each "user" element contains an "entity" attribute with the XCON-
USERID and a "role" element. Thus, each authorized user (as Each <user> element contains an 'entity' attribute with the XCON-
represented by an XCON-USERID) can be associated with a "role" USERID and a <role> element. Thus, each authorized user (as
represented by an XCON-USERID) can be associated with a <role>
element. element.
10.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 CCMP through the use of TLS.
The conference server SHOULD support the mechanism to ensure the The conference server SHOULD support the mechanism to ensure the
privacy of the XCON-USERID. The conference client indicates the privacy of the XCON-USERID. The conferencing client indicates the
desired level of privacy by manipulation of the "provide-anonymity" desired level of privacy by manipulation of the <provide-anonymity>
element defined in the XCON data model element defined in the XCON data model [RFC6501]. The <provide-
([I-D.ietf-xcon-common-data-model]. The "provide-anonymity" element anonymity> element controls the degree to which a user reveals their
controls the degree to which a user reveals their identity. The identity. The following summarizes the values for the <provide-
following summarizes the values for the "provide-anonymity" element anonymity> element that the client includes in their requests:
that the client includes in their requests:
"hidden": Ensures that other participants are not aware that there "hidden": Ensures that other participants are not aware that there
is an additional participant (i.e., the user issuing the request) is an additional participant (i.e., the user issuing the request)
in the conference. This could be used in cases of users that are in the conference. This could be used in cases of users that are
authorized with a special role in a conference (e.g., a supervisor authorized with a special role in a conference (e.g., a supervisor
in a call center environment). in a call center environment).
"anonymous": Ensures that other participants are aware that there "anonymous": Ensures that other participants are aware that there
is another participant (i.e., the user issuing the request), is another participant (i.e., the user issuing the request);
however, the other participants are not provided information as to however, the other participants are not provided information as to
the identity of the user. the identity of the user.
"semi-private": Ensures that the user's identity is only to be "semi-private": Ensures that the user's identity is only to be
revealed to other participants or users that have a higher level revealed to other participants or users that have a higher-level
authorization (e.g., a conferencing system can be configured such authorization (e.g., a conferencing system can be configured such
that a human administrator can see all users). that a human administrator can see all users).
If the client desires privacy, the conference client SHOULD include If the client desires privacy, the conferencing client SHOULD include
the "provide-anonymity" element in the "confInfo" parameter in a CCMP the <provide-anonymity> element in the <confInfo> parameter in a CCMP
confRequest message with an "update" or "create" operation or in the confRequest message with an <operation> parameter of "update" or
"userInfo" parameter in a CCMP userRequest message with an "update" "create" or in the <userInfo> parameter in a CCMP userRequest message
or "create" operation. If the "provide-anonymity" element is not with an <operation> parameter of "update" or "create". If the
included in the conference object, then other users can see the <provide-anonymity> element is not included in the conference object,
participant's identity. Participants are made aware of other then other users can see the participant's identity. Participants
participants that are "anonymous" or "semi-private" when they perform are made aware of other participants that are "anonymous" or "semi-
subsequent operations on the conference object or retrieve the private" when they perform subsequent operations on the conference
conference object or when they receive subsequent notifications. object or retrieve the conference object or when they receive
subsequent notifications.
Note, that independent of the level of anonymity requested by the Note that independent of the level of anonymity requested by the
user, the identity of the user is always known by the conferencing user, the identity of the user is always known by the conferencing
system as that is required to perform the necessary authorization as system as that is required to perform the necessary authorization as
described in Section 10.2. The degree to which human administrators described in Section 10.2. The degree to which human administrators
can see the information can be controlled using policies (e.g., some can see the information can be controlled using policies (e.g., some
information in the data model can be hidden from human information in the data model can be hidden from human
administrators). administrators).
10.4. Mitigating DoS Attacks 10.4. Mitigating DoS Attacks
[RFC4732] provides an overview of possible DoS attacks. In order to [RFC4732] provides an overview of possible DoS attacks. In order to
minimize the potential for DoS attacks, it is RECOMMENDED that minimize the potential for DoS attacks, it is RECOMMENDED that
conferencing systems require user authentication and authorization conferencing systems require user authentication and authorization
for any client participating in a conference. This can be for any client participating in a conference. This can be
accomplished through the use of the mechanisms described in accomplished through the use of the mechanisms described in
Section 10.2, as well as by using the security mechanisms associated Section 10.2, as well as by using the security mechanisms associated
with the specific signaling (e.g., SIPS) and media protocols (e.g., with the specific signaling (e.g., Session Initiation Protocol Secure
SRTP). In addition, Section 4.4 describes the use of a timer (SIPS)) and media protocols (e.g., Secure Realtime Transport Protocol
(SRTP)). In addition, Section 4.4 describes the use of a timer
mechanism to alleviate the situation whereby CCMP messages pend mechanism to alleviate the situation whereby CCMP messages pend
indefinitely, thus increasing the potential that pending requests indefinitely, thus increasing the potential that pending requests
continue to increase when is a server is receiving more requests than continue to increase when is a server is receiving more requests than
it can process. it can process.
11. XML Schema 11. XML Schema
This section gives the XML Schema Definition This section gives the XML schema definition
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
"application/ccmp+xml" format. This is presented as a formal "application/ccmp+xml" format. This is presented as a formal
definition of the "application/ccmp+xml" format. A new XML definition of the "application/ccmp+xml" format. A new XML
namespace, a new XML schema, and the MIME type for this schema are namespace, a new XML schema, and the MIME type for this schema are
registered with IANA as described in Section 12. Note that this XML registered with IANA as described in Section 12. Note that this XML
Schema Definition is not intended to be used with on-the-fly Schema Definition is not intended to be used with on-the-fly
validation of the presence XML document. Whitespaces are included in validation of the presence XML document. Whitespaces are included in
the schema to conform to the line length restrictions of the RFC the schema to conform to the line length restrictions of the RFC
format without having a negative impact on the readability of the format without having a negative impact on the readability of the
document. Any conforming processor should remove leading and document. Any conforming processor should remove leading and
skipping to change at page 101, line 19 skipping to change at page 105, line 17
type="xs:string" type="xs:string"
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>
</xs:schema> </xs:schema>
Figure 30 Figure 30: CCMP XML Schema
12. 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 and defines registries for the CCMP operation types and response
types and response codes. codes.
12.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
Mary Barnes (mary.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.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>
<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 <p>See <a href="http://www.rfc-editor.org/rfc/rfc6503.txt">
with the RFC number for this specification.]] RFC 6503</a>.</p>
<p>See RFCXXXX.</p> </body>
</body> </html>
</html> END
END
12.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 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.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.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 11 of this document. Section 11 of this document.
12.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
Same as the charset parameter of "application/xml" as specified in Same as the charset parameter of "application/xml" as specified in
RFC 3023 [RFC3023], Section 3.2. [RFC3023], Section 3.2.
Encoding considerations: Same as the encoding considerations of Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. "application/xml" as specified in [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 to conference control. Some of the data protocol data related to conference control. Some of the data
could be considered private. This media type does not provide any could be considered private. This media type does not provide any
protection and thus other mechanisms such as those described in protection and thus other mechanisms such as those described in
Section 10 are required to protect the data. This media type does Section 10 are required to protect the data. This media type does
not contain executable content. not contain executable content.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC 6503.
replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications that 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): .ccmp File extension(s): .ccmp
Macintosh File Type Code(s): TEXT Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.ietf.barnes@gmail.com> Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
skipping to change at page 103, line 47 skipping to change at page 107, line 46
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.
12.4. DNS Registrations 12.4. DNS Registrations
Section 12.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 12.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. CCMP.
12.4.1. Registration of a Conference Control Server Application Service 12.4.1. Registration of a Conference 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: RFC 6503
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
12.4.2. Registration of a Conference Control Server Application 12.4.2. Registration of a Conference Server Application Protocol Tag
Protocol Tag for CCMP 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 CCMP, 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: RFC 6503
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
12.5. CCMP Protocol Registry 12.5. CCMP Protocol Registry
This document requests that the IANA create a new registry for the The IANA has created a new registry for CCMP:
CCMP protocol: http://www.iana.org/assignments/ccmp-parameters. The http://www.iana.org/assignments/ccmp-parameters. The document
document creates initial sub-registries for CCMP operation types and creates initial sub-registries for CCMP operation types and response
response codes." codes.
12.5.1. CCMP Message Types 12.5.1. CCMP Message Types
The following summarizes the requested registry for CCMP Messages: The following summarizes the registry for CCMP messages:
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 6503.
with the RFC number for this specification.]
Registration/Assignment Procedures: Following the policies outlined Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the in [RFC5226], the IANA policy for assigning new values for the
CCMP message types for CCMP shall be Specification Required. CCMP message types for CCMP is Specification Required.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary
Barnes (mary.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.com).
This specification establishes the Message sub-registry under This specification establishes the Message sub-registry under
http://www.iana.org/assignments/ccmp-messages. The initial Message http://www.iana.org/assignments/ccmp-messages. The initial Message
table is populated using the CCMP messages described in Section 4.1 table is populated using the CCMP messages described in Section 4.1
and defined in the XML schema in Section 11. and defined in the XML schema in Section 11.
Message Description Reference Message Description Reference
------- ----------- --------- ------- ----------- ---------
optionsRequest Used by a conference control client [RFCxxxx] optionsRequest Used by a conferencing client [RFC6503]
to query a conference server for to query a conference server for
its capabilities, in terms of its capabilities, in terms of
supported messages. supported messages.
optionsResponse Returns a list of CCMP messages [RFCxxxx] optionsResponse Returns a list of CCMP messages [RFC6503]
supported by the specific supported by the specific
conference server. conference server.
blueprintsRequest Used by a conference control client [RFCxxxx] blueprintsRequest Used by a conferencing client [RFC6503]
to query a conferencing system for to query a conference server for
its capabilities, in terms of its capabilities, in terms of
available conference blueprints. available conference blueprints.
blueprintsResponse The blueprintsResponse returns a [RFCxxxx] blueprintsResponse Returns a list of blueprints supported [RFC6503]
list of blueprints supported
by the specific conference server. by the specific conference server.
confsRequest Used by a conference control client [RFCxxxx] blueprintRequest Sent to retrieve the conference object [RFC6503]
associated with a specific blueprint.
blueprintResponse Returns the conference object [RFC6503]
associated with a specific blueprint.
confsRequest Used by a conferencing client [RFC6503]
to query a conference server for to query a conference server for
its scheduled/active conferences. its scheduled/active conferences.
confsResponse Returns the list of the currently [RFCxxxx] confsResponse Returns the list of the currently [RFC6503]
activated/scheduled conferences activated/scheduled conferences
at the server. at the server.
confRequest Used to create a conference object [RFCxxxx] confRequest Used to create a conference object [RFC6503]
and/or to request an operation on and/or to request an operation on
the conference object as a whole. the conference object as a whole.
confResponse Indicates the result of the operation [RFCxxxx] confResponse Indicates the result of the operation [RFC6503]
on the conference object as a whole. on the conference object as a whole.
userRequest Used to request an operation on the [RFCxxxx] userRequest Used to request an operation on the [RFC6503]
"user" element in the conference object. <user> element in the conference object.
userResponse Indicates the result of the requested [RFCxxxx] userResponse Indicates the result of the requested [RFC6503]
operation on the "user" element in operation on the <user> element in
the conference object. the conference object.
usersRequest Used to manipulate the "users" element [RFCxxxx] usersRequest Used to manipulate the <users> element [RFC6503]
in the conference object, including in the conference object, including
parameters such as the "allowed-users-list", parameters such as the <allowed-users-list>,
"join-handling", etc. <join-handling>, etc.
usersResponse Indicates the result of the request to [RFCxxxx] usersResponse Indicates the result of the request [RFC6503]
manipulate the "users" element in the to manipulate the <users> element in
conference object. the conference object.
sidebarsByValRequest Used to retrieve the "sidebars-by-val" [RFCxxxx] sidebarsByValRequest Used to retrieve the <sidebars-by-val> [RFC6503]
element of the target conference object. element of the target conference object.
sidebarsByValResponse Returns the list of the sidebar-by-val [RFCxxxx] sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503]
conferences within the target conference conferences within the target
object. conference object.
sidebarsByRefRequest Used to retrieve the "sidebars-by-ref" [RFCxxxx] sidebarsByRefRequest Used to retrieve the <sidebars-by-ref> [RFC6503]
element of the target conference object. element of the target conference
object.
sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFCxxxx] sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503]
conferences associated with the target conferences associated with the target
conference object. conference object.
sidebarByValRequest Used to request an operation on a [RFCxxxx] sidebarByValRequest Used to request an operation on a [RFC6503]
sideber-by-val conference. sidebar-by-val conference.
sidebarByValResponse Indicates the result of the request to [RFCxxxx] sidebarByValResponse Indicates the result of the request to [RFC6503]
manipulate a sidebar-by-val conference. manipulate a sidebar-by-val conference.
sidebarByRefRequest Used to request an operation on a [RFCxxxx] sidebarByRefRequest Used to request an operation on a [RFC6503]
sideber-by-ref conference. sideber-by-ref conference.
sidebarByRefResponse Indicates the result of the request to [RFCxxxx] sidebarByRefResponse Indicates the result of the request to [RFC6503]
manipulate a sidebar-by-ref conference. manipulate a sidebar-by-ref conference.
12.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 6503.
with the RFC number for this specification.]
Registration/Assignment Procedures: Following the policies outlined Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the in [RFC5226], the IANA policy for assigning new values for the
Response codes for CCMP shall be Specification Required. Response codes for CCMP shall be Specification Required.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary
Barnes (mary.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.com).
This specification establishes the Response-code sub-registry under This specification establishes the Response-code sub-registry under
http://www.iana.org/assignments/ccmp-parameters. The initial http://www.iana.org/assignments/ccmp-parameters. The initial
Response-code table is populated using the Response codes defined in Response-code table is populated using the Response codes defined in
Section 5.4 as follows: Section 5.4 as follows:
Default Default
Response Response
Number String Description Reference Number String Description Reference
------ ------------- ------------ --------- ------ ------------- ------------ ---------
200 Success The request was successfully [RFCxxxx] 200 Success The request was successfully [RFC6503]
processed. processed.
400 Bad Request The request was badly formed in [RFCxxxx] 400 Bad Request The request was badly formed in [RFC6503]
some fashion. some fashion.
401 Unauthorized The user was not authorized for [RFCxxxx] 401 Unauthorized The user was not authorized for [RFC6503]
the specific operation on the the specific operation on the
conference object. conference object.
403 Forbidden The specific operation is not [RFCxxxx] 403 Forbidden The specific operation is not [RFC6503]
valid for the target conference valid for the target conference
object. object.
404 Object Not Found The specific conference object [RFCxxxx] 404 Object Not Found The specific conference object [RFC6503]
was not found. was not found.
409 Conflict A requested operation cannot be [RFCxxxx] 409 Conflict A requested operation cannot be [RFC6503]
successfully completed by the successfully completed by the
server. For example, the server. For example, the
modification of an object modification of an object
cannot be applied because cannot be applied because
the client version of the object the client version of the object
is obsolete and the requested is obsolete and the requested
modifications collide with the modifications collide with the
up-to-date state of the object up-to-date state of the object
stored at the server. stored at the server.
420 User Not Found The user who is the target of the [RFCxxxx] 420 User Not Found The user who is the target of the [RFC6503]
requested operation is unknown. requested operation is unknown.
421 Invalid confUserID The "confUserID" of the sender [RFCxxxx] 421 Invalid confUserID The <confUserID> parameter of the [RFC6503]
in the request is invalid. sender in the request is invalid.
422 Invalid Conference A request to access/manipulate [RFCxxxx] 422 Invalid Conference A request to access/manipulate [RFC6503]
Password a password-protected conference Password a password-protected conference
object contained an invalid object contained an invalid
"conference-password" parameter. <conference-password> parameter.
423 Conference Password A request to access/manipulate [RFCxxxx] 423 Conference Password A request to access/manipulate [RFC6503]
Required a password-protected conference Required a password-protected conference
object did not contain a object did not contain a
"conference-password" parameter. <conference-password> parameter.
424 Authentication The server wants to authenticate [RFCxxxx] 424 Authentication The server wants to authenticate [RFC6503]
Required the request through the "subject" Required the request through the <subject>
parameter but the parameter is parameter but the parameter is
not provided in the request. not provided in the request.
425 Forbidden Delete The conferencing system cannot [RFCxxxx] 425 Forbidden Delete The conferencing system cannot [RFC6503]
Parent system cannot delete the specific Parent delete the specific conference
conference object because it is a object because it is a
parent for another conference object. parent for another conference object.
426 Forbidden Change The target conference object [RFCxxxx] 426 Forbidden Change The target conference object [RFC6503]
Protected cannot be changed (e.g., due to Protected cannot be changed (e.g., due to
policies, roles or privileges). policies, roles or privileges).
427 Invalid Domain Name The domain name in an [RFCxxxx] 427 Invalid Domain Name The domain name in an [RFC6503]
AUTO_GENERATE_X AUTO_GENERATE_X
instance in the conference object instance in the conference object
is not within the conference is not within the conference
server's domain of responsibility. server's domain of responsibility.
500 Server Internal The conference server experienced [RFCxxxx] 500 Server Internal The conference server experienced [RFC6503]
Error some sort of internal error. Error some sort of internal error.
501 Not Implemented The specific operation is not [RFCxxxx] 501 Not Implemented The specific operation is not [RFC6503]
implemented on the conferencing implemented on the conferencing
system. system.
510 Request Timeout The request could not be [RFCxxxx] 510 Request Timeout The request could not be [RFC6503]
processed within a reasonable processed within a reasonable
time (as specified by the time (as specified by the
conferencing system). conferencing system).
511 Resources Not The conference server cannot [RFCxxxx] 511 Resources Not The conference server cannot [RFC6503]
Available execute a command because of Available execute a command because of
resource issues, e.g. it cannot resource issues, e.g., it cannot
create a conference because create a conference because
the system has reached its limits the system has reached its limits
on the number of conferences. on the number of conferences.
13. 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, Simo Veikkolainen, Keith Drage, Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage,
Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian
Carpenter (genart review) and Mykyta Yevstifeyev (IANA Carpenter (genart review), and Mykyta Yevstifeyev (IANA
considerations). Special thanks go to Roberta Presta for her considerations). Special thanks go to Roberta Presta for her
invaluable contribution to this document. Roberta has worked on the invaluable contribution to this document. Roberta has worked on the
specification of the CCMP protocol at the University of Napoli for specification of CCMP at the University of Napoli for the preparation
the preparation of her Master thesis. She has also implemented the of her Master thesis. She has also implemented the CCMP prototype
CCMP prototype used for the trials and from which the dumps provided used for the trials and from which the dumps provided in Section 6
in Section 6 have been extracted. have been extracted.
14. References 14. References
14.1. Normative References 14.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
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[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] [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, April 2011.
[RFC6501] 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-31 Conferencing (XCON)", RFC 6501, March 2012.
(work in progress), June 2011.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
14.2. Informative References 14.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
skipping to change at page 111, line 19 skipping to change at page 115, line 15
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-xcon-event-package] [RFC6502] 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)", RFC 6502,
draft-ietf-xcon-event-package-01 (work in progress), March 2012.
September 2008.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20070427]
Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., and H. Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M.,
Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2
World Wide Web Consortium FirstEdition REC-soap12-part1- Part 1: Messaging Framework (Second Edition)", World Wide
20030624, June 2003, Web Consortium Recommendation REC-soap12-part1-20070427,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. April 2007,
<http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20070427]
Mendelsohn, N., Hadley, M., Moreau, J., Gudgin, M., and H. Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N.,
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2
Web Consortium FirstEdition REC-soap12-part2-20030624, Part 2: Adjuncts (Second Edition)", World Wide Web
June 2003, Consortium Recommendation REC-soap12-part2-20070427,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. April 2007,
<http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
Appendix A. Appendix A: Evaluation of other protocol models and Appendix A. Evaluation of Other Protocol Models and Transports
transports considered for CCMP Considered for CCMP
This section provides some background as to the selection of HTTP as This section provides some background as to the selection of HTTP as
the transport for the CCMP requests/responses. In addition to HTTP, the transport for the CCMP requests/responses. In addition to HTTP,
the operations on the objects can be implemented in at least two the operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls -- using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
In both the SOAP and RESTFUL approaches, servers will have to In both the SOAP and RESTFUL approaches, servers will have to
recreate their internal state representation of the object with each recreate their internal state representation of the object with each
update request, checking parameters and triggering function update request, checking parameters and triggering function
invocations. In the SOAP approach, it would be possible to describe invocations. In the SOAP approach, it would be possible to describe
a separate operation for each atomic element, but that would greatly a separate operation for each atomic element, but that would greatly
increase the complexity of the protocol. A coarser-grained approach increase the complexity of the protocol. A coarser-grained approach
to the CCMP does require that the server process XML elements in to CCMP does require that the server process XML elements in updates
updates that have not changed and that there can be multiple changes that have not changed and that there can be multiple changes in one
in one update. For CCMP, the resource (REST) model might appear more update. For CCMP, the resource (REST) model might appear more
attractive, since the conference operations fit the CRUD approach. attractive, since the conference operations fit the CRUD approach.
However, neither of these approaches were considered ideal. SOAP was However, neither of these approaches were considered ideal. SOAP was
considered to bring additional overhead. It is quite awkward to considered to bring additional overhead. It is quite awkward to
apply a RESTful approach since the CCMP requires a more complex apply a RESTful approach since CCMP requires a more complex request/
request/response protocol in order to maintain the data both in the response protocol in order to maintain the data both in the server
server and at the client. This doesn't map very elegantly to the and at the client. This doesn't map very elegantly to the basic
basic request/response model, whereby a response typically indicates request/response model, whereby a response typically indicates
whether the request was successful or not, rather than providing whether the request was successful or not, rather than providing
additional data to maintain the synchronization between the client additional data to maintain the synchronization between the client
and server data. In addition, the CCMP clients may also receive the and server data. In addition, the CCMP clients may also receive the
data in Notifications. While the notification method or protocol data in notifications. While the notification method or protocol
used by some conferencing clients can be independent of the CCMP, the used by some conferencing clients can be independent of CCMP, the
same data in the server is used for both the CCMP and Notifications - same data in the server is used for both CCMP and notifications -
this requires a server application above the transport layer (e.g., this requires a server application above the transport layer (e.g.,
HTTP) for maintaining the data, which in the CCMP model is HTTP) for maintaining the data, which in the CCMP model is
transparent to the transport protocol. transparent to the transport protocol.
Thus, the solution for the CCMP defined in this document is viewed as Thus, the solution for CCMP defined in this document is viewed as a
a good compromise amongst the most notable past candidates and is good compromise amongst the most notable past candidates and is
referred to as "HTTP single-verb transport plus CCMP body". With referred to as "HTTP single-verb transport plus CCMP body". With
this approach, CCMP is able to take advantage of existing HTTP this 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, 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
pair); this allows decoupling CCMP messages from HTTP messages. pair); this allows decoupling CCMP messages from HTTP messages.
Similarly, as with any RESTful approach, CCMP messages are inserted Similarly, as with any RESTful approach, CCMP messages are inserted
directly in the body of HTTP messages, thus avoiding any unnecessary directly in the body of HTTP messages, thus avoiding any unnecessary
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.
A.1. Using SOAP for the CCMP A.1. Using SOAP for CCMP
A remote procedure call (RPC) mechanism for the CCMP could use SOAP A remote procedure call (RPC) mechanism for CCMP could use SOAP
(Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC (Simple Object Access Protocol [W3C.REC-soap12-part1-20070427]
-soap12-part2-20030624]), where conferences and the other objects are [W3C.REC-soap12-part2-20070427]), where conferences and the other
modeled as services with associated operations. Conferences and objects are modeled as services with associated operations.
other objects are selected by their own local identifiers, such as Conferences and other objects are selected by their own local
email-like names for users. This approach has the advantage that it identifiers, such as email-like names for users. This approach has
can easily define atomic operations that have well-defined error the advantage that it can easily define atomic operations that have
conditions. well-defined error conditions.
All SOAP operations would use a single HTTP verb. While the RESTful All SOAP operations would use a single HTTP verb. While the RESTful
approach requires the use of a URI for each object, SOAP can use any approach requires the use of a URI for each object, SOAP can use any
token. token.
A.2. A RESTful approach for the CCMP A.2. A RESTful Approach for CCMP
Conference objects can also be modeled as resources identified by Conference objects can also be modeled as resources identified by
URIs, with the basic CRUD operations mapped to the HTTP methods POST/ URIs, with the basic CRUD operations mapped to the HTTP methods POST/
PUT for creating objects, GET for reading objects, PATCH/POST/PUT for PUT for creating objects, GET for reading objects, PATCH/POST/PUT for
changing objects and DELETE for deleting them. Many of the objects, changing objects, and DELETE for deleting them. Many of the objects,
such as conferences, already have natural URIs. such as conferences, already have natural URIs.
CCMP can be mapped into the CRUD (Create, Read, Update, Delete) CCMP can be mapped into the CRUD (Create, Read, Update, Delete)
design pattern. The basic CRUD operations are used to manipulate design pattern. The basic CRUD operations are used to manipulate
conference objects, which are XML documents containing the conference objects, which are XML documents containing the
information characterizing a specified conference instance, be it an information characterizing a specified conference instance, be it an
active conference or a conference blueprint used by the conference active conference or a conference blueprint used by the conference
server to create new conference instances through a simple clone server to create new conference instances through a simple clone
operation. operation.
Following the CRUD approach, CCMP could use a general-purpose Following the CRUD approach, CCMP could use a general-purpose
protocol such as HTTP [RFC2616] to transfer domain-specific XML- protocol such as HTTP [RFC2616] to transfer domain-specific XML-
encoded data objects defined in the Conference Information Data Model encoded data objects defined in the "Conference Information Data
for Centralized Conferencing [I-D.ietf-xcon-common-data-model]. Model for Centralized Conferencing" [RFC6501].
Following on the CRUD approach, CCMP could follow the well-known REST Following on the CRUD approach, CCMP could follow the well-known REST
(REpresentational State Transfer) architectural style [REST]. The (REpresentational State Transfer) architectural style [REST]. CCMP
CCMP could map onto the REST philosophy, by specifying resource URIs, could map onto the REST philosophy, by specifying resource URIs,
resource formats, methods supported at each URI and status codes that resource formats, methods supported at each URI and status codes that
have to be returned when a certain method is invoked on a specific have to be returned when a certain method is invoked on a specific
URI. A REST-style approach must ensure sure that all operations can URI. A REST-style approach must ensure sure that all operations can
be mapped to HTTP operations. be mapped to HTTP operations.
The following summarizes the specific HTTP method that could be used The following summarizes the specific HTTP method that could be used
for each of the CCMP Requests: for each of the CCMP Requests:
Retrieve: HTTP GET could be used on XCON-URIs, so that clients can Retrieve: HTTP GET could be used on XCON-URIs, so that clients can
obtain data about conference objects in the form of XML data model obtain data about conference objects in the form of XML data model
skipping to change at page 114, line 15 skipping to change at page 119, line 12
Delete: HTTP DELETE could be used to delete conference objects and Delete: HTTP DELETE could be used to delete conference objects and
parameters within conference objects identified by the XCON-URI. parameters within conference objects identified by the XCON-URI.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Polycom Polycom
TX TX
USA USA
Email: mary.ietf.barnes@gmail.com EMail: mary.ietf.barnes@gmail.com
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com EMail: chris@ns-technologies.com
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
Via Claudio 21 Via Claudio 21
Napoli 80125 Napoli 80125
Italy Italy
Email: spromano@unina.it EMail: spromano@unina.it
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
Email: hgs+xcon@cs.columbia.edu EMail: hgs+xcon@cs.columbia.edu
 End of changes. 451 change blocks. 
1385 lines changed or deleted 1433 lines changed or added

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