draft-ietf-xcon-ccmp-13.txt   draft-ietf-xcon-ccmp-14.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: November 10, 2011 NS-Technologies Expires: January 13, 2012 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
May 9, 2011 July 12, 2011
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-13 draft-ietf-xcon-ccmp-14
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) allows an The Centralized Conferencing Manipulation Protocol (CCMP) allows an
XCON conferencing system client to create, retrieve, change, and XCON conferencing system client to create, retrieve, change, and
delete objects that describe a centralized conference. CCMP is a delete objects that describe a centralized conference. CCMP is a
means to control basic and advanced conference features such as means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and conference state and capabilities, participants, relative roles, and
details. CCMP is a state-less, XML-based, client server protocol details. CCMP is a state-less, XML-based, client server protocol
that carries, in its request and response messages, conference that carries, in its request and response messages, conference
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2011. This Internet-Draft will expire on January 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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 . . . . . . . 23
5.3.4. confRequest and confResponse . . . . . . . . . . . . 25 5.3.4. confRequest and confResponse . . . . . . . . . . . . 25
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
5.3.6. userRequest and userResponse . . . . . . . . . . . . 31 5.3.6. userRequest and userResponse . . . . . . . . . . . . 31
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42
5.3.11. extendedRequest and extendedResponse . . . . . . . . 45 5.3.11. extendedRequest and extendedResponse . . . . . . . . 45
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50
6. A complete example of the CCMP in action . . . . . . . . . . 54 6. A complete example of the CCMP in action . . . . . . . . . . 53
6.1. Alice retrieves the available blueprints . . . . . . . . 55 6.1. Alice retrieves the available blueprints . . . . . . . . 54
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 59 operation . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4. Alice updates conference information . . . . . . . . . . 62 6.4. Alice updates conference information . . . . . . . . . . 61
6.5. Alice inserts a list of users in the conference object . 63 6.5. Alice inserts a list of users in the conference object . 63
6.6. Alice joins the conference . . . . . . . . . . . . . . . 65 6.6. Alice joins the conference . . . . . . . . . . . . . . . 65
6.7. Alice adds a new user to the conference . . . . . . . . . 67 6.7. Alice adds a new user to the conference . . . . . . . . . 67
6.8. Alice asks for the CCMP server capabilities . . . . . . . 69 6.8. Alice asks for the CCMP server capabilities . . . . . . . 69
6.9. Alice exploits a CCMP server extension . . . . . . . . . 72 6.9. Alice exploits a CCMP server extension . . . . . . . . . 72
7. Locating a Conference Control Server . . . . . . . . . . . . 75 7. Locating a Conference Control Server . . . . . . . . . . . . 74
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 80 contacted . . . . . . . . . . . . . . . . . . . . . . . . 80
10.2. User Authentication and Authorization . . . . . . . . . . 81 10.2. User Authentication and Authorization . . . . . . . . . . 80
10.3. Security and Privacy of Identity . . . . . . . . . . . . 82 10.3. Security and Privacy of Identity . . . . . . . . . . . . 82
10.4. Mitigating DoS Attacks . . . . . . . . . . . . . . . . . 83 10.4. Mitigating DoS Attacks . . . . . . . . . . . . . . . . . 83
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 83 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 83
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 101 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 101
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 102 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 102
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 102 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 102
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 103 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 103
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 104 Application Service Tag . . . . . . . . . . . . . . . 104
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 104 Application Protocol Tag for CCMP . . . . . . . . . . 104
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 104 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 104
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 105 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 105
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 107 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 107
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 109 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 109
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 109
14.1. Normative References . . . . . . . . . . . . . . . . . . 109 14.1. Normative References . . . . . . . . . . . . . . . . . . 109
14.2. Informative References . . . . . . . . . . . . . . . . . 110 14.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Evaluation of other protocol models
considered for CCMP . . . . . . . . . . . . . . . . 111 and transports considered for CCMP . . . . . . . . 111
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 112 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 112
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 112 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON Framework introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing the current
state and capabilities of a conference. state and capabilities of a conference.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
"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 additon to the terms defined in the Framework for Centralized
Conferencing [RFC5239], this document uses the following terms and Conferencing [RFC5239], this document uses the following terms and
acronyms: acronyms:
XCON aware client: An XCON conferencing system client which is able XCON aware client: An XCON conferencing system client which is able
to issue CCMP requests. to issue CCMP requests.
First-Party: A request issued by the client to manipulate their own First-Party Request: A request issued by the client to manipulate
conferencing data. their own conferencing data.
Third-Party: 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.
........................................................ ........................................................
skipping to change at page 6, line 45 skipping to change at page 6, line 45
. | Conference | . . | Conference | .
. | Control | . . | Control | .
. | Client | . . | Client | .
. +----------------+ . . +----------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
........................................................ ........................................................
Figure 1: Conference Client Interaction Figure 1: Conference Client Interaction
CCMP serves as the Conference Control Protocol, allowing the The Centralized Conferencing Manipulation Protocol (CCMP) allows the
conference control client to interface with the conference object conference control client to interface with the conference object
maintained by the conferencing system, as represented in Figure 1. maintained by the conferencing system, as depicted in Figure 1. Note
Conference Control is one part of functionality for advanced that additional functionality of the Conference Control Client and
conferencing supported by a conferencing client. Other functions are Conferencing System is discussed in the XCON framework and related
discussed in the XCON framework and related documents. documents.
Conference object and conference users do represent key elements This section provides details of the identifiers REQUIRED to address
involved in Conference Control Protocol operations. Their and manage the clients associated with a conferencing system using
identifiers, respectively the conference XCON-URI and the the CCMP.
conferencing client XCON-USERID, and their XML representations
compliant with the XML Schema defined in the XCON data model are
widely used for creating the CCMP requests and responses. The main
conference objects and users features envisioned by the XCON
framework are briefly described in the following subsections.
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
"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
skipping to change at page 8, line 48 skipping to change at page 8, line 43
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. The CCMP does not maintain user's subscriptions at
the conference server; hence, it does not provide any specific the conference server; hence, it does not provide any specific
mechanism allowing clients to register their conferencing accounts. mechanism allowing clients to register their conferencing accounts.
The "subject" parameter is just used for carrying authentication data The "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, which has been CCMP is a client-server, XML-based protocol for user creation,
specifically conceived to provide users with the necessary means for retrieval, modification and deletion of conference objects. CCMP is
the creation, retrieval, modification and deletion of conference a stateless protocol, such that implementations can safely handle
objects. CCMP is also state-less, which means implementations can transactions independently from each other. CCMP messages are XML
safely handle transactions independently from each other. documents or XML document fragments compliant with the XCON data
Conference-related information is encapsulated into CCMP messages in model representation [I-D.ietf-xcon-common-data-model].
the form of XML documents or XML document fragments compliant with
the XCON data model representation.
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 in the 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 is
atomic and either succeeds or fails as a whole. The conference 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 conference client completes prior to
another client's operation on the same conference object. While the another client's operation on the same conference object. While the
details for this data locking functionality are out of scope for the details for this data locking functionality are out of scope for the
CCMP protocol specification and are implementation specific for a CCMP protocol 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 the 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 the CCMP need to comply
with the XCON data model, there are situations in which the values with the XCON data model, there are situations in which the values
for mandatory elements are unknown by the client. The mechanism for 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 has been conceived as completely independent from underlying CCMP is completely independent from underlying protocols, which means
protocols, which means that there can be different ways to carry CCMP that there can be different ways to carry CCMP messages from a
messages across the network, from a conferencing client to a conferencing client to a conferencing server. The specification
conferencing server. The specification recommends the use of HTTP as describes the use of HTTP as a transport solution, including CCMP
a transport solution, including CCMP requests in HTTP POST messages requests in HTTP POST messages and CCMP responses in HTTP 200 OK
and CCMP responses in HTTP 200 OK replies. This implementation replies. This implementation approach is further described in
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, a conference user, a create: for the creation of a conference object, a conference user,
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 or a blueprint, or a
sidebar) or a conference user. A retrieve operation can also be sidebar) or a conference user. A retrieve operation can also be
used to obtain the XCON-URIs of the current conferences (active or used to obtain the XCON-URIs of the current conferences (active or
registered) handled by the conferencing server and/or the registered) handled by the conferencing server and/or the
available blueprints. available blueprints.
update: to modify the current features of a specified conference or update: to modify the current features of a specified conference or
conference user. conference user.
skipping to change at page 10, line 32 skipping to change at page 10, line 28
elements of <sidebars-by-ref>), elements of <sidebars-by-ref>),
o <user> elements associated with conference users, o <user> elements associated with conference users,
o the list of XCON-URIs related to conferences and blueprints o the list of XCON-URIs related to conferences and blueprints
available at the server, for which only retrieval operations are available at the server, for which only retrieval operations are
allowed. allowed.
4.2. Data Management 4.2. Data Management
In order to ensure the integrity of the data, the conference server The XCON Framework defines a model whereby the conference server
first checks all the parameters, before making any changes to the centralizes and maintains the conference information. Since multiple
internal representation of the conference object. For example, it clients can modify the same conference objects a conference client
would be undesirable to change the <subject> of the conference, but might not have the latest version of a specific conference object
then detect an invalid URI in one of the <service-uris> and abort the when they initiate operations. To determine whether the client has
remaining updates. Also, since multiple clients can modify the same the most up to date conference information, a versioning approach is
conference objects, conference clients should first obtain the defined for the CCMP. Each conference object is associated with a
current object from the conference server and then update the version number. All CCMP response messages containing a conference
relevant data elements in the conference object prior to invoking a document (or a fragment thereof) MUST contain a "version" parameter.
specific operation on the conference server. When a client sends an update message to the server, which includes
modifications to a conference object, if the modifications are all
In order to effectively manage modifications to conference data, a successfully applied, the server MUST return a "200" response
versioning approach is provided by the CCMP. Specifically, each containing the version number of the modified object. With this
conference object is associated with a version number indicating the
most up to date view of the conference at the server's side. The
version number is reported to the clients when answering their
requests. A client willing to make modifications to a conference
object has to send an update message to the server. If the
modifications are all successfully applied, the server sends back to
the client a "200" response which also carries information about the
current server-side version of the modified object. With this
approach, a client working on version "X" of a conference object that approach, a client working on version "X" of a conference object that
finds a "200" response with a version number which is "X+1" can be receives a "200" response with a version number which is "X+1" can be
sure that the version it was aware of was the most up to date. On certain that the version it manipulated was the most up to date.
the other hand, if the "200" response contains a version which is at However, if the "200" response contains a version which is at least
least "X+2", the client can detect that the object that has been "X+2", the client knows that the object modified by the server was
modified at the server's side was more up to date than the one it was more up to date than the object the client was manipulating. In
working upon. This is clearly due to the effect of concurrent order to ensure that the client always has the latest version of the
modification requests issued by independent clients. Hence, for the modified object, the client can send a "retrieve" request to the
sake of having available the latest version of the modified object, conference server. The client can then update the relevant data
the client can send to the conference server a further "retrieve" elements in the conference object prior to invoking a specific
request. In the case that a copy of the conference object is not operation. Note that a client subscribed to the XCON event package
returned to the client as part of the update response message, the
client can always obtain a copy through an ad-hoc "retrieve" message.
Based on the above considerations, all CCMP response messages
containing a conference document (or a fragment of it) MUST contain a
"version" parameter. The "version" parameter is not REQUIRED for
requests, since it represents useless information for the server: as
long as the required modifications can be applied to the target
conference object with no conflicts, the server does not care whether
the client has stored an up to date view of the information.
However, a client subscribed to the XCON event package
[I-D.ietf-xcon-event-package] notifications about conference object [I-D.ietf-xcon-event-package] notifications about conference object
modifications, will always have the most up to date version of that modifications, will receive the most up to date version of that
object. object upon receipt of a notification.
The "version" parameter is OPTIONAL for requests, since it is not
needed by the server: as long as the required modifications can be
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
information. In addition, to ensure the integrity of the data, the
conference server first checks all the parameters, before making any
changes to the internal representation of the conference object. For
example, it would be undesirable to change the <subject> of the
conference, but then detect an invalid URI in one of the <service-
uris> and abort the remaining updates.
4.3. Data Model Compliance 4.3. Data Model Compliance
The XCON data model identifies some elements/attributes as mandatory. The XCON data model [I-D.ietf-xcon-common-data-model] identifies some
Since the XML documents carried in the CCMP need to be compliant with elements/attributes as mandatory. Since the XML documents carried in
the XCON data model, there can be a problem in cases of client- the body of the CCMP requests/responses need to be compliant with the
initiated operations, like the creation/update of conference objects. XCON data model, there can be a problem in cases of client-initiated
In such cases, not all of the mandatory data can be known in advance operations, such as the initial creation of conference objects and
to the client issuing a CCMP request. As an example, a client has no cases whereby a client updates a conference object adding new
means to know, at the time it issues a conference creation request, elements, such as a new user. In such cases, not all of the
the XCON-URI that the server will assign to the yet-to-be-created mandatory data can be known in advance to the client issuing a CCMP
conference and hence it is not able to appropriately fill with that request. As an example, a client has no means to know, at the time
value the mandatory "entity" attribute of the conference document it issues a conference creation request, the XCON-URI that the server
contained in the request. To solve this issue, the CCMP client fills will assign to the yet-to-be-created conference and hence it is not
all mandatory data model fields, for which no value is available at able to appropriately fill with that value the mandatory "entity"
the time the request is constructed, with fake values in the form of attribute of the conference document contained in the request. To
a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a solve this issue, the CCMP client fills all mandatory data model
unique numeric index for each data model field for which the value is fields, for which no value is available at the time the request is
unknown. This form of wildcard string is chosen, rather than the use constructed, with fake values in the form of a wildcard string,
of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for AUTO_GENERATE_X (all uppercase), with X being a unique numeric index
X, to simplify processing at the server. The values of for each data model field for which the value is unknown. This form
AUTO_GENERATE_X are only unique within the context of the specific of wildcard string is chosen, rather than the use of random unique
request. The fake AUTO_GENERATE_X values MUST be within the value strings (e.g, FOO_BAR_LA) or non-numeric values for X, to simplify
part of an attribute/element (e.g., <userinfo entity= processing at the server. The values of AUTO_GENERATE_X are only
unique within the context of the specific request. The fake
AUTO_GENERATE_X values MUST be within the value part of an attribute/
element (e.g., <userinfo entity=
"xcon-userid:AUTO_GENERATE_1@example.com">). "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 respond with an error 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
skipping to change at page 12, line 32 skipping to change at page 12, line 26
(e.g., AUTO_GENERATE_1) with the same identifier. The (e.g., AUTO_GENERATE_1) with the same identifier. The
identifiers MUST be unique for each instance of AUTO_GENERATE_X identifiers MUST be unique for each instance of AUTO_GENERATE_X
within the same XML document received in the request - e.g., the within the same XML document received in the request - e.g., the
value that replaces AUTO_GENERATE_1 MUST NOT be the same as the value that replaces AUTO_GENERATE_1 MUST NOT be the same as the
value that replaces AUTO_GENERATE_2. Note that the values that value that replaces AUTO_GENERATE_2. Note that the values that
replace the instances of AUTO_GENERATE_X are not the same across replace the instances of AUTO_GENERATE_X are not the same across
all conference objects - e.g., different values can be used to all conference objects - e.g., different values can be used to
replace AUTO_GENERATE_1 in two different documents. 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 has (have) been replaced by the newly created in the request have been replaced by the newly created one(s).
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 which is one of the main conference objects at the server's side. Note that the use of this
goals of the CCMP protocol. mechanism could be avoided in come cases by using multiple
operations, such as creating a new user and then adding the new user
to an existing conference. However, the AUTO_GENERATE_X mechanism
allows a single operation to be used to effect the same change on the
conference object.
4.4. Implementation Approach 4.4. Implementation Approach
There have been a number of different proposals as to the most CCMP is implemented using HTTP, placing the CCMP request messages
suitable implementation solution for the CCMP. A non-exhaustive into the body of an HTTP POST operation and placing the CCMP
summary of the most interesting ones is provided in Appendix A. The responses into the body of the HTTP response messages. A non-
solution for the CCMP defined in this document is viewed as a good exhaustive summary of the other approaches that were considered and
compromise amongst the most notable past candidates and is referred the perceived advantages of the HTTP solution described in this
to as "HTTP single-verb transport plus CCMP body". With this document are provided in Appendix A.
approach, CCMP is able to take advantage of existing HTTP
functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
transport (i.e. a single transaction type for each request/response
pair); this allows decoupling CCMP messages from HTTP messages.
Similarly, as with any RESTful approach, CCMP messages are inserted
directly in the body of HTTP messages, thus avoiding any unnecessary
processing and communication burden associated with further
intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport
protocol. The remainder of this document focuses on the selected
approach.
The CCMP protocol inserts XML-based CCMP requests into the body of Most CCMP commands can pend indefinitely, thus increasing the
HTTP POST operations and retrieves responses from the body of HTTP potential that pending requests can continue to increase when a
"200 OK" messages. Most CCMP commands can pend indefinitely, thus server is receiving more requests than it can process within a
increasing the potential that pending requests can continue to specific time period. In this case a server SHOULD return a 510
increase when a server is receiving more requests than it can process response code to the pending requests. In addition, to mitigate the
within a specific time period. In this case a server SHOULD return a situation clients MUST NOT wait indefinitely for a response and MUST
510 response code to the pending requests. In addition, to mitigate implement a timer such that when it expires, the client MUST close
the situation clients MUST NOT wait indefinitely for a response and the connection. Thirty seconds is RECOMMENDED as the default value
MUST implement a timer (in the range of seconds) such that when it for this timer. Sixty seconds is considered a reasonable upper
expires, the client MUST close the connection. Note, that there may range. Note, that there may be cases where a response message is
be cases where a response message is lost and a request has been lost and a request has been successful (e.g., user added to a
successful (e.g., user added to a conference), yet the client will be conference), yet the client will be unaware and close the connection.
unaware. However, as described in Section 4.2, there is a versioning However, as described in Section 4.2, there is a versioning mechanism
mechanism for the conference objects, thus there is a mechanism for for the conference objects, thus there is a mechanism for the
the conference object stored by the client to be brought up to date. 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" 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 the CCMP.
skipping to change at page 14, line 5 skipping to change at page 13, line 36
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 which 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 username and password of
the client registered at the conferencing system. Each user who the client registered at the conferencing system. Each user who
subscribes to the conferencing system is assumed to be equipped subscribes to the conferencing system is assumed to be equipped
with those credentials and SHOULD enclose them in each CCMP with those credentials and SHOULD enclose them in each CCMP
request she issues. These fields can be used to control that the request she issues. These fields can be used to control that the
user sending the CCMP request has the authority to perform the user sending the CCMP request has the authority to perform the
entailed operation. The same fields can also be exploited to entailed operation. The same fields can also be exploited to
carry out other Authorization, Authentication and Accounting (AAA) carry out other authorization and authentication procedures.
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 conferencing server at each conferencing client
who interacts with it. The "confUserID" parameter is REQUIRED in who interacts with it. The "confUserID" parameter is REQUIRED in
the CCMP request and response messages with the exception of the the CCMP request and response messages with the exception of the
case of a user who has no XCON-USERID and who wants to enter, via case of a user who has no XCON-USERID and who wants to enter, via
CCMP, a conference whose identifier is known. In such case, a CCMP, a conference whose identifier is known. In such case, a
side-effect of the request is that the user is provided with an side-effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 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: An OPTIONAL parameter that MUST be inserted in
all requests whose target conference object is password-protected all requests whose target conference object is password-protected
(as per the <conference-password> element in (as per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]). [I-D.ietf-xcon-common-data-model]). A CCMP response code of "423"
MUST be returned if a conference-password is not included in the
request when required.
specialized request message: This is specialization of the generic specialized request message: This is specialization of the generic
request message (e.g., blueprintsRequest), containing parameters request message (e.g., blueprintsRequest), containing parameters
that are dependent on the specific request sent to the server. A that are dependent on the specific request sent to the server. A
specialized request message MUST be included in the CCMP request specialized request message MUST be included in the CCMP request
message. The details for the specialized messages and associated message. The details for the specialized messages and associated
parameters are provided in Section 5.3. parameters are provided in Section 5.3.
<!-- Definition of CCMP Request --> <!-- Definition of CCMP Request -->
skipping to change at page 15, line 45 skipping to change at page 15, line 45
</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 mandatory 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 who issued
the CCMP request message. the CCMP request message.
confObjID: An optional parameter containing the XCON-URI of the confObjID: An OPTIONAL parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter for CCMP response messages. This operation: An OPTIONAL parameter for CCMP response messages. This
parameter is REQUIRED in all responses except for the parameter is REQUIRED in all responses except for the
"blueprintsResponse" and "confsResponse" specialized messages. "blueprintsResponse" and "confsResponse" specialized messages.
response-code: A mandatory parameter containing the response code response-code: A 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, such 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. element related to that conference. This parameter is REQUIRED in
CCMP response messages and SHOULD NOT be included in CCMP request
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). A
specialized response message SHOULD be included in the CCMP specialized response message SHOULD be included in the CCMP
response message, except in an error situation where the CCMP response message, except in an error situation where the CCMP
request message did not contain a valid specialized message. In request message did not contain a valid specialized message. In
this case, the conference server MUST return a "response-code" of this case, the conference server MUST return a "response-code" of
"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.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
9. sidebarByValRequest/sidebarByValResponse 9. sidebarByValRequest/sidebarByValResponse
10. sidebarByRefRequest/sidebarByRefResponse 10. sidebarByRefRequest/sidebarByRefResponse
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. The as defined in Section 4.1 to manipulate the conference data. These
optionsRequest/optionsResponse message pair deserves a specific request/response pairs are included in an IANA registry as defined in
discussion, since it is not used for manipulating information about Section 12.5. Table 1 summarizes the remaining CCMP operations and
either conferences or conference users, but rather to retrieve corresponding actions that are valid for a specific CCMP request
general information about conference server capabilities, in terms of type, noting that neither the blueprintsRequest/blueprintsResponse
standard CCMP messages it supports, plus potential extension messages nor confsRequest/confsResponse require an "operation" parameter. The
it understands, as it will be further explained in Section 5.3.12. corresponding response MUST contain the same operation. Note that
Table 1 summarizes the remaining CCMP operations and corresponding some entries are labeled "N/A" indicating the operation is invalid
actions that are valid for a specific CCMP request type, noting that for that request type. In the case of an "N/A*", the operation MAY
neither the blueprintsRequest/blueprintsResponse nor confsRequest/ be allowed for specific privileged users or system administrators,
confsResponse require an "operation" parameter. The corresponding but is not part of the functionality included in this document.
response MUST contain the same operation. Note that some entries are
labeled "N/A" indicating the operation is invalid for that request
type. In the case of an "N/A*", the operation MAY be allowed for
specific privileged users or system administrators, but is not part
of the functionality included in this document.
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | 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 | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
skipping to change at page 20, line 22 skipping to change at page 20, line 22
Additional parameters included in the specialized CCMP request/ Additional parameters included in the specialized CCMP request/
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 400 response code 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 XCON-URIs associated with the available blueprints from the of XCON-URIs associated with the available blueprints from the
conference server. Such URIs can be subsequently used by the client conference server. These XCON-URIs can be subsequently used by the
to access detailed information about a specified blueprint with a client to access detailed information about a specified blueprint
specific blueprintRequest message per Section 5.3.3. The with a specific blueprintRequest message per Section 5.3.3.
"confUserID" parameter MUST be included in every blueprintsRequest/
Response message and reflect the XCON-USERID of the conferencing The "confUserID" parameter MUST be included in every
client issuing the request. A blueprintsRequest message REQUIRES no blueprintsRequest/Response message and reflect the XCON-USERID of the
"confObjID" and "operation" parameters, since it is not targetted to conferencing client issuing the request. Since a blueprintsRequest
a specific conference instance and it is conceived as a "retrieve- message is not targetted to a specific conference instance and is a
only" request. In order to obtain a specific subset of the available "retrieve-only" request, the "confObjID" and "operation" MUST NOT be
blueprints, a client may specify a selection filter providing an included in the blueprintsRequest/Response messages.
appropriate xpath query in the optional "xpathFilter" parameter of
the request. For example, to select blueprints having both audio and In order to obtain a specific subset of the available blueprints, a
video stream support, a possible xpathFilter value could be: "/ client may specify a selection filter providing an appropriate xpath
conference-info[conference-description/available-media/entry/ query in the OPTIONAL "xpathFilter" parameter of the request. The
type='audio' and conference-description/available-media/entry/ information in the blueprints typically represents general
type='video']". capabilities and characteristics. For example, to select blueprints
having both audio and video stream support, a possible xpathFilter
value could be: "/conference-info[conference-description/
available-media/entry/type='audio' and conference-description/
available-media/entry/type='video']". A conference server SHOULD NOT
provide any sensitive information (e.g., passwords) in the
blueprints.
The associated "blueprintsResponse" message SHOULD contain, as shown The associated "blueprintsResponse" message SHOULD contain, as shown
in Figure 4, a "blueprintsInfo" parameter containing the above in Figure 4, a "blueprintsInfo" parameter containing the above
mentioned XCON-URI list. mentioned 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>
</xs:complexType> </xs:complexType>
<!-- blueprintsRequestType --> <!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/> <xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="blueprintsRequestType"> <xs:complexType name="blueprintsRequestType">
skipping to change at page 22, line 19 skipping to change at page 22, line 21
currently handled by the conferencing system. The "confUserID" currently handled by the conferencing system. The "confUserID"
parameter MUST be included in every confsRequest/Response message and parameter MUST be included in every confsRequest/Response message and
reflect the XCON-USERID of the conferencing client issuing the reflect the XCON-USERID of the conferencing client issuing the
request. The "confObjID" parameter MUST NOT be included in the request. The "confObjID" parameter MUST NOT be included in the
confsRequest message. The "confsRequest" message is of a "retrieve- confsRequest message. The "confsRequest" message is of a "retrieve-
only" type, since the sole purpose is to collect information only" type, since the sole purpose is to collect information
available at the conference server. Thus, an "operation" parameter available at the conference server. Thus, an "operation" parameter
MUST NOT be included in a "confsRequest" message. In order to MUST NOT be included in a "confsRequest" message. In order to
retrieve a specific subset of the available conferences, a client may retrieve a specific subset of the available conferences, a client may
specify a selection filter providing an appropriate xpath query in specify a selection filter providing an appropriate xpath query in
the optional "xpathFilter" parameter of the request. For example, to the OPTIONAL "xpathFilter" parameter of the request. For example, to
select only the registered conferences, a possible xpathFilter value select only the registered conferences, a possible xpathFilter value
could be: "/conference-info[conference-description/conference-state/ could be: "/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">
skipping to change at page 26, line 20 skipping to change at page 26, line 26
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 transporting the created
conference document MAY be included, at the discretion of the conference document MAY be included, at the discretion of the
conferencing system implementation, along with an optional version conferencing system implementation, along with the REQUIRED "version"
parameter initialized at "1", since at creation time the conference parameter initialized at "1", since at creation time the conference
object is at its first version. object is at its first version.
In the case of a confRequest with a "retrieve" operation, the In the case of a confRequest with a "retrieve" operation, the
"confObjID" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included and the "confInfo" parameter MUST NOT be included in the be included and the "confInfo" parameter MUST NOT be included in the
request. The conferencing server MUST ignore any "confInfo" request. The conferencing server MUST ignore any "confInfo"
parameter that is received in a confRequest/retrieve. If the parameter that is received in a confRequest/retrieve. If the
confResponse for the "retrieve" operation contains a "response-code" confResponse for the "retrieve" operation contains a "response-code"
of "200", the "confInfo" parameter MUST be included in the response. of "200", the "confInfo" parameter MUST be included in the response.
skipping to change at page 27, line 28 skipping to change at page 27, line 28
<confInfo entity="xcon:8977777@example.com"> <confInfo entity="xcon:8977777@example.com">
<conference-description> <conference-description>
<display-text/> <display-text/>
</conference-description> </conference-description>
</confInfo> </confInfo>
Figure 8: Updating a conference object: removing the title of a Figure 8: Updating a conference object: removing the title of a
conference conference
In the case of a confResponse/update with a response-code of "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 not mandatory. A following means the return of 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 aspect of the conference upon the modification, or the
Notification Protocol might address that task as well. A "200" Notification Protocol might address that task as well. A "200"
response-code indicates that the referenced conference document has response-code indicates that the conference object has been changed
been changed accordingly to the request by the conferencing server. accordingly to the request by the conferencing server. The "version"
The "version" parameter MUST be enclosed in the confResponse/update parameter MUST be enclosed in the confResponse/update message, in
message, in order to let the client understand what is the actual order to let the client understand what is the actual current
current conference-object version, upon the applied modifications. conference-object version, upon the applied modifications. An "409"
An "409" response-code indicates that the changes reflected in the response-code indicates that the changes reflected in the request
request "confInfo" are not feasible. This could be due to policies, "confInfo" are not feasible. This could be due to policies,
requestor roles, specific privileges, unacceptable values etc., with requestor roles, specific privileges, unacceptable values etc., with
the reason specific to a conferencing system and its configuration. the reason specific to a conferencing system and its configuration.
Together with the "409" response-code, the "version" parameter MUST Together with the "409" response-code, the "version" parameter MUST
be attached in the confResponse/update, by this way allowing the be attached in the confResponse/update, by this way allowing the
client to eventually retrieve the current version of the target client to eventually retrieve the current version of the target
conference if the one she attempted to modify was not the most up-to- conference if the one she attempted to modify was not the most up-to-
date. date.
In the case of a confRequest with a "delete" operation, the In the case of a confRequest with a "delete" operation, the
"confObjID" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
skipping to change at page 29, line 39 skipping to change at page 29, line 39
<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
Through a "usersRequest" message the CCMP client manipulates the XML The "usersRequest" message allows a client to manipulate the <users>
<users> element of the conference document associated with the element of the conference object represented by the "confObjID". The
conference identified by the "confObjID" parameter complusory <users> element contains the list of <user> elements associated with
included in the request. Inside the <users> element, along with the conference participants, the list of the users to which access to the
list of <user> elements associated with conference participants, conference is allowed/denied, conference participation policies, etc.
there is information that the client may be interested in The "confObjID" MUST be included in a "usersRequest" message.
controlling, such the list of the users to which access to the
conference is allowed/denied, conference participation policies,
etc.; for this reason, a customized message has been designed to
allow for the manipulation of this specific part of a conference
document.
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
skipping to change at page 32, line 13 skipping to change at page 32, line 8
"operation" parameter, and MAY include a "userInfo" parameter "operation" parameter, and MAY include a "userInfo" parameter
containing the detailed user's information depending upon the containing the detailed user's information depending upon the
operation and whether the "userInfo" has already been populated for a operation and whether the "userInfo" has already been populated for a
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
AAA checks), like creating a conference, retrieving conference authorization and authentication checks), like creating a conference,
information, etc.. retrieving conference information, etc..
Conference users can be created in a number of different ways. In Conference users can be created in a number of different ways. In
each of these cases the operation MUST be set to "create" in the each of these cases the operation MUST be set to "create" in the
userRequest message. Each of the userResponse messages for these userRequest message. Each of the userResponse messages for these
cases MUST include the "confObjID", "confUserID", "operation" and cases MUST include the "confObjID", "confUserID", "operation" and
"response-code" parameters. In the case of a response code of "200", "response-code" parameters. In the case of a response code of "200",
the userResponse message MAY include the "userInfo" parameter the userResponse message MAY include the "userInfo" parameter
depending upon the manner in which the user was created: depending upon the manner in which the user was created:
o Conferencing client with an XCON-USERID adds itself to the o Conferencing client with an XCON-USERID adds itself to the
skipping to change at page 47, line 4 skipping to change at page 46, line 40
<xs:complexType name="extendedResponseType"> <xs:complexType name="extendedResponseType">
<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 extendedResponse
messages messages
5.3.12. optionsRequest and optionsResponse 5.3.12. optionsRequest and optionsResponse
An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e. The "optionsRequest" (Figure 18) message is used to retrieve general
it does not represent a specialization of the general CCMP request. information about conference server capabilities. These capabilities
It allows a CCMP client to become aware of CCMP server capabilities include the standard CCMP messages (request/response pairs) and
in terms of CCMP supported messages. potential extension messages supported by the conference server. As
such it is a basic CCMP message, rather than a specialization of the
general 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 messages as defined in this specification. list of the supported CCMP message pairs as defined in this
These messages are in the form of a list, <standard-message-list> specification. These messages are in the form of a list, <standard-
including each of the supported messages as reflected by <standard- message-list> including each of the supported messages as reflected
message> elements. The "optionsResponse" message also allows for an by <standard-message> elements. The "optionsResponse" message also
<extended-message-list>, which is a list of additional message types allows for an <extended-message-list>, which is a list of additional
in the form of <extended-message-list> elements that are currently message types in the form of <extended-message-list> elements that
undefined, to allow for future extensibility. The following are currently undefined, to allow for future extensibility. The
information is provided for both types of messages: following information is provided for both types of messages:
o <name> (mandatory): 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 ten 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 CRUD operation supported by the
server for the message. If this optional element is absent, the server for the message. If this element is absent, the client
client SHOULD assume the server is able to handle the entire set SHOULD assume the server is able to handle the entire set of CRUD
of CRUD operations or, in case of standard messages, all the operations or, in case of standard messages, all the operations
operations envisioned for that message in this document. 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 further 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 homologous 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 at least one of the standard server is required to be able to handle at least one of the standard
messages for at least one of the operations. messages for at least one of the operations.
skipping to change at page 50, line 34 skipping to change at page 50, line 24
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 optionsResponse
messages messages
5.4. CCMP Response Codes 5.4. CCMP Response Codes
All CCMP response messages MUST include a ""response-code"". The All CCMP response messages MUST include a "response-code". This
following summarizes the CCMP response codes: document defines an IANA registry for the CCMP response codes as
described in Section 12.5.2. The following summarizes the CCMP
response codes:
200 Success: Successful completion of the requested operation. 200 Success: Successful completion of the requested operation.
400 Bad Request: Syntactically malformed request. 400 Bad Request: Syntactically malformed request.
401 Unauthorized: User not allowed to perform the required 401 Unauthorized: User not allowed to perform the required
operation. operation.
403 Forbidden: Operation not allowed (e.g., cancellation of a 403 Forbidden: Operation not allowed (e.g., cancellation of a
blueprint). blueprint).
skipping to change at page 52, line 25 skipping to change at page 52, line 13
adding a new user fails because the max number of users has been 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 conference or the max number of users has been
reached for the conferencing system. reached for the conferencing system.
The handling of a "response-code" of "404", "409", "420", "421", The handling of a "response-code" of "404", "409", "420", "421",
"425", "426" and "427" are only applicable to specific operations for "425", "426" and "427" are 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 code | Create | Retrieve | Update | Delete | | Response | Create | Retrieve | Update | Delete |
+---------------+------------+------------+------------+------------+ | code | | | | |
| 404 | userReques | All | All update | All delete | +----------+-------------+--------------+-------------+-------------+
| | t, | retrieve | requests | requests | | 404 | userRequest | All retrieve | All update | All delete |
| | sidebarBy | requests, | | | | | sidebarBy | requests | requests | requests |
| | ValRequest | EXCEPT: | | | | | ValRequest, | EXCEPT: | | |
| | sidebars | blueprints | | | | | sidebarsBy | blueprints | | |
| | ByRefReque | Request, | | | | | RefRequest | Request, | | |
| | st | confsRequ | | | | | | confsRequest | | |
| | | est | | | | -------- | ----------- | ------------ | ----------- | ----------- |
| ------------- | ---------- | ---------- | ---------- | ---------- | | | - | | | |
| 409 | N/A | N/A | All update | N/A | | 409 | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | -------- | ----------- | ----------- | ----------- | ----------- |
| 420 | userReques | userReques | userReques | userReques | | 420 | userRequest | userRequest | userRequest | userRequest |
| | t(3rd part | t | t | t | | | (3rd party | | | |
| | yinvite | | | | | | invite with | | | |
| | with thir | | | | | | third user | | | |
| | duser | | | | | | entity) (*) | | | |
| | entity) | | | | | -------- | ----------- | ----------- | ----------- | ----------- |
| | (*) | | | | | 421 | All create | All retrieve | All update | All delete |
| ------------- | ---------- | ---------- | ---------- | ---------- | | | requests | requests | requests | requests |
| 421 | All create | All | All update | All delete | | | EXCEPT: | | | |
| | requests, | retrieve | requests | requests | | | userRequest | | | |
| | EXCEPT: | requests | | | | | with no | | | |
| | userReques | | | | | | confUserID | | | |
| | twith no | | | | | | (**) | | | |
| | confUserI | | | | | -------- | ----------- | ----------- | ----------- | ----------- |
| | D(**) | | | | | 425 | N/A | N/A | N/A | All delete |
| ------------- | ---------- | ---------- | ---------- | ---------- | | | | | | request |
| 425 | N/A | N/A | N/A | All delete | | -------- | ----------- | ----------- | ----------- | ----------- |
| | | | | request | | 426 | N/A | N/A | All update | N/A |
| ------------- | ---------- | ---------- | ---------- | ---------- | | | | | requests | |
| 426 | N/A | N/A | All update | N/A | | -------- | ----------- | ----------- | ----------- | ----------- |
| | | | requests | | | 427 | ConfRequest | N/A | All update | N/A |
| 427 | ConfReques | N/A | All update | N/A | | | UserRequest | | requests | |
| | t, | | requests | | +----------+-------------+--------------+-------------+-------------+
| | UserReque | | | |
| | st | | | |
+---------------+------------+------------+------------+------------+
Table 2: Response codes and associated operations Table 2: Response codes and associated operations
(*) "420" in answer to a "userRequest/create" operation: in the case (*) "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" of the sender of the request that is
invalid, a "421" error code is returned to the client. invalid, a "421" error code is returned to the client.
(**) "421" is not sent in answers to "userRequest/create" messages (**) "421" is not sent in answers to "userRequest/create" messages
skipping to change at page 54, line 16 skipping to change at page 53, line 45
client in the same manner as a "500" "response-code", the handling of client in the same manner as a "500" "response-code", the handling of
which is specific to the conference control client implementation. which is specific to the conference control client implementation.
6. A complete example of the CCMP in action 6. A complete example of the CCMP in action
In this section a typical, not normative, scenario in which the CCMP In this section a typical, not normative, scenario in which the 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 Conference Control Client is a CCMP-enabled client, whereas the
Conference Control Server is a CCMP-enabled server. The "confUserID" Conference Control Server is a CCMP-enabled server. The "confUserID"
of the client, Alice, is "xcon-userid:Alice@example.com" and appears of the client, Alice, is "xcon-userid:alice@example.com" and appears
in all requests. The sequence of operations is as follows: in all requests. The sequence of operations is as follows:
1. Alice retrieves from the server the list of available blueprints 1. Alice retrieves from the server the list of available blueprints
(Section 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);
skipping to change at page 55, line 40 skipping to change at page 55, line 22
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintsRequest message: 1. blueprintsRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <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-blueprints-request-message-type"> xsi:type="ccmp:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<ccmp:blueprintsRequest/> <ccmp:blueprintsRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintsResponse message form the server:
2. blueprintsResponse 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 <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code> <response-code>200</response-code>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri> <info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room: <info:purpose>Simple Room:
conference room with public access, conference room with public access,
where only audio is available, more users where only audio is available, more users
can talk at the same time can talk at the same time
skipping to change at page 57, line 41 skipping to change at page 57, line 22
In this case, Alice, who now knows the XCON-URIs of the blueprints In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about CCMP "blueprintRequest" message, to get detailed information about
one of them (the one called with XCON-URI one of them (the one called with XCON-URI
"xcon:AudioRoom@example.com"). The picture shows such transaction. "xcon:AudioRoom@example.com"). The picture shows such transaction.
Notice that the response contains, in the "blueprintInfo" parameter, Notice that the response contains, in the "blueprintInfo" parameter,
a document compliant with the standard XCON data model. a document compliant with the standard XCON data model.
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 form 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> <info:display-text>audio stream</info:display-text>
audio stream <info:type>audio</info:type>
</info:display-text> </info:entry>
<info:type>audio</info:type> </info:available-media>
</info:entry> </info:conference-description>
</info:available-media> <info:users>
</info:conference-description> <xcon:join-handling>allow</xcon:join-handling>
<info:users> </info:users>
<xcon:join-handling>allow</xcon:join-handling> <xcon:floor-information>
</info:users> <xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:floor-information> <xcon:conference-floor-policy>
<xcon:floor-request-handling>confirm <xcon:floor id="audioFloor">
</xcon:floor-request-handling> <xcon:media-label>audioLabel</xcon:media-label>
<xcon:conference-floor-policy> </xcon:floor>
<xcon:floor id="audioFloor"> </xcon:conference-floor-policy>
<xcon:media-label> </xcon:floor-information>
audioLabel </blueprintInfo>
</xcon:media-label> </ccmp:blueprintResponse>
</xcon:floor>
</xcon:conference-floor-policy> </ccmpResponse>
</xcon:floor-information> </ccmp:ccmpResponse>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 20: Getting info about a specific blueprint Figure 20: Getting info 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. This is achieved by sending a "confRequest/create" message message. This is achieved by sending a "confRequest/create" message
skipping to change at page 60, line 8 skipping to change at page 59, line 30
conference, which is compliant with the standard XCON data model. conference, which is compliant with the standard XCON data model.
The "confObjID" in the response is set to the XCON-URI of the new The "confObjID" in the response is set to the XCON-URI of the new
conference (in this case, "xcon:8977794@example.com"). We also 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 |
| - confObjID: AudioRoom | | - confObjID: AudioRoom |
| - operation: create | | - operation: create |
| - confInfo: (null) | | - confInfo: (null) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP confResponse message | | CCMP confResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: newConfId | | - confObjID: newConfId |
| - operation: create | | - operation: create |
| - response-code: 200 | | - response-code: 200 |
| - version: 1 | | - version: 1 |
| - confInfo: newConfInfo | | - confInfo: newConfInfo |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-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>create</operation> <operation>create</operation>
<ccmp:confRequest/> <ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message from the server: 2. confResponse 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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<version>1</version> <version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:available-media> <info:available-media>
<info:entry label="333"> <info:entry label="333">
<info:display-text> <info:display-text>audio stream</info:display-text>
audio stream <info:type>audio</info:type>
</info:display-text> </info:entry>
<info:type>audio</info:type> </info:available-media>
</info:entry>
</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> <xcon:conference-floor-policy>
confirm <xcon:floor id="11">
</xcon:floor-request-handling> <xcon:media-label>333</xcon:media-label>
<xcon:conference-floor-policy> </xcon:floor>
<xcon:floor id="11"> </xcon:conference-floor-policy>
<xcon:media-label>333</xcon:media-label> </xcon:floor-information>
</xcon:floor> </confInfo>
</xcon:conference-floor-policy> </ccmp:confResponse>
</xcon:floor-information> </ccmpResponse>
</confInfo> </ccmp:ccmpResponse>
</ccmp:confResponse>
</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
skipping to change at page 62, line 47 skipping to change at page 62, line 22
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:confRequest> <ccmp:confRequest>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
Alice's conference Alice's conference
</info:display-text> </info:display-text>
</info:conference-description> </info:conference-description>
</confInfo> </confInfo>
</ccmp:confRequest> </ccmp:confRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message form the server: 2. confResponse 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-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<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
skipping to change at page 64, line 35 skipping to change at page 64, line 11
| | | |
. . . .
. . . .
1. usersRequest message: 1. usersRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
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">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type"> xsi:type="ccmp:ccmp-users-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:usersRequest> <ccmp:usersRequest>
<usersInfo> <usersInfo>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial out" <xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/> uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer" <xcon:target method="refer"
uri="tel:+390817683823"/> uri="tel:+1-972-555-1234"/>
<xcon:target method="refer" <xcon:target method="refer"
uri="sip:Carol@example.com"/> uri="sip:Carol@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</usersInfo> </usersInfo>
</ccmp:usersRequest> </ccmp:usersRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. usersResponse message form the server: 2. usersResponse 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-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 Figure 23: Updating the list of allowed users for the conference
'xcon:8977794@example.com' 'xcon:8977794@example.com'
6.6. Alice joins the conference 6.6. Alice joins the conference
This section illustrates the sixth transaction in the overall flow. This section illustrates the sixth transaction in the overall flow.
Alice uses the CCMP to add herself to the newly created conference. Alice uses the CCMP to add herself to the newly created conference.
This is achieved through a "userRequest/create" message containing, This is achieved through a "userRequest/create" message containing,
in the "userInfo" parameter, a <user> element compliant with the XCON in the "userInfo" parameter, a <user> element compliant with the XCON
data model representation. Notice that such element includes data model representation. Notice that such element includes
skipping to change at page 66, line 29 skipping to change at page 65, line 49
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. userRequest message: 1. userRequest 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-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:Alice@example.com"> <userInfo entity="xcon-userid:alice@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Alice83@example.com mailto:Alice83@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:alice_789@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse message form the server:
2. 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: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-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<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 the CCMP
skipping to change at page 68, line 30 skipping to change at page 68, line 6
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 1. "third party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@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>
skipping to change at page 69, line 4 skipping to change at page 68, line 28
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>
<operation>create</operation> <operation>create</operation>
<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
skipping to change at page 70, line 45 skipping to change at page 70, line 27
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. optionsRequest (Alice asks for CCMP server capabilities) 1. optionsRequest (Alice asks for CCMP server capabilities)
<?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-options-request-message-type"> xsi:type="ccmp:ccmp-options-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. optionsResponse (the server returns the list of its conference 2. optionsResponse (the server returns the list of its conference
control capabilities) control capabilities)
<?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-options-response-message-type"> xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>success</response-string> <response-string>success</response-string>
<ccmp:optionsResponse> <ccmp:optionsResponse>
<options> <options>
<standard-message-list> <standard-message-list>
<standard-message> <standard-message>
<name>blueprintsRequest</name> <name>blueprintsRequest</name>
</standard-message> </standard-message>
<standard-message> <standard-message>
<name>blueprintRequest</name> <name>blueprintRequest</name>
skipping to change at page 72, line 37 skipping to change at page 72, line 15
</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 exploits 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 is The extension in question is named "confSummaryRequest" and allows a
conceived to allow a CCMP client to obtain from the CCMP server CCMP client to obtain from the CCMP server synthetic information
synthetic information about a specific conference. The conference about a specific conference. The conference summary is carried in
summary is carried in the form of an XML element, <confSummary>, the form of an XML element as follows:
defined by the following XML schema:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="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>
skipping to change at page 74, line 24 skipping to change at page 73, line 39
| - confSummary | | - confSummary |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. extendedRequest (Alice makes use of the "confSummaryRequest") 1. extendedRequest (Alice makes use of the "confSummaryRequest")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
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"
xmlns:example="http://example.com/ccmp-extension-schema.xsd"> xmlns:example="http://example.com/ccmp-extension">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-request-message-type"> xsi:type="ccmp:ccmp-extended-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:extendedRequest> <ccmp:extendedRequest>
<extensionName>confRequestSummary</extensionName> <extensionName>confRequestSummary</extensionName>
</ccmp:extendedRequest> </ccmp:extendedRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. extendedResponse (the server provides Alice with a brief description 2. extendedResponse (the server provides Alice with a brief description
of the desired conference) of the desired conference)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpResponse 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"
xmlns:example="http://example.com/ccmp-extension-schema.xsd"> xmlns:example="http://example.com/ccmp-extension">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-response-message-type"> xsi:type="ccmp:ccmp-extended-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>
<ccmp:extendedResponse> <ccmp:extendedResponse>
<extensionName>confSummaryRequest</extensionName> <extensionName>confSummaryRequest</extensionName>
<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 Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. The result of the discovery process, is the address of the requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server. http: or https: URI, which identifies a conference server.
This document proposes the use of DNS to locate the conferencing DNS is RECOMMENDED to be used to locate a conference server in the
server. U-NAPTR resolution for conferencing takes a domain name as case that the client is not pre-configured to use a specific
input and produces a URI that identifies the conferencing server. conference server. U-NAPTR resolution for conferencing takes a
This process also requires an Application Service tag and an domain name as input and produces a URI that identifies the
Application Protocol tag, which differentiate conferencing-related conferencing server. This process also requires an Application
NAPTR records from other records for that domain. Service tag and an Application Protocol tag, which differentiate
conferencing-related NAPTR records from other records 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. the CCMP protocol.
The NAPTR records in the following example Figure 29 demonstrate the The NAPTR records in the following example Figure 29 demonstrate the
use of the Application Service and Protocol tags. Iterative NAPTR use of the Application Service and Protocol tags. Iterative NAPTR
resolution is used to delegate responsibility for the conferencing resolution is used to delegate responsibility for the conferencing
service from "zonea.example.com." and "zoneb.example.com." to service from "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.com. zonea.example.com.
;; order pref flags ;; order pref flags
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
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex "!*.!https://confs.example.com/!" ; regex
. ; replacement . ; replacement
) )
Figure 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], the CCMP is one of the following four protocols
which have been formally identified within the XCON framework: which have been formally identified within the XCON framework:
Conference Control Protocol: between Conference and Media Control Conference Control Protocol: between Conference and Media Control
skipping to change at page 78, line 5 skipping to change at page 77, line 26
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 the CCMP protocol, which a
conforming conference Server and Conferencing client MUST support. conforming conference Server and Conferencing client MUST support.
Although CCMP uses HTTP as a transport, it uses a strict subset of Although CCMP uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a HTTP features, and due to the restrictions of some features, a
conferencing server may not be a fully compliant HTTP server. It is conferencing server might not be a fully compliant HTTP server. It
intended that a conference server can easily be built using an HTTP is intended that a conference server can easily be built using an
server with extensibility mechanisms, and that a conferencing client HTTP server with extensibility mechanisms, and that a conferencing
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 implementors avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
A conferencing client that conforms to this specification is not Support of HTTP authentication [RFC2617] and cookies [RFC6265] is
required to support HTTP authentication [RFC2617] or cookies OPTIONAL for a conferencing client that conforms to this
[RFC6265]. These mechanism are unnecessary because CCMP requests specification. These mechanism are unnecessary because CCMP requests
carry their own authentication information (in the "subject" field; carry their own authentication information (in the "subject" field;
see Section 5.1). see Section 5.1).
A CCMP request is carried in the body of an HTTP POST request. The A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request. conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/ The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields. provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content- If the conference server does not receive the appropriate Content-
skipping to change at page 79, line 8 skipping to change at page 78, line 30
error message such as 405 (method not allowed). 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 conferencing The conference server MAY redirect a CCMP request. A conference
client MUST handle redirects, by using the Location header provided server MUST NOT include CCMP responses in a 3xx response. A
by the server in a 3xx response. When redirecting, the conferencing conferencing client MUST handle redirects, by using the Location
client MUST observe the delay indicated by the Retry-After header. header provided by the server in a 3xx response. When redirecting,
The conferencing client MUST authenticate the server that returns the the conferencing client MUST observe the delay indicated by the
redirect response before following the redirect. A conferencing Retry-After header. The conferencing client MUST authenticate the
client SHOULD authenticate the conference server indicated in a server that returns the redirect response before following the
redirect. redirect. A conferencing client SHOULD authenticate the conference
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 conference control client and the
skipping to change at page 80, line 49 skipping to change at page 80, line 23
client receives a valid response from the DNS server in cases where client receives a valid response from the DNS server in cases where
this is a concern. 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 conference client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). 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. In particular, the validation path able to validate the certificate following the procedures in
of the certificate must end in one of the client's trust anchors, [RFC2818] in the case of HTTP as a transport. In particular, the
even if that trust anchor is the conference server certificate validation path of the certificate must end in one of the client's
itself. If the client has external information as to the expected trust anchors, even if that trust anchor is the conference server
identity or credentials of the proper conference server, the certificate itself. If the client has external information as to 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 conferencing server MUST
implement mechanisms for authentication of users to validate their implement mechanisms for authentication of users to validate their
identity. There are several ways that a user might authenticate its identity. There are several ways that a user might authenticate its
identity to the system. For users joining a conference using one of identity to the system. For users joining a conference using one of
the call signaling protocols, the user authentication mechanisms for the call signaling protocols, the user authentication mechanisms for
skipping to change at page 83, line 36 skipping to change at page 83, line 9
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
In order to minimize the potential for DoS attacks, it is RECOMMENDED [RFC4732] provides an overview of possible DoS attacks. In order to
that conferencing systems require user authentication and minimize the potential for DoS attacks, it is RECOMMENDED that
authorization for any client participating in a conference. This can conferencing systems require user authentication and authorization
be accomplished through the use of the mechanisms described in for any client participating in a conference. This can be
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., SIPS) and media protocols (e.g.,
SRTP). In addition, Section 4.4 describes the use of a timer 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 provides the XML schema definition of the "application/ This section gives the XML Schema Definition
ccmp+xml" format. [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
"application/ccmp+xml" format. This is presented as a formal
definition of the "application/ccmp+xml" format. A new XML
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
Schema Definition is not intended to be used with on-the-fly
validation of the presence XML document. Whitespaces are included in
the schema to conform to the line length restrictions of the RFC
format without having a negative impact on the readability of the
document. Any conforming processor should remove leading and
trailing white spaces.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp" targetNamespace="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:tns="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info" <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/> schemaLocation="DataModel.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info" <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/> schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
skipping to change at page 101, line 44 skipping to change at page 101, line 32
This document registers a new XML namespace, a new XML schema, and This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema. This document also registers the the MIME type for the schema. This document also registers the
"XCON" Application Service tag and the "CCMP" Application Protocol "XCON" Application Service tag and the "CCMP" Application Protocol
tag. This document also defines registries for the CCMP operation tag. This document also defines registries for the CCMP operation
types and response codes. types and response codes.
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 Barnes (mary.ietf.barnes@gmail.com). Mary 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 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See RFCXXXX.</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 as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon-ccmp
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.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.
skipping to change at page 103, line 33 skipping to change at page 103, line 27
Interoperability considerations: None. Interoperability considerations: None.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .ccmpxml 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
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
skipping to change at page 110, line 24 skipping to change at page 110, line 24
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-27 Conferencing (XCON)", draft-ietf-xcon-common-data-model-31
(work in progress), April 2011. (work in progress), June 2011.
[W3C.REC-xmlschema-1-20041028]
Mendelsohn, N., Thompson, H., Maloney, M., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<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
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 110, line 47 skipping to change at page 111, line 12
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[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-
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] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and Moreau, J., Gudgin, M., Hadley, M., Nielsen, H., and N.
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
World Wide Web Consortium FirstEdition REC-soap12-part1- Framework", World Wide Web Consortium FirstEdition REC-
20030624, June 2003, soap12-part1-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and Moreau, J., Mendelsohn, N., Nielsen, H., Hadley, M., and
M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Evaluation of other protocol models and
for CCMP transports considered for CCMP
The operations on the objects can be implemented in at least two This section provides some background as to the selection of HTTP as
the transport for the CCMP requests/responses. In addition to HTTP,
the operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
In both approaches, servers will have to recreate their internal In both the SOAP and RESTFUL approaches, servers will have to
state representation of the object with each update request, checking recreate their internal state representation of the object with each
parameters and triggering function invocations. In the SOAP update request, checking parameters and triggering function
approach, it would be possible to describe a separate operation for invocations. In the SOAP approach, it would be possible to describe
each atomic element, but that would greatly increase the complexity a separate operation for each atomic element, but that would greatly
of the protocol. A coarser-grained approach to the CCMP does require increase the complexity of the protocol. A coarser-grained approach
that the server process XML elements in updates that have not changed to the CCMP does require that the server process XML elements in
and that there can be multiple changes in one update. updates that have not changed and that there can be multiple changes
in one update. For CCMP, the resource (REST) model might appear more
For CCMP, the resource (REST) model might appear more attractive, attractive, since the conference operations fit the CRUD approach.
since the conference operations fit the CRUD approach.
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 the CCMP requires a more complex
request/response protocol in order to maintain the data both in the request/response protocol in order to maintain the data both in the
server and at the client. This doesn't map very elegantly to the server and at the client. This doesn't map very elegantly to the
basic request/response model, whereby a response typically indicates basic 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 the CCMP, the
same data in the server is used for both the CCMP and Notifications - same data in the server is used for both the 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
a good compromise amongst the most notable past candidates and is
referred to as "HTTP single-verb transport plus CCMP body". With
this approach, CCMP is able to take advantage of existing HTTP
functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
transport (i.e. a single transaction type for each request/response
pair); this allows decoupling CCMP messages from HTTP messages.
Similarly, as with any RESTful approach, CCMP messages are inserted
directly in the body of HTTP messages, thus avoiding any unnecessary
processing and communication burden associated with further
intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport
protocol.
A.1. Using SOAP for the CCMP A.1. Using SOAP for the CCMP
A remote procedure call (RPC) mechanism for the CCMP could use SOAP A remote procedure call (RPC) mechanism for the CCMP could use SOAP
(Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC
-soap12-part2-20030624]), where conferences and the other objects are -soap12-part2-20030624]), where conferences and the other objects are
modeled as services with associated operations. Conferences and modeled as services with associated operations. Conferences and
other objects are selected by their own local identifiers, such as other objects are selected by their own local identifiers, such as
email-like names for users. This approach has the advantage that it email-like names for users. This approach has the advantage that it
can easily define atomic operations that have well-defined error can easily define atomic operations that have well-defined error
conditions. conditions.
 End of changes. 142 change blocks. 
569 lines changed or deleted 587 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/