draft-ietf-xcon-ccmp-10.txt   draft-ietf-xcon-ccmp-11.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: January 13, 2011 NS-Technologies Expires: April 29, 2011 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 12, 2010 October 26, 2010
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-10 draft-ietf-xcon-ccmp-11
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 January 13, 2011. This Internet-Draft will expire on April 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12
5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14
5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16
5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19
5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21
5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22
5.3.4. confRequest and confResponse . . . . . . . . . . . . 24 5.3.4. confRequest and confResponse . . . . . . . . . . . . 24
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28
5.3.6. userRequest and userResponse . . . . . . . . . . . . 30 5.3.6. userRequest and userResponse . . . . . . . . . . . . 30
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 36 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41
5.3.11. extendedRequest and extendedResponse . . . . . . . . 44 5.3.11. extendedRequest and extendedResponse . . . . . . . . 44
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 45 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49
6. A complete example of the CCMP in action . . . . . . . . . . 52 6. A complete example of the CCMP in action . . . . . . . . . . 52
6.1. Alice retrieves the available blueprints . . . . . . . . 53 6.1. Alice retrieves the available blueprints . . . . . . . . 53
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 57 operation . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4. Alice updates conference information . . . . . . . . . . 60 6.4. Alice updates conference information . . . . . . . . . . 60
6.5. Alice inserts a list of users in the conference object . 62 6.5. Alice inserts a list of users in the conference object . 62
6.6. Alice joins the conference . . . . . . . . . . . . . . . 63 6.6. Alice joins the conference . . . . . . . . . . . . . . . 63
6.7. Alice adds a new user to the conference . . . . . . . . . 65 6.7. Alice adds a new user to the conference . . . . . . . . . 65
6.8. Alice asks for the CCMP server capabilities . . . . . . . 67 6.8. Alice asks for the CCMP server capabilities . . . . . . . 68
6.9. Alice exploits a CCMP server extension . . . . . . . . . 70 6.9. Alice exploits a CCMP server extension . . . . . . . . . 70
7. Locating a Conference Control Server . . . . . . . . . . . . 73 7. Locating a Conference Control Server . . . . . . . . . . . . 73
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 78 contacted . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2. User Authentication and Authorization . . . . . . . . . . 78 10.2. User Authentication and Authorization . . . . . . . . . . 79
10.3. Security and Privacy of Identity . . . . . . . . . . . . 79 10.3. Security and Privacy of Identity . . . . . . . . . . . . 80
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 100 Application Service Tag . . . . . . . . . . . . . . . 100
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 100 Application Protocol Tag for CCMP . . . . . . . . . . 101
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104
14. Changes since last Version . . . . . . . . . . . . . . . . . 104 14. Changes since last Version . . . . . . . . . . . . . . . . . 104
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
15.1. Normative References . . . . . . . . . . . . . . . . . . 105 15.1. Normative References . . . . . . . . . . . . . . . . . . 105
15.2. Informative References . . . . . . . . . . . . . . . . . 106 15.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . 106 considered for CCMP . . . . . . . . . . . . . . . . 107
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109
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 9 skipping to change at page 5, line 9
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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
conferencing data.
Third-Party: A request issued by a client to manipulate the
conference data of another client.
3. XCON Conference Control System Architecture 3. XCON Conference Control System Architecture
CCMP supports the XCON framework . Figure 1 depicts a subset of the CCMP supports the XCON framework . Figure 1 depicts a subset of the
"Conferencing System Logical Decomposition" architecture from the "Conferencing System Logical Decomposition" architecture from the
XCON framework document. It illustrates the role that CCMP assumes XCON framework document. It illustrates the role that CCMP assumes
within the overall centralized architecture. within the overall centralized architecture.
........................................................ ........................................................
. Conferencing System . . Conferencing System .
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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
resources associated with them (conference reservations). An object resources associated with them (i.e., conference reservations). An
can mark certain of its properties as unalterable, so that they object can mark certain of its properties as unalterable, so that
cannot be overridden. It is envisaged by the framework that a client they cannot be overridden. Per the framework, a client may specify a
may specify a parent object (a conference or blueprint) from which parent object (a conference or blueprint) from which to inherit
the conference to be created has to inherit values by the mean of the values when a conference is created using the Conference Control
Conference Control Protocol. Protocol.
Conference objects are uniquely identified by the XCON-URI within the Conference objects are uniquely identified by the XCON-URI within the
scope of the conferencing system. Such identifier is introduced in scope of the conferencing system. The XCON-URI is introduced in the
the XCON framework and defined in the XCON common data model. XCON framework and defined in the XCON common data model.
Conference objects are comprehensively represented through XML Conference objects are comprehensively represented through XML
documents compliant with the XML Schema defined in the XCON data documents compliant with the XML Schema defined in the XCON data
model [I-D.ietf-xcon-common-data-model]. The root element of such model [I-D.ietf-xcon-common-data-model]. The root element of such
documents, called "<conference-info>", is of type "conference-type". documents, called "<conference-info>", is of type "conference-type".
It encompasses other XML elements describing different conference It encompasses other XML elements describing different conference
features and users as well. By the mean of CCMP, conferencing features and users as well. Using the CCMP, conferencing clients can
clients can use such XML structures to express their preferences in use these XML structures to express their preferences in creating or
creation or update. A conferencing server can convey conference updating a conference. A conferencing server can convey conference
information of such a form back to the clients. information using the XML elements back to the clients.
3.2. Conference Users 3.2. Conference Users
Each conference can have zero or more users. All conference Each conference can have zero or more users. All conference
participants are users, but some users may have only administrative participants are users, but some users may have only administrative
functions and do not contribute or receive media. Users are added functions and do not contribute or receive media. Users are added
one user at a time to simplify error reporting. When a conference is one user at a time to simplify error reporting. When a conference is
cloned from a parent object, users are inherited as well, so that it cloned from a parent object, users are inherited as well, so that it
is easy to set up a conference that has the same set of participants is easy to set up a conference that has the same set of participants
or a common administrator. The Conference Control Server creates or a common administrator. The Conference Control Server creates
skipping to change at page 8, line 18 skipping to change at page 8, line 18
out in Section 5.3.6 representing the case of a user at his first out in Section 5.3.6 representing the case of a user at his first
entrance in the system as a conference participant, must carry the entrance in the system as a conference participant, must carry the
XCON-USERID of the requestor in the proper "confUserID" parameter. XCON-USERID of the requestor in the proper "confUserID" parameter.
The XCON-USERID acts as a pointer to the user's profile as a The XCON-USERID acts as a pointer to the user's profile as a
conference actor, e.g. her signalling URI and other XCON protocol conference actor, e.g. her signalling URI and other XCON protocol
URIs in general, her role (moderator, participant, observer, etc.), URIs in general, her role (moderator, participant, observer, etc.),
her display text, her joining information and so on. A variety of her display text, her joining information and so on. A variety of
elements defined in the common <conference-info> element as specified elements defined in the common <conference-info> element as specified
in the XCON data model are used to describe the users related to a in the XCON data model are used to describe the users related to a
conference, in the first place the <users> element, as well as each conference including the <users> element, as well as each <user>
<user> element included in it. For example, it is possible to element included within it. For example, it is possible to determine
determine how a specific user expects and is allowed to join a how a specific user expects and is allowed to join a conference by
conference by looking at the <allowed-user-list> in <users>: each looking at the <allowed-user-list> in <users>: each <target> element
<target> element involved in such a list represents a user and shows involved in such a list represents a user and shows a "method"
a "method" attribute defining how the user is expected to join the attribute defining how the user is expected to join the conference,
conference, i.e. "dial-in" for users that are allowed to dial, "dial- i.e. "dial-in" for users that are allowed to dial, "dial-out" for
out" for users that the conference focus will be trying to reach users that the conference focus will be trying to reach (with
(with "dial-in" being the default mode). If the conference is "dial-in" being the default mode). If the conference is currently
currently active, dial-out users are contacted immediately; active, dial-out users are contacted immediately; otherwise, they are
otherwise, they are contacted at the start of the conference. The contacted at the start of the conference. The CCMP, acting as the
CCMP, acting as the Conference Control Protocol, provides a means to Conference Control Protocol, provides a means to manipulate these and
manipulate these and other kinds of user-related features. other kinds of user-related features.
As a consequence of an explicit user registration to a specific XCON As a consequence of an explicit user registration to a specific XCON
conferencing system, conferencing clients are usually provided conferencing system, conferencing clients are usually provided
(besides the XCON-USERID) with log-in credentials (i.e. username and (besides the XCON-USERID) with log-in credentials (i.e. username and
password). Such credentials can be used to authenticate the XCON password). Such credentials can be used to authenticate the XCON
aware client issuing CCMP requests. To this purpose, both username aware client issuing CCMP requests. Thus, both username and password
and password should be carried in a CCMP request as part of the should be carried in a CCMP request as part of the "subject"
"subject" parameter whenever a registered conferencing client wishes parameter whenever a registered conferencing client wishes to contact
to contact a CCMP server. The CCMP does not look after users a CCMP server. The CCMP does not maintain user's subscriptions at
subscriptions at the conference server; hence, it does not provide the conference server; hence, it does not provide any specific
any specific mechanism allowing clients to register their mechanism allowing clients to register their conferencing accounts.
conferencing accounts. The "subject" parameter is just used for The "subject" parameter is just used for carrying authentication data
carrying authentication data associated with pre-registered clients. associated with pre-registered clients, with the specific
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, which has been
specifically conceived to provide users with the necessary means for specifically conceived to provide users with the necessary means for
the creation, retrieval, modification and deletion of conference the creation, retrieval, modification and deletion of conference
objects. CCMP is also state-less, which means implementations can objects. CCMP is also state-less, which means implementations can
safely handle transactions independently from each other. safely handle transactions independently from each other.
Conference-related information is encapsulated into CCMP messages in Conference-related information is encapsulated into CCMP messages in
the form of XML documents or XML document fragments compliant with the form of XML documents or XML document fragments compliant with
skipping to change at page 9, line 18 skipping to change at page 9, line 19
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 protocol conference. The core set of objects manipulated in the CCMP protocol
includes conference blueprints, the conference object, users, and includes conference blueprints, the conference object, users, and
sidebars. sidebars.
CCMP has been conceived as completely independent from underlying CCMP has been conceived as completely independent from underlying
protocols, which means that there can be different ways to carry CCMP protocols, which means that there can be different ways to carry CCMP
messages across the network, from a conferencing client to a messages across the network, from a conferencing client to a
conferencing server. Nevertheless, it is recommended to use HTTP as conferencing server. The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies. Implementation details and CCMP responses in HTTP 200 OK replies. Implementation details
are presented in Section 4.2 are presented in Section 4.2
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, a conference user, a
skipping to change at page 10, line 27 skipping to change at page 10, line 27
conference server first checks all the parameters, before making any conference server first checks all the parameters, before making any
changes to the internal representation of the conference object. For changes to the internal representation of the conference object. For
example, it would be undesirable to change the <subject> of the example, it would be undesirable to change the <subject> of the
conference, but then detect an invalid URI in one of the <service- conference, but then detect an invalid URI in one of the <service-
uris> and abort the remaining updates. Also, since multiple clients uris> and abort the remaining updates. Also, since multiple clients
can modify the same conference objects, conference clients should can modify the same conference objects, conference clients should
first obtain the current object from the conference server and then first obtain the current object from the conference server and then
update the relevant data elements in the conference object prior to update the relevant data elements in the conference object prior to
invoking a specific operation on the conference server. In order to invoking a specific operation on the conference server. In order to
effectively manage modifications to conference data, a versioning effectively manage modifications to conference data, a versioning
approach is exploited in the CCMP. More precisely, each conference approach is provided by the CCMP. Specifically, each conference
object is associated with a version number indicating the most up to object is associated with a version number indicating the most up to
date view of the conference at the server's side. Such version date view of the conference at the server's side. The version number
number is reported to the clients when answering their requests. A is reported to the clients when answering their requests. A client
client willing to make modifications to a conference object has to willing to make modifications to a conference object has to send an
send an update message to the server. In case the modifications are update message to the server. If the modifications are all
all successfully applied, the server sends back to the client a "200" successfully applied, the server sends back to the client a "200"
response which also carries information about the current server-side response which also carries information about the current server-side
version of the modified object. With such approach, a client which version of the modified object. With this approach, a client working
is working on version "X" of a conference object and finds inside a on version "X" of a conference object that finds a "200" response
"200" response a version number which is "X+1" can be sure that the with a version number which is "X+1" can be sure that the version it
version it was aware of was the most up to date. On the other hand, was aware of was the most up to date. On the other hand, if the
if the "200" response carries back a version which is at least "X+2", "200" response contains a version which is at least "X+2", the client
the client can detect that the object that has been modified at the can detect that the object that has been modified at the server's
server's side was more up to date than the one it was working upon. side was more up to date than the one it was working upon. This is
This is clearly due to the effect of concurrent modification requests clearly due to the effect of concurrent modification requests issued
issued by independent clients. Hence, for the sake of having by independent clients. Hence, for the sake of having available the
available the latest version of the modified object, the client can latest version of the modified object, the client can send to the
send to the conference server a further "retrieve" request. In no conference server a further "retrieve" request. In the case that a
case a copy of the conference object available at the server is copy of the conference object is not returned to the client as part
returned to the client as part of the update response message. Such of the update response message, the client can always obtain a copy
a copy can always be obtained through an ad-hoc "retrieve" message. through an ad-hoc "retrieve" message.
Based on the above considerations, all CCMP response messages Based on the above considerations, all CCMP response messages
carrying in their body a conference document (or a fragment of it) containing a conference document (or a fragment of it) MUST contain a
must contain a "version" parameter. This does not hold for request "version" parameter. The "version" parameter is not REQUIRED for
messages, for which the "version" parameter is not at all required, requests, since it represents useless information for the server: as
since it represents useless information for the server: as long as long as the required modifications can be applied to the target
the required modifications can be applied to the target conference conference object with no conflicts, the server does not care whether
object with no conflicts, the server does not care whether or not the the client has stored an up to date view of the information.
client had an up to date view of the information stored at its side. However, a client subscribed to the XCON event package
This said, it stands clear that a client which has subscribed at the [I-D.ietf-xcon-event-package] notifications about conference object
server, through the XCON event package [I-D.ietf-xcon-event-package], modifications, will always have the most up to date version of that
to notifications about conference object modifications, will always object.
have the most up to date version of that object available at his
side.
A final consideration concerns the relation between the CCMP and the A final consideration concerns the relation between the CCMP and the
main entities it manages, i.e. conference objects. Such objects have main entities it manages, i.e. conference objects. Such objects have
to be compliant with the XCON data-model, which identifies some to be compliant with the XCON data-model, which identifies some
elements/attributes as mandatory. From the CCMP standpoint this can elements/attributes as mandatory. From the CCMP standpoint this can
become a problem in cases of client-initiated operations, like the become a problem in cases of client-initiated operations, like the
creation/update of conference objects. In such cases, not all of the creation/update of conference objects. In such cases, not all of the
mandatory data can be known in advance to the client issuing a CCMP mandatory data can be known in advance to the client issuing a CCMP
request. As an example, a client has no means to know, at the time request. As an example, a client has no means to know, at the time
it issues a conference creation request, the XCON-URI that the server it issues a conference creation request, the XCON-URI that the server
skipping to change at page 12, line 17 skipping to change at page 12, line 15
processing and communication burden associated with further processing and communication burden associated with further
intermediaries. With this approach, no modification to the CCMP intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport messages/operations is required to use a different transport
protocol. protocol.
The remainder of this document focuses on the selected approach. The The remainder of this document focuses on the selected approach. The
CCMP protocol inserts XML-based CCMP requests into the body of HTTP CCMP protocol inserts XML-based CCMP requests into the body of HTTP
POST operations and retrieves responses from the body of HTTP "200 POST operations and retrieves responses from the body of HTTP "200
OK" messages. CCMP messages have a MIME-type of "application/ OK" messages. CCMP messages have a MIME-type of "application/
ccmp+xml", which appears inside the "Content-Type" and "Accept" ccmp+xml", which appears inside the "Content-Type" and "Accept"
fields of HTTP requests and responses. Section 9 provides the fields of HTTP requests and responses. The XML documents in the CCMP
complete requirements for an HTTP implementation to support the CCMP. messages MUST be encoded in UTF-8. This specification follows the
recommendations and conventions described in [RFC3023], including the
naming convention of the type ('+xml' suffix) and the usage of the
'charset' parameter. The 'charset' parameter MUST be included with
the XML document. Section 9 provides the complete requirements for
an HTTP implementation to support the CCMP.
5. CCMP messages 5. CCMP messages
CCMP messages are either requests or responses. The general CCMP CCMP messages are either requests or responses. The general CCMP
request message is defined in Section 5.1. The general CCMP response request message is defined in Section 5.1. The general CCMP response
message is defined in Section 5.2. The details of the specific message is defined in Section 5.2. The details of the specific
message type which is carried in the CCMP request and response message type 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
skipping to change at page 16, line 29 skipping to change at page 16, line 29
<xs:complexType abstract="true" <xs:complexType abstract="true"
name="ccmp-response-message-type"> name="ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" minOccurs="0" <xs:element name="operation" minOccurs="0"
maxOccurs="1" /> maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element name="response-code"
maxOccurs="1" /> type="response-codeType"
minOccurs="1" maxOccurs="1" />
<xs:element name="response-string" type="xs:string" <xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs: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>
skipping to change at page 19, line 14 skipping to change at page 19, line 14
request, is created and removed in conjuntcion with, respectively, request, is created and removed in conjuntcion with, respectively,
the creation and deletion of the associated conference document. the creation and deletion of the associated conference document.
Thus, "update" and "retrieve" are the only semantically correct Thus, "update" and "retrieve" are the only semantically correct
operations for such message. operations for such message.
(***): This operation can involve the creation of an XCON-USERID, if (***): This operation can involve the creation of an XCON-USERID, if
the sender does not add it in the "confUserID" parameter, and/or if the sender does not add it in the "confUserID" parameter, and/or if
the "entity" field of the "userInfo" parameter is void. the "entity" field of the "userInfo" parameter is void.
Additional parameters included in the specialized CCMP request/ Additional parameters included in the specialized CCMP request/
response messages are detailed in the subsequent sections. response messages are detailed in the subsequent sections. If a
required parameter is not included in a request, the conference
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. Such URIs can be subsequently used by the client
to access detailed information about a specified blueprint with a to access detailed information about a specified blueprint with a
specific blueprintRequest message per Section 5.3.3. The specific blueprintRequest message per Section 5.3.3. The
"confUserID" parameter MUST be included in every blueprintsRequest/ "confUserID" parameter MUST be included in every blueprintsRequest/
Response message and reflect the XCON-USERID of the conferencing Response message and reflect the XCON-USERID of the conferencing
skipping to change at page 24, line 49 skipping to change at page 24, line 49
confRequest and response. The requirements for inclusion of confRequest and response. The requirements for inclusion of
"confObjID" and "confInfo" parameter in the confRequest/confResponse "confObjID" and "confInfo" parameter in the confRequest/confResponse
messages and are detailed below for each "operation" case. messages and are detailed below for each "operation" case.
The creation case deserves care. To create a new conference through The creation case deserves care. To create a new conference through
a "confRequest" message, two approaches can be considered: a "confRequest" message, two approaches can be considered:
1. Creation through explicit cloning: the "confObjID" parameter MUST 1. Creation through explicit cloning: the "confObjID" parameter MUST
contain the XCON-URI of the blueprint or of the conference to be contain the XCON-URI of the blueprint or of the conference to be
cloned, while the "confInfo" parameter MUST NOT be included in cloned, while the "confInfo" parameter MUST NOT be included in
the confRequest; the confRequest. Note that cloning of an active conference is
only done in the case of a sidebar operation per the XCON
framework and as described in Section 5.3.8.
2. Creation through implicit cloning (also known as "direct 2. Creation through implicit cloning (also known as "direct
creation"): the "confObjID" parameter MUST NOT be included in the creation"): the "confObjID" parameter MUST NOT be included in the
request and the CCMP client can describe the desired conference request and the CCMP client can describe the desired conference
to be created using the "confInfo" parameter. If no "confInfo" to be created using the "confInfo" parameter. If no "confInfo"
parameter is provided in the request, the new conference will be parameter is provided in the request, the new conference will be
created as a clone of the system default blueprint. created as a clone of the system default blueprint.
In both creation cases, the confResponse, for a successful completion In both creation cases, the confResponse, for a successful completion
of a "create" operation, contains a response-code of "200" and MUST of a "create" operation, contains a response-code of "200" and MUST
contain the XCON-URI of the newly created conference in the contain the XCON-URI of the newly created conference in the
skipping to change at page 32, line 13 skipping to change at page 32, line 14
should look like the following: should look like the following:
Request fields: Request fields:
confUserID=null; confUserID=null;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
userInfo= userInfo=
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<endpoint entity="sip:GHIL345@blablabla"> <endpoint entity="sip:GHIL345@example.com">
... ...
Response fields (in case of success): Response fields (in case of success):
confUserID=user345; confUserID=user345;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
response-code=200; response-code=200;
userInfo=null; //or the entire userInfo object userInfo=null; //or the entire userInfo object
skipping to change at page 46, line 5 skipping to change at page 46, line 12
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. An "optionsRequest" (Figure 18) message is a basic CCMP message, i.e.
it does not represent a specialization of the general CCMP request. it does not represent a specialization of the general CCMP request.
It allows a CCMP client to become aware of CCMP server capabilities It allows a CCMP client to become aware of CCMP server capabilities
in terms of CCMP supported messages. in terms of CCMP supported messages.
Indeed, the "optionsResponse" returns, in the appropriate <options> The "optionsResponse" returns, in the appropriate <options> field, a
field, information about both standard (i.e. IETF-defined) CCMP list of the supported CCMP messages as defined in this specification.
messages and extension messages the server is able to handle. These messages are in the form of a list, <standard-message-list>
Supported messages are listed into two separate groups, namely including each of the supported messages as reflected by <standard-
<standard-message-list> and <extended-message-list>. Such groups are message> elements. The "optionsResponse" message also allows for an
represented, respectively, by a <standard-message> entry (for <extended-message-list>, which is a list of additional message types
standard messages) and an <extended-message> entry (for extensions). in the form of <extended-message-list> elements that are currently
In both cases, for each message the following information is undefined, to allow for future extensibility. The following
provided: information is provided for both types of messages:
o <name> (mandatory): in case of standard messages, it can be one of o <name> (mandatory): 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 optional element is absent, the
client SHOULD assume the server is able to handle the entire set client SHOULD assume the server is able to handle the entire set
skipping to change at page 53, line 29 skipping to change at page 53, line 29
the blueprints, together with a dump of the two messages exchanged the blueprints, together with a dump of the two messages exchanged
("blueprintsRequest" and "blueprintsResponse"). As it comes out from ("blueprintsRequest" and "blueprintsResponse"). As it comes out from
the figure, the "blueprintsResponse" message contains, in the the figure, the "blueprintsResponse" message contains, in the
"blueprintsInfo" parameter, information about the available "blueprintsInfo" parameter, information about the available
blueprints, in the form of the standard XCON-URI of the blueprint, blueprints, in the form of the standard XCON-URI of the blueprint,
plus additional (and optional) information, like its display-text and plus additional (and optional) information, like its display-text and
purpose. purpose.
Alice retrieves from the server the list of available blueprints: Alice retrieves from the server the list of available blueprints:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP blueprintsRequest message | | CCMP blueprintsRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: (null) | | - confObjID: (null) |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CMP blueprintsResponse message | | CMP blueprintsResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: (null) | | - confObjID: (null) |
| - response-code: 200 | | - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. | | - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintsRequest message: 1. blueprintsRequest message:
<?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:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
xsi:type="xcon:ccmp-blueprints-request-message-type"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<confUserID>xcon-userid:Alice@example.com</confUserID> xsi:type="ccmp:ccmp-blueprints-request-message-type">
</ccmpRequest> <confUserID>xcon-userid:alice@example.com</confUserID>
</ccmp:ccmpRequest> <ccmp:blueprintsRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintsResponse message form the server: 2. blueprintsResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:response-code>200</ccmp: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,
where only audio is available, more users
can talk at the same time
and the requests for the AudioFloor
are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access, conference room with public access,
where only audio is available, more users where both audio and video are available,
can talk at the same time 8 users can talk and be seen at the same time,
and the requests for the AudioFloor and the floor requests are automatically accepted.
are automatically accepted. </info:purpose>
</info:purpose> </info:entry>
</info:entry> <info:entry>
<info:entry> <info:uri>xcon:AudioConference1@example.com</info:uri>
<info:uri>xcon:VideoRoom@example.com</info:uri> <info:display-text>AudioConference1</info:display-text>
<info:display-text>VideoRoom</info:display-text> <info:purpose>Public Audio Conference:
<info:purpose>Video Room: conference with public access,
conference room with public access, where only audio is available,
where both audio and video are available, only one user can talk at the same time,
8 users can talk and be seen at the same time, and the requests for the AudioFloor MUST
and the floor requests are automatically accepted. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri>
<info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference
where both audio and video are available,
only one user can talk
</info:purpose>
</info:entry> </info:entry>
<info:entry> <info:entry>
<info:uri>xcon:AudioConference1@example.com</info:uri> <info:uri>xcon:AudioConference2@example.com</info:uri>
<info:display-text>AudioConference1</info:display-text> <info:display-text>AudioConference2</info:display-text>
<info:purpose>Public Audio Conference: <info:purpose>Basic Audio Conference:
conference with private access,
conference with public access,
where only audio is available, where only audio is available,
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
<info:entry> </blueprintsInfo>
<info:uri>xcon:VideoConference1@example.com</info:uri> </ccmp:blueprintsResponse>
<info:display-text>VideoConference1</info:display-text> </ccmpResponse>
<info:purpose>Public Video Conference: conference </ccmp:ccmpResponse>
where both audio and video are available,
only one user can talk
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference2@example.com</info:uri>
<info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference:
conference with private access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
</blueprintsInfo>
</ccmp:blueprintsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 19: Getting blueprints from the server Figure 19: Getting blueprints from the server
6.2. Alice gets detailed information about a specific blueprint 6.2. Alice gets detailed information about a specific blueprint
This section illustrates the second transaction in the overall flow. This section illustrates the second transaction in the overall flow.
In this case, Alice, who now knows the XCON-URIs of the blueprints In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about CCMP "blueprintRequest" message, to get detailed information about
one 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 form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type"> xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:response-code>200</ccmp:response-code> <response-code>200</response-code>
<ccmp:blueprintResponse> <response-string>Success</response-string>
<blueprintInfo entity="xcon:AudioRoom@example.com"> <ccmp:blueprintResponse>
<info:conference-description> <blueprintInfo entity="xcon:AudioRoom@example.com">
<info:display-text>AudioRoom</info:display-text> <info:conference-description>
<info:maximum-user-count>2</info:maximum-user-count> <info:display-text>AudioRoom</info:display-text>
<info:available-media> <info:available-media>
<info:entry label="audioLabel"> <info:entry label="audioLabel">
<info:type>audio</info:type> <info:display-text>
</info:entry> audio stream
</info:available-media> </info:display-text>
</info:conference-description> <info:type>audio</info:type>
<info:users> </info:entry>
<xcon:join-handling>allow</xcon:join-handling> </info:available-media>
</info:users> </info:conference-description>
<xcon:floor-information> <info:users>
<xcon:floor-request-handling>confirm <xcon:join-handling>allow</xcon:join-handling>
</xcon:floor-request-handling> </info:users>
<xcon:conference-floor-policy> <xcon:floor-information>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor-request-handling>confirm
</xcon:conference-floor-policy> </xcon:floor-request-handling>
</xcon:floor-information> <xcon:conference-floor-policy>
</blueprintInfo> <xcon:floor id="audioFloor">
</ccmp:blueprintResponse> <xcon:media-label>
audioLabel
</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp: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 58, line 8 skipping to change at page 58, line 19
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 <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-blueprint-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>
<ccmp:response-code>200</ccmp:response-code> <response-string>Success</response-string>
<ccmp:version>1</ccmp: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:conf-uris> <info:available-media>
<info:entry> <info:entry label="333">
<info:uri> <info:display-text>
xcon:8977794@example.com audio stream
</info:uri> </info:display-text>
<info:display-text> <info:type>audio</info:type>
conference xcon-uri </info:entry>
</info:display-text> </info:available-media>
</info:entry> </info:conference-description>
</info:conf-uris> <info:users>
<info:maximum-user-count>10</info:maximum-user-count> <xcon:join-handling>allow</xcon:join-handling>
<info:available-media> </info:users>
<info:entry label="11"> <xcon:floor-information>
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling> <xcon:floor-request-handling>
confirm</xcon:floor-request-handling> confirm
</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="11"/> <xcon:floor id="11">
<xcon:media-label>333</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse>
</ccmp:ccmpResponse>
Figure 21: Creating a new conference by cloning a blueprint Figure 21: Creating a new conference by cloning a blueprint
6.4. Alice updates conference information 6.4. Alice updates conference information
This section illustrates the fourth transaction in the overall flow. This section illustrates the fourth transaction in the overall flow.
Alice decides to modify some of the details associated with the Alice decides to modify some of the details associated with the
conference she just created. More precisely, she changes the conference she just created. More precisely, she changes the
<display-text> element under the <conference-description> element of <display-text> element under the <conference-description> element of
the document representing the conference. This is achieved through a the document representing the conference. This is achieved through a
"confRequest/update" message carrying the fragment of the conference "confRequest/update" message carrying the fragment of the conference
document to which the required changes have to be applied. As shown document to which the required changes have to be applied. As shown
in the picture, the response contains a code of "200", which in the picture, the response contains a code of "200", which
acknowledges the modifications requested by the client, while also acknowledges the modifications requested by the client, while also
updating the conference version number from 1 to 2, as reflected in updating the conference version number from 1 to 2, as reflected in
the "version" parameter. the "version" parameter.
Alice updates information about the conference she just created: Alice updates information about the conference she just created:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP confRequest message | | CCMP confRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - confInfo: confUpdates | | - confInfo: confUpdates |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP confResponse message | | CCMP confResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - response-code: 200 | | - response-code: 200 |
| - version: 2 | | - version: 2 |
| - confInfo: (null) | | - confInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
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 form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>200</ccmp:response-code> <response-code>200</response-code>
<ccmp:version>2</ccmp:version> <response-string>Success</response-string>
<ccmp:confResponse/> <version>2</version>
<ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Updating conference information Figure 22: Updating conference information
6.5. Alice inserts a list of users in the conference object 6.5. Alice inserts a list of users in the conference object
This section illustrates the fifth transaction in the overall flow. This section illustrates the fifth transaction in the overall flow.
Alice modifies the <allowed-users-list> under the <users> element in Alice modifies the <allowed-users-list> under the <users> element in
the document associated with the conference she created. To the the document associated with the conference she created. To the
purpose, she exploits the "usersRequest" message provided by the purpose, she exploits the "usersRequest" message provided by the
CCMP. The picture below shows the transaction. CCMP. The picture below shows the transaction.
skipping to change at page 62, line 42 skipping to change at page 62, line 47
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
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"/>
skipping to change at page 63, line 22 skipping to change at page 63, line 28
</usersInfo> </usersInfo>
</ccmp:usersRequest> </ccmp:usersRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. usersResponse message form the server: 2. usersResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns: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-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>update</operation> <operation>retrieve</operation>
<ccmp:response-code>200</ccmp:response-code> <response-code>200</response-code>
<ccmp:version>3</ccmp:version> <response-string>Success</response-string>
<ccmp:confResponse/> <version>3</version>
<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.
skipping to change at page 64, line 9 skipping to change at page 64, line 15
data model representation. Notice that such element includes data model representation. Notice that such element includes
information about the user's Address of Records, as well as her information about the user's Address of Records, as well as her
current end-point. The picture below shows the transaction. Notice current end-point. The picture below shows the transaction. Notice
how the "confUserID" parameter is equal to the "entity" attribute of how the "confUserID" parameter is equal to the "entity" attribute of
the <userInfo> element, which indicates that the request issued by the <userInfo> element, which indicates that the request issued by
the client is a first-party one. the client is a first-party one.
Alice joins the conference by issuing a "userRequest/create" message Alice joins the conference by issuing a "userRequest/create" message
with her own id to the server: with her own id to the server:
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: AliceUserInfo |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 4 |
| - userInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:response-code>200</ccmp:response-code>
<ccmp:version>4</ccmp:version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 24: Alice joins the conference through the CCMP
6.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new conferencing system
user, Ciccio, to the conference. This "third-party" request is
realized through a "userRequest/create" message containing, in the
"userInfo" parameter, a <user> element compliant with the XCON data
model representation. Notice that such element includes information
about Ciccio's Address of Records, as well as his current end-point,
but has a fake "entity" attribute, since it is unknown to Alice, in
this example. Thus, the server is in charge of generating a new
XCON-USERID for the user Alice indicates, and returning it in the
"entity" attribute of the "userInfo" parameter carried in the
response, as well as adding the user to the conference. The picture
below shows the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: CiccioUserInfo(with dummy "entity") | | - userInfo: AliceUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP optionsResponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - response-code: 200 | | - response-code: 200 |
| - version: 5 | | - version: 4 |
| - userInfo: CiccioUserInfo | | - userInfo: (null) |
| (with actual "entity") |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 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:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:Alice@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Ciccio@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:Ciccio@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. "third party" userResponse message from the server: 2. userResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>4</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 24: Alice joins the conference through the CCMP
6.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new conferencing system
user, Ciccio, to the conference. This "third-party" request is
realized through a "userRequest/create" message containing, in the
"userInfo" parameter, a <user> element compliant with the XCON data
model representation. Notice that such element includes information
about Ciccio's Address of Records, as well as his current end-point,
but has a fake "entity" attribute, "AUTO_GENERATE@example.com" as
discussed in Section 4, since the XCON-USERID is initially unknown to
Alice. Thus, the conference server is in charge of generating a new
XCON-USERID for the user Alice indicates (i.e, Ciccio), and returning
it in the "entity" attribute of the "userInfo" parameter carried in
the response, as well as adding the user to the conference. The
picture below shows the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server:
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: dummyUserID, CiccioUserInfo |
|------------------------------------------------------>|
| |
| CCMP optionsResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 5 |
| - userInfo: userIDCiccio, |
| CiccioUserInfo |
| |
|<------------------------------------------------------|
| |
. .
. .
1. "third party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. "third party" userResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>200</ccmp:response-code> <response-code>200</response-code>
<ccmp:version>5</ccmp:version> <version>5</version>
<ccmp:userResponse> <ccmp:userResponse>
<userInfo entity="xcon-userid:Ciccio@example.com"> <userInfo entity="xcon-userid:Ciccio@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Ciccio@example.com mailto:Ciccio@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
skipping to change at page 68, line 7 skipping to change at page 68, line 16
6.8. Alice asks for the CCMP server capabilities 6.8. Alice asks for the CCMP server capabilities
This section illustrates how Alice can discover which standard CCMP This section illustrates how Alice can discover which standard CCMP
messages and what extensions are supported by the CCMP server she messages and what extensions are supported by the CCMP server she
interacts with through an optionsRequest/optionsResponse transaction. interacts with through an optionsRequest/optionsResponse transaction.
To prepare the optionsRequest, Alice just puts her XCON-USERID in the To prepare the optionsRequest, Alice just puts her XCON-USERID in the
confUserID parameter. Looking at the <options> element in the confUserID parameter. Looking at the <options> element in the
received optionsResponse, Alice infers the following server received optionsResponse, Alice infers the following server
capabilities as regards standard CCMP messages: capabilities as regards standard CCMP messages:
o the server doesn't support neither sidebarsByValRequest nor o the server doesn't support sidebarsByValRequest nor
sidebarByValRequest messages, since they do not appear in the sidebarByValRequest messages, since they do not appear in the
<standard-message-list>; <standard-message-list>;
o the only implemented operation for the blueprintRequest message is o the only implemented operation for the blueprintRequest message is
"retrieve", since no other <operation> entries are included in the "retrieve", since no other <operation> entries are included in the
related <operations> field. related <operations> field.
Besides, by analyzing the <extended-message-list>, Alice discovers By analyzing the <extended-message-list>, Alice discovers the server
the server implements an extension named "confSummaryRequest" implements a bluePrint extension, referred to as "confSummaryRequest"
allowing conferencing clients to recover via CCMP a brief description in this example. This extension allows Alice to recover via CCMP a
of a specific conference; the XML elements involved in this extended brief description of a specific conference; the XML elements involved
conference control transaction are available at the URL indicated in in this extended conference control transaction are available at the
the <schema-ref> element and the only operation envisioned for this URL indicated in the <schema-ref> element and the only operation
extension is "retrieve". To better understand how Alice can exploit provided by this extension is "retrieve". To better understand how
the "confSummaryRequest" extension via CCMP, see Section 6.9. Alice can exploit the "confSummaryRequest" extension via CCMP, see
Section 6.9.
The picture below shows the optionsRequest/optionsResponse message
exchanging between Alice and the CCMP server.
CCMP Client CCMP Server
| |
| CCMP optionsRequest message |
| - confUserID: Alice |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
1. optionsRequest (Alice asks for CCMP server capabilities)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> The figure below shows the optionsRequest/optionsResponse message
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" exchange between Alice and the CCMP server.
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" CCMP Client CCMP Server
xsi:type="ccmp:ccmp-options-request-message-type"> | |
<confUserID>xcon-userid:Alice@example.com</confUserID> | CCMP optionsRequest message |
</ccmpRequest> | - confUserID: Alice |
</ccmp:ccmpRequest> |------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
2. optionsResponse (the server returns the list of its conference 1. optionsRequest (Alice asks for CCMP server capabilities)
control capabilities)
<?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: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">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type"> xsi:type="ccmp:ccmp-options-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code> </ccmpRequest>
<response-string>success</response-string> </ccmp:ccmpRequest>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
</standard-message>
<name>blueprintRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
<standard-message>
</standard-message>
<name>confsRequest</name>
<standard-message>
<name>confRequest</name>
</standard-message>
<standard-message>
<name>usersRequest</name>
</standard-message>
<standard-message>
<name>userRequest</name>
</standard-message>
<standard-message>
<name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list> 2. optionsResponse (the server returns the list of its conference
<extended-message-list> control capabilities)
<extended-message>
<name>confSummaryRequest</name> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
<standard-message>
<name>blueprintRequest</name>
<operations> <operations>
<operation>request</operation> <operation>retrieve</operation>
</operations> </operations>
<schema-ref> </standard-message>
http://example.com/ccmp-extension-schema.xsd <standard-message>
</schema-ref> <name>confsRequest</name>
<description> </standard-message>
confSummaryRequest is intented <standard-message>
to allow the requestor to retrieve <name>confRequest</name>
a brief description
of the conference indicated in the </standard-message>
confObjID request parameter <standard-message>
</description> <name>usersRequest</name>
</extended-message> </standard-message>
</extended-message-list> <standard-message>
</options> <name>userRequest</name>
</ccmp:optionsResponse> </standard-message>
</ccmpResponse> <standard-message>
</ccmp:ccmpResponse> <name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list>
<extended-message-list>
<extended-message>
<name>confSummaryRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
<schema-def>
http://example.com/ccmp-extension-schema.xsd
</schema-def>
<description>
confSummaryRequest is intented
to allow the requestor to retrieve
a brief description
of the conference indicated in the
confObjID request parameter
</description>
</extended-message>
</extended-message-list>
</options>
</ccmp:optionsResponse>
</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 is
skipping to change at page 71, line 19 skipping to change at page 71, line 22
<xs:complexType name="conf-summary-type"> <xs:complexType name="conf-summary-type">
<xs:sequence> <xs:sequence>
<xs:element name="title" type="xs:string"/> <xs:element name="title" type="xs:string"/>
<xs:element name="status" type="xs:string"/> <xs:element name="status" type="xs:string"/>
<xs:element name="public" type="xs:boolean"/> <xs:element name="public" type="xs:boolean"/>
<xs:element name="media" type="xs:string"/> <xs:element name="media" type="xs:string"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema </xs:schema>
Figure 27: Example of XML Schema defining an extension parameter Figure 27: Example of XML Schema defining an extension parameter
(ccmp-extension-schema.xsd) (ccmp-extension-schema.xsd)
As it can be inferred from the schema file, the <confSummary> element As it can be inferred from the schema file, the <confSummary> element
contains conference information related to: contains conference information related to:
o title o title
o status (active or registered) o status (active or registered)
o participation modality (if everyone is allowed to participate, the o participation modality (if everyone is allowed to participate, the
skipping to change at page 74, line 44 skipping to change at page 74, line 44
Client and Conference Server. Such protocol is the subject of the Client and Conference Server. Such protocol is the subject of the
present document. present document.
Binary floor Control Protocol: between the Floor Control Client and Binary floor Control Protocol: between the Floor Control Client and
the Floor Control Server. Such protocol is the BFCP, specified in the Floor Control Server. Such protocol is the BFCP, specified in
[RFC4582]. [RFC4582].
Call Signaling Protocol: between the Call Signaling Client and the Call Signaling Protocol: between the Call Signaling Client and the
Focus. Such protocol can be either SIP or any other call Focus. Such protocol can be either SIP or any other call
signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating signaling protocol (e.g. H.323, IAX, etc.) capable of negotiating
a conferencing session. a conferencing session.
Notification Protocol: between the Notification Client and the XCON Notification Protocol: between the Notification Client and the XCON
Notification Service. Such protocol has not been identified as Notification Service. This specification does not define a new
yet. notification protocol. For clients that use SIP as the call
signaling protocol, the XCON event package
[I-D.ietf-xcon-event-package] MUST be used by the client for
notifications of changes in the conference data as described
below.
The CCMP protocol specified in this document is a pro-active one and The CCMP protocol specified in this document is a pro-active one and
is used by a conferencing client to send requests to a conferencing is used by a conferencing client to send requests to a conferencing
server in order to retrieve information about the conference objects server in order to retrieve information about the conference objects
it stores and potentially manipulate them. Though, it stands clear stored by the server and to potentially manipulate them. However, a
that a complete conferencing solution cannot refrain from providing complete conferencing solution is not prohibited from providing
clients with a means for receiving asynchronous updates about the clients with a means for receiving asynchronous updates about the
status of the objects available at the server. The notification status of the objects available at the server. The notification
protocol to be adopted in XCON, while conceptually independent of all protocol, while conceptually independent of all the mentioned
the mentioned companion protocols, can nonetheless be chosen in a way companion protocols, can nonetheless be chosen in a way that is
that is consistent with the overall protocol architecture consistent with the overall protocol architecture characterizing a
characterizing a specific deployment, as it is discussed in the specific deployment, as discussed in the following.
following.
When the conference control client uses SIP [RFC3261] as the When the conference control client uses SIP [RFC3261] as the
signaling protocol to participate in the conference, SIP event signaling protocol to participate in the conference, SIP event
notification can be used. In such a case, the conference control notification can be used. In such a case, the conference control
client MUST implement the Conference event package for XCON client MUST implement the Conference event package for XCON
[I-D.ietf-xcon-event-package]. This is the default mechanism for [I-D.ietf-xcon-event-package]. This is the default mechanism for
conferencing clients as is SIP for signaling per the XCON Framework conferencing clients as is SIP for signaling per the XCON Framework
[RFC5239]. [RFC5239].
In the case where the interface to the conference server is entirely In the case where the interface to the conference server is entirely
skipping to change at page 78, line 17 skipping to change at page 78, line 22
conference MUST be assured. The mechanisms to ensure the conference MUST be assured. The mechanisms to ensure the
security and privacy of identity are discussed in Section 10.3. security and privacy of identity are discussed in Section 10.3.
6. A final issue is related to Denial of Service (DoS) attacks on 6. A final issue is related to Denial of Service (DoS) attacks on
the conferencing server itself. In order to minimize the the conferencing server itself. In order to minimize the
potential for DoS attacks, it is RECOMMENDED that conferencing potential for DoS attacks, it is RECOMMENDED that conferencing
systems require user authentication and authorization for any systems require user authentication and authorization for any
client participating in a conference. This can be accomplished client participating in a conference. This can be accomplished
through the use of the mechanisms described in Section 10.2, as through the use of the mechanisms described in Section 10.2, as
well as by using the security mechanisms associated with the well as by using the security mechanisms associated with the
specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). specific signaling (e.g., SIPS) and media protocols (e.g., SRTP).
Most CCMP commands can pend indefinitely, thus increasing the
potential that pending requests can continue to increase when a
server is receiving more requests than it can process within a
specific time period. In this case a server SHOULD return a 510
response code to the pending requests. In addition, to mitigate
the situation clients MUST NOT wait indefinitely for a response
and MUST implement a timer (in the range of seconds) such that
when it expires, the client MUST close the connection.
10.1. Assuring that the Proper Conferencing Server has been contacted 10.1. Assuring that the Proper Conferencing Server has been contacted
When the CCMP transaction is conducted using TLS [RFC5246], the When the CCMP transaction is conducted using TLS [RFC5246], the
conference server can authenticate its identity, either as a domain conference server can authenticate its identity, either as a domain
name or as an IP address, to the conference client by presenting a name or as an IP address, to the conference client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). With the use of HTTP as a an iPAddress or dNSName, respectively). With the use of HTTP as a
transport for CCMP, this is exactly the authentication described by transport for CCMP, this is exactly the authentication described by
TLS [RFC2818]. If the client has external information as to the TLS [RFC2818]. If the client has external information as to the
skipping to change at page 82, line 12 skipping to change at page 82, line 27
<xs:complexType abstract="true" name="ccmp-response-message-type"> <xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType" <xs:element name="operation" type="operationType"
minOccurs="0" minOccurs="0"
maxOccurs="1" /> maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element name="response-code"
maxOccurs="1" /> type="response-codeType"
minOccurs="1" maxOccurs="1" />
<xs:element name="response-string" type="xs:string" <xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs: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>
skipping to change at page 95, line 23 skipping to change at page 95, line 38
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- CCMP ELEMENT TYPES --> <!-- CCMP ELEMENT TYPES -->
<!-- response-codeType--> <!-- response-codeType-->
<xs:element name="response-code" type="response-codeType" />
<xs:simpleType name="response-codeType"> <xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger"> <xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" /> <xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- operationType --> <!-- operationType -->
<xs:simpleType name="operationType"> <xs:simpleType name="operationType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
skipping to change at page 99, line 18 skipping to change at page 99, line 21
"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</a>.</p> <p>See RFCXXXX.</p>
</body> </body>
</html> </html>
END END
12.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon:ccmp
skipping to change at page 99, line 44 skipping to change at page 100, line 5
12.3. MIME Media Type Registration for 'application/ccmp+xml' 12.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type. This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: ccmp+xml MIME subtype name: ccmp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML for which the Same as the charset parameter of "application/xml" as specified in
default is UTF-8. RFC 3023 [RFC3023], Section 3.2.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Same as the encoding considerations of
characters, depending on the character encoding used. See RFC "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related conference control. Some of the data could protocol data related to conference control. Some of the data
be considered private and thus should be protected. could be considered private. This media type does not provide any
protection and thus other mechanisms such as those described in
Section 10 are required to protect the data. This media type does
not contain executable content.
Interoperability considerations: None. Interoperability considerations: None.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .ccmpxml
Macintosh File Type Code(s): (none) 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
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml. described there also apply to application/ccmp+xml.
12.4. DNS Registrations 12.4. DNS Registrations
skipping to change at page 105, line 48 skipping to change at page 106, line 11
[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-19 Conferencing (XCON)", draft-ietf-xcon-common-data-model-20
(work in progress), May 2010. (work in progress), October 2010.
15.2. Informative References 15.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 106, line 33 skipping to change at page 106, line 42
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[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]
Nielsen, H., Gudgin, M., Hadley, M., Moreau, J., and N. Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2
Mendelsohn, "SOAP Version 1.2 Part 1: Messaging Part 1: Messaging Framework", World Wide Web Consortium
Framework", World Wide Web Consortium FirstEdition REC- FirstEdition REC-soap12-part1-20030624, June 2003,
soap12-part1-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Nielsen, H., Moreau, J., Hadley, M., and Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2
M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Part 2: Adjuncts", World Wide Web Consortium
Web Consortium FirstEdition REC-soap12-part2-20030624, FirstEdition REC-soap12-part2-20030624, June 2003,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
 End of changes. 101 change blocks. 
640 lines changed or deleted 672 lines changed or added

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