draft-ietf-xcon-ccmp-04.txt   draft-ietf-xcon-ccmp-05.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: May 16, 2010 NS-Technologies Expires: June 27, 2010 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
November 12, 2009 December 24, 2009
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-04 draft-ietf-xcon-ccmp-05
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) can create, The Centralized Conferencing Manipulation Protocol (CCMP) can create,
retrieve, change and delete objects describing a centralized retrieve, change and delete objects describing a centralized
conference, such as state and capabilities of the conference, conference, such as state and capabilities of the conference,
participants, and their roles. The conference information is participants, and their roles. The conference information is
contained in XML documents and fragments conforming to the contained in XML documents and fragments conforming to the
centralized conferencing data model schema. Even though the goal of centralized conferencing data model schema. Even though the goal of
the CCMP is to appropriately manage conference state, the mechanisms the CCMP is to appropriately manage conference state, the mechanisms
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2010. This Internet-Draft will expire on June 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. XCON Conference Control System Architecture . . . . . . . . . 7 4. XCON Conference Control System Architecture . . . . . . . . . 7
4.1. Conference Objects . . . . . . . . . . . . . . . . . . . . 8 4.1. Conference Objects . . . . . . . . . . . . . . . . . . . 8
4.2. Conference Users . . . . . . . . . . . . . . . . . . . . . 8 4.2. Conference Users . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10 5.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 10
5.2. Implementation Approach . . . . . . . . . . . . . . . . . 12 5.2. Implementation Approach . . . . . . . . . . . . . . . . . 12
6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13 6. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13 6.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13
6.2. CCMP Response Message Type . . . . . . . . . . . . . . . . 14 6.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14
6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 6.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16
6.3.1. blueprintsRequest and blueprintsResponse . . . . . . . 19 6.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19
6.3.2. confsRequest and confsResponse . . . . . . . . . . . . 21 6.3.2. confsRequest and confsResponse . . . . . . . . . . . 22
6.3.3. blueprintRequest and blueprintResponse . . . . . . . . 22 6.3.3. blueprintRequest and blueprintResponse . . . . . . . 24
6.3.4. confRequest and confResponse . . . . . . . . . . . . . 24 6.3.4. confRequest and confResponse . . . . . . . . . . . . 26
6.3.5. usersRequest and usersResponse . . . . . . . . . . . . 27 6.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
6.3.6. userRequest and userResponse . . . . . . . . . . . . . 30 6.3.6. userRequest and userResponse . . . . . . . . . . . . 32
6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . . 34 6.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 37
6.3.8. sidebarByValRequest and sidebarByValResponse . . . . . 36 6.3.8. sidebarByValRequest and sidebarByValResponse . . . . 39
6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . . 39 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 42
6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . . 41 6.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 44
6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 44 6.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 47
7. A complete example of the CCMP in action . . . . . . . . . . . 48 7. A complete example of the CCMP in action . . . . . . . . . . 51
7.1. Alice retrieves the available blueprints . . . . . . . . . 48 7.1. Alice retrieves the available blueprints . . . . . . . . 51
7.2. Alice gets detailed information about a specific 7.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 51 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3. Alice creates a new conference through a cloning 7.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 53 operation . . . . . . . . . . . . . . . . . . . . . . . . 56
7.4. Alice updates conference information . . . . . . . . . . . 55 7.4. Alice updates conference information . . . . . . . . . . 58
7.5. Alice inserts a list of users in the conference object . . 57 7.5. Alice inserts a list of users in the conference object . 60
7.6. Alice joins the conference . . . . . . . . . . . . . . . . 59 7.6. Alice joins the conference . . . . . . . . . . . . . . . 62
7.7. Alice adds a new user to the conference . . . . . . . . . 61 7.7. Alice adds a new user to the conference . . . . . . . . . 64
8. Locating a Conference Control Server . . . . . . . . . . . . . 64 8. Locating a Conference Control Server . . . . . . . . . . . . 67
9. Managing Notifications . . . . . . . . . . . . . . . . . . . . 66 9. Managing Notifications . . . . . . . . . . . . . . . . . . . 69
10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 67 10. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 70
11. Security Considerations . . . . . . . . . . . . . . . . . . . 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 72
11.1. Assuring that the Proper Conferencing Server has been 11.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 70 contacted . . . . . . . . . . . . . . . . . . . . . . . . 73
11.2. User Authentication and Authorization . . . . . . . . . . 70 11.2. User Authentication and Authorization . . . . . . . . . . 73
11.3. Security and Privacy of Identity . . . . . . . . . . . . . 71 11.3. Security and Privacy of Identity . . . . . . . . . . . . 74
12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 72 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 75
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 83 13.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 87
13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 83 13.2. XML Schema Registration . . . . . . . . . . . . . . . . . 87
13.3. MIME Media Type Registration for 'application/ccmp+xml' . 84 13.3. MIME Media Type Registration for 'application/ccmp+xml' . 88
13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 85 13.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 89
13.4.1. Registration of a Conference Control Server 13.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 85 Application Service Tag . . . . . . . . . . . . . . . 89
13.4.2. Registration of a Conference Control Server 13.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 85 Application Protocol Tag for CCMP . . . . . . . . . . 89
13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 86 13.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 90
13.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 86 13.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 90
13.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 87 13.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 91
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
15. Changes since last Version . . . . . . . . . . . . . . . . . . 91 15. Changes since last Version . . . . . . . . . . . . . . . . . 95
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
16.1. Normative References . . . . . . . . . . . . . . . . . . . 93 16.1. Normative References . . . . . . . . . . . . . . . . . . 97
16.2. Informative References . . . . . . . . . . . . . . . . . . 93 16.2. Informative References . . . . . . . . . . . . . . . . . 97
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . . 95 considered for CCMP . . . . . . . . . . . . . . . . 99
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 95 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 99
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 96 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
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 27 skipping to change at page 5, line 27
include adding and removing participants, changing their roles, as include adding and removing participants, changing their roles, as
well as adding and removing media streams and associated end points. well as adding and removing media streams and associated end points.
The CCMP implements the client-server model within the XCON The CCMP implements the client-server model within the XCON
Framework, with the conferencing client and conference control server Framework, with the conferencing client and conference control server
acting as client and server, respectively. The CCMP uses HTTP acting as client and server, respectively. The CCMP uses HTTP
[RFC2616] as the protocol to transfer the CCMP requests and [RFC2616] as the protocol to transfer the CCMP requests and
responses, which contain the domain-specific XML-encoded data objects responses, which contain the domain-specific XML-encoded data objects
defined in the Conference Information Data Model for Centralized defined in the Conference Information Data Model for Centralized
Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model]. Conferencing (XCON Data Model) [I-D.ietf-xcon-common-data-model].
Other protocol models such as the use of a REST (REpresentational
State Transfer) architectural style [REST] were considered.
Section 4 provides an overview of the Conference Control Section 4 provides an overview of the Conference Control
functionality of the XCON framework, together with a description of functionality of the XCON framework, together with a description of
the main targets CCMP deals with, namely conference objects and the main targets CCMP deals with, namely conference objects and
conference users. A general description of the operations associated conference users. A general description of the operations associated
with protocol messages is given in Section 5 together with with protocol messages is given in Section 5 together with
implementation details. A complete example of the operation of the implementation details. A complete example of the operation of the
CCMP, describing a typical call flow associated with conference CCMP, describing a typical call flow associated with conference
creation and manipulation, is provided in Section 7. Section 12 creation and manipulation, is provided in Section 7. Section 12
provides the XML schema. provides the XML schema.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
In additon to the terms defined in the Framework for Centralized In additon to the terms defined in the Framework for Centralized
Conferencing [RFC5239], this document uses the following terms and Conferencing [RFC5239], this document uses the following terms and
acronyms: acronyms:
XCON aware client: An XCON conferencing system client which is able
to use all of the protocols of the XCON framework suite.
CRUD: CRUD stands for Create/Read/Update/Delete and indicates a CRUD: CRUD stands for Create/Read/Update/Delete and indicates a
design pattern supporting creating, retrieving, updating and design pattern supporting creating, retrieving, updating and
destroying objects. destroying objects.
REST: REpresentational State Transfer (REST) is an architectural REST: REpresentational State Transfer (REST) is an architectural
style, i.e., a coordinated set of architectural constraints. REST style, i.e., a coordinated set of architectural constraints. REST
is based on the consideration that a software architecture can is based on the consideration that a software architecture can
often be specified as an appropriate configuration of components, often be specified as an appropriate configuration of components,
data and connectors, all coordinated through constraining their data and connectors, all coordinated through constraining their
mutual relationships. Coordination and constraints help achieve a mutual relationships. Coordination and constraints help achieve a
desired set of architectural properties. [REST] desired set of architectural properties. [REST]
SOAP: Simple Object Access Protocol defined in SOAP: Simple Object Access Protocol defined in
[W3C.REC-soap12-part1-20030624] and [W3C.REC-soap12-part1-20030624] and
[W3C.REC-soap12-part2-20030624]. [W3C.REC-soap12-part2-20030624].
4. XCON Conference Control System Architecture 4. XCON Conference Control System Architecture
CCMP supports the XCON framework . Figure 1 depicts a subset of the CCMP supports the XCON framework. Figure 1 depicts a subset of the
"Conferencing System Logical Decomposition" architecture from the "Conferencing System Logical Decomposition" architecture from the
XCON framework document. It illustrates the role that CCMP assumes XCON framework document. It illustrates the role that CCMP assumes
within the overall centralized architecture. within the overall centralized architecture.
........................................................ ........................................................
. Conferencing System . . Conferencing System .
. . . .
. +---------------------------------------+ . . +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | . . | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | . . +-+-------------------------------------+ | .
skipping to change at page 11, line 51 skipping to change at page 11, line 51
conference user. conference user.
Thus, the main targets of CCMP operations are: Thus, the main targets of CCMP operations are:
o conference objects associated with either active or registered o conference objects associated with either active or registered
conferences, conferences,
o conference objects associated with blueprints, o conference objects associated with blueprints,
o conference objects associated with sidebars, both embedded in the o conference objects associated with sidebars, both embedded in the
main conference (i.e. <sidebars-by-value> elements) and external main conference (i.e. <entry> elements in <sidebars-by-value>) and
to it (i.e. <sidebars-by-ref> elements), external to it (i.e. whose xcon-uris are included in the <entry>
elements of <sidebars-by-ref>)],
o <user> elements associated with conference users, o <user> elements associated with conference users,
o the list of XCON-URIs related to conferences and blueprints o the list of XCON-URIs related to conferences and blueprints
available at the server, for which only retrieval operations are available at the server, for which only retrieval operations are
allowed. allowed.
Each operation in the protocol model is atomic and either succeeds or Each operation in the protocol model is atomic and either succeeds or
fails as a whole. The conference server MUST ensure that the fails as a whole. The conference server MUST ensure that the
operations are atomic in that the operation invoked by a specific operations are atomic in that the operation invoked by a specific
skipping to change at page 12, line 26 skipping to change at page 12, line 27
functionality are out of scope for the CCMP protocol specification functionality are out of scope for the CCMP protocol specification
and are implementation specific for a conference server. Thus, the and are implementation specific for a conference server. Thus, the
conference server first checks all the parameters, before making any conference server first checks all the parameters, before making any
changes to the internal representation of the conference object. For changes to the internal representation of the conference object. For
example, it would be undesirable to change the <subject> of the example, it would be undesirable to change the <subject> of the
conference, but then detect an invalid URI in one of the <service- conference, but then detect an invalid URI in one of the <service-
uris> and abort the remaining updates. Also, since multiple clients uris> and abort the remaining updates. Also, since multiple clients
can modify the same conference objects, conference clients SHOULD can modify the same conference objects, conference clients SHOULD
first obtain the current object from the conference server and then first obtain the current object from the conference server and then
update the relevant data elements in the conference object prior to update the relevant data elements in the conference object prior to
invoking a specific operation on the conference server. In order to invoking a specific operation on the conference server.
effectively manage modifications to conference data, a versioning
approach is exploited in the CCMP. More precisely, each conference In order to effectively manage modifications to conference data, a
object is associated with a version number indicating the most up to versioning approach is implemented in the CCMP. More precisely, each
date view of the conference at the server's side. Such version conference object is associated with a version number indicating the
number is reported to the clients when answering their requests. A most up to date view of the conference at the server's side. This
client willing to make modifications to a conference object has to version number is reported to the clients in response to their
send an update message to the server. In case the modifications are requests. A client sends an "update" message to the server to make
all successfully applied, the server sends back to the client a modifications to a conference object. If the modifications are all
"success" response which also carries information about the current successfully applied, the server sends a "success" response to the
server-side version of the modified object. With such approach, a client. This response contains information about the current server-
client which is working on version "X" of a conference object and side version of the modified object. With this approach, a client
finds inside a "success" response a version number which is "X+1" can working on version "X" of a conference object that finds a version
be sure that the version it was aware of was the most up to date. On number which is "X+1" inside a "success" response can be certain that
the other hand, if the "success" response carries back a version the version being used is the most up to date. On the other hand, if
which is at least "X+2", the client can detect that the object that the "success" response contains a version which is at least "X+2",
has been modified at the server's side was more up to date than the the client can detect that the object that has been modified at the
one it was working upon. This is clearly due to the effect of server's side was more up to date than the one it was working upon.
concurrent modification requests issued by independent clients. This is clearly due to the effect of concurrent modification requests
Hence, for the sake of having available the latest version of the issued by independent clients. Hence, to ensure that the client has
modified object, the client can send to the conference server a the latest version of the modified object, the client can send an
further "retrieve" request. In no case a copy of the conference additional "retrieve" request to the conference server. If a copy of
object available at the server is returned to the client as part of the conference object is not returned to the client as part of the
the update response message. Such a copy can always be obtained "update" response message, the client can obtain a copy through an
through an ad-hoc "retrieve" message. Based on the above ad-hoc "retrieve" message.
considerations, all CCMP response messages except those associated
with the retrieval of either the list of blueprints or the list of Based on the above considerations, all CCMP response messages except
conferences will have to contain a mandatory "version" parameter. those associated with the retrieval of either the list of blueprints
This does not hold for request messages, for which the "version" or the list of conferences MUST contain a mandatory "version"
parameter is not at all required, since it represents useless parameter. The "version" parameter is not included in request
information for the server: as long as the required modifications can messages, since it represents information the server does not need:
be applied to the target conference object with no conflicts, the as long as the required modifications can be applied to the target
server does not care whether or not the client had an up to date view conference object with no conflicts, the server does not care whether
of the information stored at its side. This said, it stands clear the client had an up to date view of the information. Thus, a client
that a client which has subscribed at the server, through the XCON which has subscribed at the server, through the XCON event package
event package [I-D.ietf-xcon-event-package], to notifications about [I-D.ietf-xcon-event-package], to notifications about conference
conference object modifications, will always have the most up to date object modifications, always has the most up to date version of the
version of that object available at his side. conference object.
5.2. Implementation Approach 5.2. Implementation Approach
There have been a number of different proposals as to the most There have been a number of different proposals as to the most
suitable implementation solution for the CCMP. A non-exhaustive suitable implementation solution for the CCMP. A non-exhaustive
summary of the most interesting ones is provided in Appendix A. The summary of the most interesting ones is provided in Appendix A. The
solution for the CCMP defined in this document is viewed as a good solution for the CCMP defined in this document is viewed as a good
compromise amongst the most notable past candidates and is referred compromise amongst the most notable past candidates and is referred
to as "HTTP transport plus CCMP body". With this approach, CCMP is to as "HTTP transport plus CCMP body". With this approach, CCMP is
able to take advantage of existing HTTP functionality. As with SOAP, able to take advantage of existing HTTP functionality. As with SOAP,
skipping to change at page 14, line 18 skipping to change at page 14, line 18
request message is defined in Section 6.1. The general CCMP response request message is defined in Section 6.1. The general CCMP response
message is defined in Section 6.2. The details of the specific message is defined in Section 6.2. The details of the specific
message type which is carried in the CCMP request and response message type which is carried in the CCMP request and response
messages are described in Section 6.3. CCMP response codes are messages are described in Section 6.3. CCMP response codes are
listed in Section 6.4 listed in Section 6.4
6.1. CCMP Request Message Type 6.1. CCMP Request Message Type
A CCMP request message is comprised of the following parameters: A CCMP request message is comprised of the following parameters:
confUserId: An optional parameter containing the XCON-USERID of the confUserID: An optional parameter containing the XCON-USERID of the
client. The "confUserID" parameter is used to determine if the client. The "confUserID" parameter is used to determine if the
conference control client has the authority to perform the conference control client has the authority to perform the
operation, as well as other Authorization, Authentication and operation, as well as other Authorization, Authentication and
Accounting (AAA) procedures. The attribute is REQUIRED in the Accounting (AAA) procedures. The attribute is REQUIRED in the
CCMP request and response messages with the exception of the case CCMP request and response messages with the exception of the case
of a user who has no XCON-USERID and who wants to enter, via CCMP, of a user who has no XCON-USERID and who wants to enter, via CCMP,
a conference whose identifier is known. In such case, a side- a conference whose identifier is known. In such case, a side-
effect of the request is that the user is provided with an effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 6.3.6. will be provided in Section 6.3.6.
confObjId: An optional parameter containing the XCON-URI of the confObjID: An optional parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter refining the type of specialized operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest" requests except for the "blueprintsRequest" and "confsRequest"
specialized messages. specialized messages.
password: An optional parameter that MUST be inserted in all password: An optional parameter that MUST be inserted in all
requests whose target conference object is password-protected (as requests whose target conference object is password-protected (as
per the <conference-password> element in per the <conference-password> element in
skipping to change at page 15, line 38 skipping to change at page 15, line 38
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 2: Structure of CCMP Request messages Figure 2: Structure of CCMP Request messages
6.2. CCMP Response Message Type 6.2. CCMP Response Message Type
A CCMP response message is comprised of the following parameters: A CCMP response message is comprised of the following parameters:
confUserId: A mandatory parameter in CCMP response messages confUserID: A mandatory parameter in CCMP response messages
containing the XCON-USERID of the conferencing client who issued containing the XCON-USERID of the conferencing client who issued
the CCMP request message. the CCMP request message.
confObjId: An optional parameter containing the XCON-URI of the confObjID: An optional parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter for CCMP response messages. This operation: An optional parameter for CCMP response messages. This
parameter is REQUIRED in all responses except for the parameter is REQUIRED in all responses except for the
"blueprintsResponse" and "confsResponse" specialized messages. "blueprintsResponse" and "confsResponse" specialized messages.
response-code: A mandatory parameter containing the response code response-code: A mandatory parameter containing the response code
associated with the request. The response code MUST be chosen associated with the request. The response code MUST be chosen
from the codes listed in Section 6.4. from the codes listed in Section 6.4.
response-string: An optional reason string associated with the response-string: An optional reason string associated with the
response. In case of an error, in particular, such string can be response. In case of an error, the string can be used to provide
used to provide the client with detailed information about the the client with detailed information about the error.
error itself.
specialized response message: This is specialization of the generic version: An optional parameter reflecting the current version number
response message, containing parameters that are dependent on the of the conference object referenced by the confObjID. The version
specific request sent to the server (e.g., blueprintsResponse). A number is contained in the "version" attribute of the <conference-
specialized response message SHOULD be included in the CCMP info> element related to that conference.
response message, except in an error situation where the CCMP
request message did not contain a valid specialized message. In specialized response message: This is a specialization of the
this case, the conference server MUST return a responseCode of generic response message, containing parameters that are dependent
"badRequest". The details for the specialized messages and on the specific request sent to the server (e.g.,
associated parameters are provided in Section 6.3. blueprintsResponse). A specialized response message SHOULD be
included in the CCMP response message, except in an error
situation where the CCMP request message did not contain a valid
specialized message. In this case, the conference server MUST
return a "response-code" of "badRequest". The details for the
specialized messages and associated parameters are provided in
Section 6.3.
<xs:element name="ccmpResponse" type="ccmp-response-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP response definition --> <!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type"> <xs:complexType name="ccmp-response-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpResponse" <xs:element name="ccmpResponse"
type="ccmp-response-message-type" /> type="ccmp-response-message-type" />
</xs:sequence> </xs:sequence>
skipping to change at page 20, line 33 skipping to change at page 20, line 33
| equest | sidebar | sidebar by | modifies | deletes | | equest | sidebar | sidebar by | modifies | deletes |
| | element | cloning | sidebar | entire | | | element | cloning | sidebar | entire |
| | | existing | | sidebar | | | | existing | | sidebar |
| | | conf | | | | | | conf | | |
| | | object | | | | | | object | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 1: Request Type Operation Specific Processing
(**): This operation can involve the creation of an XCON-UserID, if (**): This operation can involve the creation of an XCON-UserID, if
the sender does not add it in the "confUserId" parameter, or if the the sender does not add it in the "confUserID" parameter, or if the
"entity" field of the userInfo parameter is void. "entity" field of the userInfo parameter is void.
Additional parameters included in the specialized CCMP request/ Additional parameters included in the specialized CCMP request/
response messages are detailed in the subsequent sections. response messages are detailed in the subsequent sections.
6.3.1. blueprintsRequest and blueprintsResponse 6.3.1. blueprintsRequest and blueprintsResponse
A "blueprintsRequest" (Figure 4) message is sent to request the list A "blueprintsRequest" (Figure 4) message is sent to request the list
of XCON-URIs associated with the available blueprints from the of XCON-URIs associated with the available blueprints from the
conference server. Such URIs can be subsequently used by the client conference server. Such URIs can be subsequently used by the client
to access detailed information about a specified blueprint with a to access detailed information about a specified blueprint with a
specific "blueprintRequest" message per Section 6.3.3. A specific "blueprintRequest" message per Section 6.3.3. A
"blueprintsRequest" message REQUIRES no additional parameters beyond "blueprintsRequest" message REQUIRES no additional parameters beyond
those specified for the basic CCMP request message. The "confObjId" those specified for the basic CCMP request message. The "confObjID"
and "operation" parameters MUST NOT be included in the request or and "operation" parameters MUST NOT be included in the request or
response for this transaction. response for this transaction. A "blueprintsRequest" message MAY
contain an optional "xpathFilter" parameter, which can be used to
instruct the server on how to filter-out unwanted information from
the response. This parameter is of type "xs:string" for generality.
The "xpathFilter" parameter MUST represent a syntactically correct
XPath [W3C.REC-xpath-19991116] string used by the server to properly
query the conference document database it manages.
The associated "blueprintsResponse" message SHOULD contain, as shown The associated "blueprintsResponse" message SHOULD contain, as shown
in Figure 4, a "blueprintsInfo" parameter containing the above in Figure 4, a "blueprintsInfo" parameter containing the above
mentioned XCON-URI list. If the "blueprintsInfo" parameter is empty, mentioned XCON-URI list. If the "blueprintsInfo" parameter is empty,
the conference control client MAY attempt to use a local default the conference control client MAY attempt to use a local default
blueprint to create conferences. However, the handling in this blueprint to create conferences. However, the handling in this
situation is specific to the conference control client situation is specific to the conference control client
implementation. implementation.
<!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type">
</xs:complexContent> <xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="blueprintsRequest"
type="blueprintsRequestType" />
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- blueprintsResponse --> <!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsResponse"/> <xs:element ref="blueprintsResponse"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 22, line 8 skipping to change at page 23, line 8
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 4: Structure of the blueprintsRequest and blueprintsResponse Figure 4: Structure of the blueprintsRequest and blueprintsResponse
messages messages
6.3.2. confsRequest and confsResponse 6.3.2. confsRequest and confsResponse
A "confsRequest" message is used to retrieve, from the server, the A "confsRequest" message is used to retrieve, from the server, the
list of XCON-URIs associated with active and registered conferences A list of XCON-URIs associated with active and registered conferences.
"confsRequest" message REQUIRES no additional parameters beyond those A "confsRequest" message REQUIRES no additional parameters beyond
specified for the basic CCMP request message. The "confObjId" those specified for the basic CCMP request message. The "confObjID"
parameter MUST NOT be included in the confsRequest message. The parameter MUST NOT be included in the confsRequest message. The
"confsRequest" message is of a "retrieve-only" type, since the sole "confsRequest" message is of a "retrieve-only" type, since the sole
purpose is to collect information available at the conference server. purpose is to collect information available at the conference server.
Thus, an "operation" parameter MUST NOT be included in a Thus, an "operation" parameter MUST NOT be included in a
"confsRequest" message. The associated "confsResponse" message "confsRequest" message. The associated "confsResponse" message
SHOULD contain the list of XCON-URIs in the "confsInfo" parameter. A SHOULD contain the list of XCON-URIs in the "confsInfo" parameter. A
user, upon receipt of the response message, can interact with the user, upon receipt of the response message, can interact with the
available conference objects through further CCMP messages. available conference objects through further CCMP messages. A
"confsRequest" message MAY contain an optional "xpathFilter"
parameter, which can be used to instruct the server on how to filter-
out unwanted information from the response. This parameter is of
type "xs:string" for generality. The "xpathFilter" parameter MUST
represent a syntactically correct XPath [W3C.REC-xpath-19991116]
string used by the server to properly query the conference document
database it manages. As an example, to retrieve just registered
conferences, a CCMP client can configure the mentioned "xpathFilter"
parameter as follows: xpathFilter="/
info:conference-info[info:conference-state/info:active='false']";
<!-- confsRequest --> <!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- confsResponse --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsResponse" /> <xs:element ref="confsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 23, line 4 skipping to change at page 24, line 47
<!-- confsResponseType --> <!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType"/> <xs:element name="confsResponse" type="confsResponseType"/>
<xs:complexType name="confsResponseType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confsInfo" <xs:element name="confsInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 5: Structure of the confsRequest and confsResponse messages Figure 5: Structure of the confsRequest and confsResponse messages
6.3.3. blueprintRequest and blueprintResponse 6.3.3. blueprintRequest and blueprintResponse
Through a "blueprintRequest", a client can manipulate the conference Through a "blueprintRequest", a client can manipulate the conference
object associated with a specified blueprint. The request MUST object associated with a specified blueprint. The request MUST
include an "operation" parameter and a "confObjId" parameter. The include an "operation" parameter and a "confObjID" parameter. The
"confObjId" parameter MUST contain the XCON-URI of the blueprint, "confObjID" parameter MUST contain the XCON-URI of the blueprint,
which might have been previously retrieved through a which might have been previously retrieved through a
"blueprintsRequest" message. The blueprintRequest message SHOULD NOT "blueprintsRequest" message. The blueprintRequest message SHOULD NOT
contain an "operation" parameter other than "retrieve". The contain an "operation" parameter other than "retrieve". The
"create", "update" and "delete" operations SHOULD NOT be included in "create", "update" and "delete" operations SHOULD NOT be included in
a "blueprintRequest" message except in the case of privileged users a "blueprintRequest" message except in the case of privileged users
(e.g. the conference server administration staff). (e.g. the conference server administration staff).
In the case of responseCode of "success" for a "retrieve" operation, In the case of "response-code" of "success" for a "retrieve"
the "blueprintInfo" parameter MUST be included in the operation, the "blueprintInfo" parameter MUST be included in the
"blueprintResponse" message. The "blueprintInfo" parameter contains "blueprintResponse" message. The "blueprintInfo" parameter contains
the conference document associated with the blueprint as identified the conference document associated with the blueprint as identified
by the "confObjID" parameter specified in the blueprintRequest. by the "confObjID" parameter specified in the blueprintRequest.
If a response code fo "objectNotFound" is received in a If a response code of "objectNotFound" is received in a
"blueprintResponse" message, a conference control client may attempt "blueprintResponse" message, a conference control client may attempt
to retrieve another conference blueprint if more than one had been to retrieve another conference blueprint if more than one had been
received in the "blueprintsResponse" message. If there was only one received in the "blueprintsResponse" message. If there was only one
blueprint in the "blueprintsResponse" initially, then the client blueprint in the "blueprintsResponse" initially, then the client
should send another "blueprintsRequest" message to determine if there should send another "blueprintsRequest" message to determine if there
may be new or additional blueprints for the specific conferencing may be new or additional blueprints for the specific conferencing
system. If this "blueprintsResponse" message contains no blueprints, system. If this "blueprintsResponse" message contains no blueprints,
the handling is specific to the conference control client. the handling is specific to the conference control client.
<!-- blueprintRequest --> <!-- blueprintRequest -->
skipping to change at page 25, line 11 skipping to change at page 27, line 11
Figure 6: Structure of the blueprintRequest and blueprintResponse Figure 6: Structure of the blueprintRequest and blueprintResponse
messages messages
6.3.4. confRequest and confResponse 6.3.4. confRequest and confResponse
With a "confRequest" message, CCMP clients can manipulate conference With a "confRequest" message, CCMP clients can manipulate conference
objects associated with either active or registered conferences objects associated with either active or registered conferences
(blueprints or reservations). The request MUST include an (blueprints or reservations). The request MUST include an
"operation" parameter. Depending upon the type of "operation" a "operation" parameter. Depending upon the type of "operation" a
"confObjId" parameter MAY be included. The "confObjId" parameter "confObjID" parameter MAY be included. The "confObjID" parameter
contains the XCON-URI of the specific active or registered contains the XCON-URI of the specific active or registered
conference. The requirements for inclusion of "confInfo" parameter conference. The requirements for inclusion of "confInfo" parameter
depends upon the specific "operation" in the confRequest/confResponse depends upon the specific "operation" in the confRequest/confResponse
and are detailed below. The detailed information included in the and are detailed below. The detailed information included in the
"confInfo" parameter MUST follow the rules as specified in the XCON "confInfo" parameter MUST follow the rules as specified in the XCON
Data Model document [I-D.ietf-xcon-common-data-model]. Data Model document [I-D.ietf-xcon-common-data-model].
To create a new conference through a "confRequest" message, two To create a new conference through a "confRequest" message, two
approaches can be considered: 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 to be cloned, while the contain the XCON-URI of either the blueprint, or of the
"confInfo" parameter MUST NOT be included in the confRequest; conference, to be cloned, while the "confInfo" parameter MUST NOT
be included in the confRequest;
2. Creation through implicit cloning (also known as "direct 2. Creation through implicit cloning (also known as "direct
creation"): the "confObjId" parameter MUST NOT be included in the creation"): the "confObjID" parameter MUST NOT be included in the
request, whereas the "confInfo" parameter describing the request and the CCMP client can describe the desired conference
conference to be created MUST be included in the confRequest. to be created through the "confInfo" parameter. If no "confInfo"
parameter is provided in the request, the new conference will be
created as a clone of the system's default blueprint.
In both cases, the confResponse, for a successful completion of a In both cases, the confResponse, for a successful completion of a
"create" operation, contains a responseCode of "success" and MUST "create" operation, contains a "response-code" of "success" and MUST
contain the XCON-URI of the created conference in the "confObjID" contain the XCON-URI of the created conference in the "confObjID"
parameter. In addition, the "confInfo" parameter transporting the parameter. In addition, the "confInfo" parameter transporting the
created conference document MAY be included. Obviously, the newly created conference document MAY be included. Obviously, the newly
created object can be manipulated by the client through a subsequent created object can be manipulated by the client through a subsequent
"update" operation. For example, after the creation and addition of "update" operation. For example, after the creation and addition of
the participants, the creator may want to lock the conference object. the participants, the creator may want to lock the conference object.
This can be accomplished with a confRequest with an operation of This can be accomplished with a confRequest with an operation of
"update" by setting the "locked" element in the confInfo included in "update" by setting the "locked" element in the confInfo included in
the confRequest message described below. the confRequest message described below.
In the case of a confRequest with a "retrieve" operation, the In the case of a confRequest with a "retrieve" operation, the
"confObjId" representing the XCON-URI of the target conference the "confObjID" representing the XCON-URI of the target conference the
conference control client MUST be included and the "confInfo" conference control client MUST be included and the "confInfo"
parameter SHOULD NOT be included in the request. The conferencing parameter SHOULD NOT be included in the request. The conferencing
server MUST ignore any "confInfo" parameter that is received in a server MUST ignore any "confInfo" parameter that is received in a
"confRequest" and this "confInfo" parameter MUST NOT be included in "confRequest" and this "confInfo" parameter MUST NOT be included in
the confResponse. If the confResponse for the "retrieve" operation the confResponse. If the confResponse for the "retrieve" operation
contains a responseCode of "success", the "confInfo" parameter MUST contains a "response-code" of "success", the "confInfo" parameter
be included in the response. The "confInfo" parameter MUST contain MUST be included in the response. The "confInfo" parameter MUST
the entire conference document describing the target conference contain the entire conference document describing the target
object in its current state. conference object in its current state.
In case of a confRequest with an "update" operation, the "confInfo" In case of a confRequest with an "update" operation, the "confInfo"
and "confObjID" MUST be included in the request. The "confInfo" and "confObjID" MUST be included in the request. The "confInfo"
represents an object of type "conference-type" containing all the represents an object of type "conference-type" containing all the
changes to be applied to the conference whose identifier is changes to be applied to the conference whose identifier is
"confObjId". In the case of a confResponse with a responseCode of "confObjID". In the case of a confResponse with a "response-code" of
"success", no additional information is required in the "success", no additional information is required in the
"confResponse" message. A responseCode of "success" indicates that "confResponse" message. A "response-code" of "success" indicates
the referenced conference document has been changed by the conference that the referenced conference document has been changed by the
server. A responseCode of "changeFailedProtected" indicates that the conference server. A "response-code" of "changeFailedProtected"
conferencing client is not allowed to make the changes reflected in indicates that the conferencing client is not allowed to make the
the "confInfo" in the initial request. This could be due to changes reflected in the "confInfo" in the initial request. This
policies, roles, specific privileges, etc.), with the reason specific might be due to policies, roles, specific privileges, etc.), with the
to a conferencing system and its configuration. Thus, it is reason specific to a conferencing system and its configuration.
RECOMMENDED that the client continue using the previous version of
the "confInfo", if the conference was active. If the conference was
not active, it is RECOMMENDED that the client revert to an original
version of the blueprint or use another blueprint - one previously
retrieved with a blueprintRequest or one obtained via a new
blueprintsRequest/blueprintRequest sequence.
In the case of a confRequest with a "delete" operation, the In the case of a confRequest with a "delete" operation, the
"confObjId" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included and the "confInfo" SHOULD NOT be included in the request. be included and the "confInfo" SHOULD NOT be included in the request.
The conferencing server MUST ignore any "confInfo" parameter that is The conferencing server MUST ignore any "confInfo" parameter that is
received. The confResponse MUST contain the same "confObjId" that received. The confResponse MUST contain the same "confObjID" that
was included in the confRequest. The confResponse MUST contain a was included in the confRequest. The confResponse MUST contain a
responseCode of "success" if the targeted conference is successfully "response-code" of "success" if the targeted conference is
deleted. If the confResponse for the "retrieve" operation contains a successfully deleted. If the confResponse for the "delete" operation
responseCode of "success", the confResponse SHOULD NOT contain the contains a "response-code" of "success", the confResponse MUST NOT
"confInfo" parameter. If the conferencing server cannot delete the contain the "confInfo" parameter. If the conferencing server cannot
conference referenced by the "confObjId" received in the confRequest delete the conference referenced by the "confObjID" received in the
because it is the parent of another conference object that is in use, confRequest because it is the parent of another conference object
the conferencing server MUST return a responseCode of that is in use, the conferencing server MUST return a "response-code"
"deleteParentFailed". of "deleteParentFailed".
The schema for the confRequest/confResponse pair is shown in The schema for the confRequest/confResponse pair is shown in
Figure 7. Figure 7.
<!-- confRequest --> <!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
skipping to change at page 28, line 32 skipping to change at page 30, line 32
</conference-description> </conference-description>
</conf-info> </conf-info>
Figure 9: Updating a conference object: removing the title of a Figure 9: Updating a conference object: removing the title of a
conference conference
6.3.5. usersRequest and usersResponse 6.3.5. usersRequest and usersResponse
Through a usersRequest message the CCMP client manipulates the Through a usersRequest message the CCMP client manipulates the
<users> element of the conference document associated with the <users> element of the conference document associated with the
conference identified by the "confObjId" parameter. Inside the conference identified by the "confObjID" parameter. Inside the
<users> element, along with the list of conference users, there is <users> element, along with the list of conference users, there is
information that the client may be interested in controlling, such as information that the client may be interested in controlling, such as
the lists of users to which access to the conference is allowed/ the lists of users to which access to the conference is allowed/
denied, conference participation policies, etc.; for this reason, a denied, conference participation policies, etc.; for this reason, a
customized message has been designed to allow for the manipulation of customized message has been designed to allow for the manipulation of
this specific part of a conference document. this specific part of a conference document.
A "usersInfo" parameter MAY be included in a usersRequest message A "usersInfo" parameter MAY be included in a usersRequest message
depending upon the operation. If the "usersInfo" parameter is depending upon the operation. If the "usersInfo" parameter is
included in the usersRequest message, the parameter MUST be compliant included in the usersRequest message, the parameter MUST be compliant
skipping to change at page 29, line 15 skipping to change at page 31, line 15
Two operations are allowed for a "usersRequest" message: Two operations are allowed for a "usersRequest" message:
1. "retrieve": In this case the request MUST NOT include a 1. "retrieve": In this case the request MUST NOT include a
"usersInfo" parameter, while a successful response MUST contain "usersInfo" parameter, while a successful response MUST contain
the desired <users> element in the "usersInfo" parameter. The the desired <users> element in the "usersInfo" parameter. The
conference server MUST be ignore a "usersInfo" parameter if it is conference server MUST be ignore a "usersInfo" parameter if it is
received in a request with a "retrieve" operation. received in a request with a "retrieve" operation.
2. update: In this case, the "usersInfo" parameter MUST contain the 2. update: In this case, the "usersInfo" parameter MUST contain the
modifications to be applied to the referred <users> element. If modifications to be applied to the referred <users> element. If
the responseCode is "success", then the "usersInfo" parameter the "response-code" is "success", then the "usersInfo" parameter
SHOULD NOT be returned. Any "usersInfo" parameter that is SHOULD NOT be returned. Any "usersInfo" parameter that is
returned SHOULD be ignored. A responseCode of returned SHOULD be ignored. A "response-code" of
"changeFailedProtected" indicates that the conferencing client is "changeFailedProtected" indicates that the conferencing client is
not allowed to make the changes reflected in the "usersInfo" in not allowed to make the changes reflected in the "usersInfo" in
usersRequest message. This could be due to policies, roles, usersRequest message. This could be due to policies, roles,
specific privileges, etc.), with the reason specific to a specific privileges, etc.), with the reason specific to a
conferencing system and its configuration. Thus, it is conferencing system and its configuration. Thus, it is
RECOMMENDED that the client continue using the previous version RECOMMENDED that the client continue using the previous version
of the "usersInfo". of the "usersInfo".
Operations of "create" and "delete" are not applicable to a Operations of "create" and "delete" are not applicable to a
usersRequest message and MUST NOT be considered by the server, which usersRequest message and MUST NOT be considered by the server, which
means that a responseCode of "forbidden" MUST be included in the means that a "response-code" of "forbidden" MUST be included in the
usersResponse message. usersResponse message.
<!-- usersRequest --> <!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type"> <xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersRequest" /> <xs:element ref="usersRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 31, line 9 skipping to change at page 33, line 9
<xs:element name="usersInfo" type="info:users-type"/> <xs:element name="usersInfo" type="info:users-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 10: Structure of the usersRequest and usersResponse messages Figure 10: Structure of the usersRequest and usersResponse messages
6.3.6. userRequest and userResponse 6.3.6. userRequest and userResponse
A "userRequest" message is used to manipulate <user> elements inside A "userRequest" message is used to manipulate <user> elements inside
a conference document associated with a conference identified by the a conference document associated with a conference identified by the
"confObjId" parameter. Besides retrieving information about a "confObjID" parameter. Besides retrieving information about a
specific conference user, the message is used to request that the specific conference user, the message is used to request that the
conference server either create, modify, or delete information about conference server either create, modify, or delete information about
a user. A "userRequest" message MUST include the "confObjID", the a user. A "userRequest" message MUST include the "confObjID", the
"operation" parameter, and MAY include a "userInfo" parameter "operation" parameter, and MAY include a "userInfo" parameter
containing the detailed user's information depending upon the containing the detailed user's information depending upon the
operation and whether the "userInfo" has already been populated for a operation and whether the "userInfo" has already been populated for a
specific user. Note that a user may not necessarily be a specific user. Note that a user may not necessarily be a
conferencing control client (i.e., some participants in a conference conferencing control client (i.e., some participants in a conference
are not "XCON aware"). are not "XCON aware").
An XCON-USERID SHOULD be assigned to each and every user subscribed An XCON-USERID SHOULD be assigned to each and every user subscribed
to the system. In such a way, a user who is not a conference to the system. In such a way, a user who is not a conference
participant can make requests (provided she has successfully passed participant can make requests (provided she has successfully passed
AAA checks), like creating a conference, retrieving conference AAA checks), like creating a conference, retrieving conference
information, etc.. information, etc..
Conference users can be created in a number of different ways. In Conference users can be created in a number of different ways. In
each of these cases the operation MUST be set to "create" in the each of these cases the operation MUST be set to "create" in the
userRequest message. Each of the userResponse messages for these userRequest message. Each of the userResponse messages for these
cases MUST include the "confObjID", "confUserID", "operation" and cases MUST include the "confObjID", "confUserID", "operation" and
"responseCode" parameters. In the case of a response code of "response-code" parameters. In the case of a response code of
"success", the userResponse message MAY include the "userInfo" "success", the userResponse message MAY include the "userInfo"
parameter depending upon the manner in which the user was created: parameter depending upon the manner in which the user was created:
o Conferencing client with an XCON-USERID adds itself to the o Conferencing client with an XCON-USERID adds itself to the
conference: In this case, the "userInfo" parameter MAY be included conference: In this case, the "userInfo" parameter MAY be included
in the userRequest. The "userInfo" parameter MUST contain a in the userRequest. The "userInfo" parameter MUST contain a
<user> element (compliant with the XCON data model) and the <user> element (compliant with the XCON data model) and the
"entity" attribute MUST be set to a value which represents the "entity" attribute MUST be set to a value which represents the
XCON-USERID of the user initiating the request. No additional XCON-USERID of the user initiating the request. No additional
parameters beyond those previously described are required in the parameters beyond those previously described are required in the
userResponse message, in the case of a responseCode of "success". userResponse message, in the case of a "response-code" of
"success".
o Conferencing client acts on behalf of a third user whose XCON- o Conferencing client acts on behalf of a third user whose XCON-
USERID is known: in this case, the "userInfo" parameter MUST be USERID is known: in this case, the "userInfo" parameter MUST be
included in the userRequest. The "userInfo" parameter MUST included in the userRequest. The "userInfo" parameter MUST
contain a <user> element and the "entity" attribute value MUST be contain a <user> element and the "entity" attribute value MUST be
set to the XCON-USERID of the third user in question. No set to the XCON-USERID of the third user in question. No
additional parameters beyond those previously described are additional parameters beyond those previously described are
required in the userResponse message, in the case of a required in the userResponse message, in the case of a "response-
responseCode of "success". code" of "success".
o A conferencing client who has no XCON-USERID and who wants to o A conferencing client who has no XCON-USERID and who wants to
enter, via CCMP, a conference whose identifier is known. In such enter, via CCMP, a conference whose identifier is known. In such
case, a side-effect of the request is that the user is provided case, a side-effect of the request is that the user is provided
with an appropriate XCON-USERID. The involved messages with an appropriate XCON-USERID. The involved messages
(userRequest and userResponse) in such case should look like the (userRequest and userResponse) in such case should look like the
following: following:
Request fields: Request fields:
confUserId=null; confUserID=null;
confObjId=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
userInfo= userInfo=
<userInfo entity=null> <userInfo entity=null>
<endpoint entity="sip:GHIL345@blablabla"> <endpoint entity="sip:GHIL345@blablabla">
... ...
Response fields (in case of success): Response fields (in case of success):
confUserId=user345; confUserID=user345;
confObjId=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
response-code=success; response-code=success;
userInfo=null; //or the entire userInfo object userInfo=null; //or the entire userInfo object
Figure 11: userRequest and userResponse in the absence of an xcon- Figure 11: userRequest and userResponse in the absence of an xcon-
userid userid
o Conferencing client is unaware of the XCON-USERID of a third user: o Conferencing client is unaware of the XCON-USERID of a third user:
In this case, the "entity" attribute MUST NOT be included in the In this case, the "entity" attribute MUST NOT be included in the
request. The XCON-USERID generated by the conference server for request. The XCON-USERID generated by the conference server for
such a user MUST also be returned to the client as the value of such a user MUST also be returned to the client as the value of
the "entity" attribute in the "userInfo" parameter of the response the "entity" attribute in the "userInfo" parameter of the response
if the responseCode is "success". This scenario is mainly if the "response-code" is "success". This scenario is mainly
intended to support the case whereby an XCON aware client is added intended to support the case whereby a non-registered user is
to a conference by a third party, e.g. the chairperson of the added to a conference by a third party, e.g. the chairperson of
conference. the conference.
o Conferencing client obtains a new user profile in the context of a o Conferencing client obtains a new user profile in the context of a
conference: this case is handled in the same manner as the conference: this case is handled in the same manner as the
previous case associated with the creation of a user on behalf of previous case associated with the creation of a user on behalf of
a third party when the XCON-USERID is unknown, thus indicating to a third party when the XCON-USERID is unknown, thus indicating to
the conference server that the client wants a new XCON-USERID and the conference server that the client wants a new XCON-USERID and
associated "userInfo" parameter to be allocated and populated associated "userInfo" parameter to be allocated and populated
respectively. respectively.
In the case of a userRequest with a "retrieve" operation, the In the case of a userRequest with a "retrieve" operation, the
"confObjId" representing the XCON-URI of the target conference MUST "confObjID" representing the XCON-URI of the target conference MUST
be included. The "confUserId" MUST be included in the userRequest be included. The "confUserID", containing the xcon-userid of the
message. This "confUserId" indicates the specific <user> element in CCMP client, MUST also be included in the userRequest message. If
XCON data model, as reflected by the "entity" attribute in the <user> the client wants to retrieve information about her profile in the
element that the conference client is requesting to retrieve. The specified conference, no "userInfo" parameter is needed in the
"userInfo" parameter MUST NOT be included in the request. The retrieve request. On the other hand, if the client wants to obtain
conferencing server MUST ignore any "userInfo" parameter that is someone else's information within the given conference, she MUST
received in a "userRequest" and this "userInfo" parameter MUST NOT be include in the userRequest/retrieve a "userInfo" parameter whose
included in the userResponse. If the userResponse for the "retrieve" "entity" attribute conveys the desired user's xcon-userid. If the
operation contains a responseCode of "success", the "userInfo" userResponse for the "retrieve" operation contains a "response-code"
parameter MUST be included in the response. of "success", the "userInfo" parameter MUST be included in the
response.
In case of a userRequest with an "update" operation, the "confObjID", In case of a userRequest with an "update" operation, the "confObjID",
"confUserID" and "userInfo" MUST be included in the request. The "confUserID" and "userInfo" MUST be included in the request. The
"userInfo" is of type "user-type" and contains all the changes to be "userInfo" is of type "user-type" and contains all the changes to be
applied to a specific <user> element in the conference object applied to a specific <user> element in the conference object
identified by the "confObjId" in the userRequest message. In the identified by the "confObjID" in the userRequest message. The user
case of a user Response with a responseCode of "success", no to be modified is identified through the "entity" attribute of the
additional information is required in the "confResponse" message. A "userInfo" parameter included in the request. In the case of a
responseCode of "success" indicates that the referenced user element userResponse with a "response-code" of "success", no additional
has been updated by the conference server. A responseCode of information is required in the "userResponse" message. A "response-
code" of "success" indicates that the referenced user element has
been updated by the conference server. A "response-code" of
"changeFailedProtected" indicates that the conferencing client is not "changeFailedProtected" indicates that the conferencing client is not
allowed to make the changes reflected in the "userInfo" in the allowed to make the changes reflected in the "userInfo" in the
initial request. This could be due to policies, roles, specific initial request. This could be due to policies, roles, specific
privileges, etc., with the reason specific to a conferencing system privileges, etc., with the reason specific to a conferencing system
and its configuration. Thus, it is RECOMMENDED that the client and its configuration. Thus, it is RECOMMENDED that the client
continue using the previous version of the "userInfo". continue using the previous version of the "userInfo".
In the case of a userRequest with a "delete" operation, the In the case of a userRequest with a "delete" operation, the
"confObjId" representing the XCON-URI of the target conference and "confObjID" representing the XCON-URI of the target conference MUST
the "confUserID" associated with the specific <user> element (i.e., be included. The "confUserID", containing the CCMP client's xcon-
matching the "entity" attribute) that the conferencing client is userid, MUST also be included in the userRequest message. If the
requesting to be deleted MUST be included in the userRequest message. client wants to exit the specified conference, no "userInfo"
The userResponse MUST contain the same "confObjId" that was included parameter is needed in the delete request. On the other hand, if the
in the userRequest. The userResponse MUST contain a responseCode of client wants to remove another participant from the given conference,
"success" if the target <user> element has been successfully deleted. she MUST include in the userRequest/delete a "userInfo" parameter
If the userResponse for the "delete" operation contains a whose "entity" attribute conveys the xcon-userid of that participant.
responseCode of "success", the userResponse MUST NOT contain the The userResponse MUST contain the same "confObjID" that was included
in the userRequest. The userResponse MUST contain a "response-code"
of "success" if the target <user> element has been successfully
deleted. If the userResponse for the "delete" operation contains a
"response-code" of "success", the userResponse MUST NOT contain the
"userInfo" parameter. "userInfo" parameter.
<!-- userRequest --> <!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 35, line 9 skipping to change at page 38, line 9
<xs:element name="userInfo" type="info:user-type"/> <xs:element name="userInfo" type="info:user-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 12: Structure of the userRequest and userResponse messages Figure 12: Structure of the userRequest and userResponse messages
6.3.7. sidebarsByValRequest and sidebarsByValResponse 6.3.7. sidebarsByValRequest and sidebarsByValResponse
A "sidebarsByValRequest" is used to execute a retrieve-only operation A "sidebarsByValRequest" is used to execute a retrieve-only operation
on the <sidebars-by-val> field of the conference object represented on the <sidebars-by-val> field of the conference object represented
by the "confObjId". The "sidebarsByValRequest" message is of a by the "confObjID". The "sidebarsByValRequest" message is of a
"retrieve-only" type, so an "operation" parameter MUST NOT be "retrieve-only" type, so an "operation" parameter MUST NOT be
included in a "sidebarsByValRequest" message. A included in a "sidebarsByValRequest" message. A
"sidebarsByValResponse" with a responseCode of "success" MUST contain "sidebarsByValResponse" with a "response-code" of "success" MUST
a "sidebarsByValInfo" parameter containing the desired <sidebars-by- contain a "sidebarsByValInfo" parameter containing the desired
val> element. The "sidebarsByValInfo" parameter contains the list of <sidebars-by-val> element. The "version" parameter contained in the
the conference objects associated with the sidebars by value derived response is related to the current version of the main conference
from the main conference. The retrieved sidebars can then be updated referenced by the "confObjId" parameter of the request. The
or deleted using the "sidebarByValRequest" message, which is "sidebarsByValInfo" parameter contains the list of the conference
described in Section 6.3.8. objects associated with the sidebars by value derived from the main
conference. The retrieved sidebars can then be updated or deleted
using the "sidebarByValRequest" message, which is described in
Section 6.3.8.
<!-- sidebarsByValRequest --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValRequest"/> <xs:element ref="sidebarsByValRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
skipping to change at page 37, line 14 skipping to change at page 40, line 14
Figure 13: Structure of the sidebarsByValRequest and Figure 13: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages sidebarsByValResponse messages
6.3.8. sidebarByValRequest and sidebarByValResponse 6.3.8. sidebarByValRequest and sidebarByValResponse
A sidebarByValRequest message MUST contain the "operation" parameter A sidebarByValRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of a "create" operation, the "confObjId" parameter MUST In the case of a "create" operation, the "confObjID" parameter MUST
be included in the sidebyValRequest message. In this case, the be included in the sidebyValRequest message. In this case, the
"confObjID" parameter contains the XCON-URI of the main conference in "confObjID" parameter contains the XCON-URI of the main conference in
which the sidebar is to be created. The "sidebarByValInfo" parameter which the sidebar is to be created. The "sidebarByValInfo" parameter
SHOULD NOT be included in the request, since, as envisaged in the SHOULD NOT be included in the request, since, as envisaged in the
XCON framework ([RFC5239]), sidebars are always created by cloning XCON framework ([RFC5239]), sidebars are always created by cloning
the main conference. Any "sidebarByValInfo" included in the request the main conference. Any "sidebarByValInfo" included in the request
MUST be ignored. The conference server sets the "active" element to MUST be ignored. The conference server sets the "active" element to
"false" of the cloned conference to reflect that it is a "reserved" "false" of the cloned conference to reflect that it is a "reserved"
conference. The conference server MUST update the conference object conference. The conference server MUST update the conference object
reflected by the "confObjID" parameter, in the sidebarbyVal request reflected by the "confObjID" parameter, in the sidebarbyVal request
message, from which the sidebar was created to reflect the newly message, from which the sidebar was created to reflect the newly
created sidebar. The newly created conference object MAY be included created sidebar. The newly created conference object MAY be included
in the response in the "sidebarByValInfo" parameter, if the in the response in the "sidebarByValInfo" parameter, if the
responseCode is "success". The URI of the conference object "response-code" is "success". The URI of the conference object
associated with the newly created sidebar object MUST appear in the associated with the newly created sidebar object MUST appear in the
"confObjId" parameter of the response. The conference server can "confObjID" parameter of the response. The conference server can
notify any conferencing clients that have subscribed to the notify any conferencing clients that have subscribed to the
conference event package, and are authorized to receive the conference event package, and are authorized to receive the
notifications, of the addition of the sidebar to the conference. notifications, of the addition of the sidebar to the conference.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
(received in the response to a "create" operation or in a (received in the response to a "create" operation or in a
sidebarsByValResponse message) MUST be included in the "confObjID" sidebarsByValResponse message) MUST be included in the "confObjID"
parameter in the request. This "retrieve" operation is handled by parameter in the request. This "retrieve" operation is handled by
the conference server in the same manner as a "retrieve" operation the conference server in the same manner as a "retrieve" operation
included in a confRequest message as detailed in Section 6.3.4. included in a confRequest message as detailed in Section 6.3.4.
In the case of a "sidebarByVal" request with an operation of In the case of a "sidebarByVal" request with an operation of
"update", the "sidebarByValInfo" MUST also be included in the "update", the "sidebarByValInfo" MUST also be included in the
request. The "confObjID" parameter contained in the request message request. The "confObjID" parameter contained in the request message
identifies the specific sidebar instance to be updated. An "update" identifies the specific sidebar instance to be updated. An "update"
operation on the "sidebarByValInfo" is handled by the conference operation on the "sidebarByValInfo" is handled by the conference
server in the same manner as an "update" operation on the confInfo server in the same manner as an "update" operation on the confInfo
included in a confRequest message as detailed in Section 6.3.4. included in a confRequest message, as detailed in Section 6.3.4. The
"version" parameter contained in the response is related to the
current version of the conference object associated with the sidebar
referenced by the "confObjId" parameter of the request.
If an "operation" of "delete" is included in the sidebarByVal If an "operation" of "delete" is included in the sidebarByVal
request, the "sidebarByValInfo" parameter MUST NOT be included in the request, the "sidebarByValInfo" parameter MUST NOT be included in the
request. Any "sidebarByValInfo" included in the request MUST be request. Any "sidebarByValInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
associated with the sidebar MUST be included in the "confObjID" associated with the sidebar MUST be included in the "confObjID"
parameter in the request. If the specific conferencing user as parameter in the request. If the specific conferencing user as
reflected by the "confUserID" in the request is authorized to delete reflected by the "confUserID" in the request is authorized to delete
the conference, the conference server deletes the conference object the conference, the conference server deletes the conference object
reflected by the "confObjID" parameter and updates the data in the reflected by the "confObjID" parameter and updates the data in the
skipping to change at page 40, line 11 skipping to change at page 43, line 11
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 14: Structure of the sidebarByValRequest and Figure 14: Structure of the sidebarByValRequest and
sidebarByValResponse messages sidebarByValResponse messages
6.3.9. sidebarsByRefRequest and sidebarsByRefResponse 6.3.9. sidebarsByRefRequest and sidebarsByRefResponse
Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
invoked to retrieve the <sidebars-by-ref> element of the conference invoked to retrieve the <sidebars-by-ref> element of the conference
object identified by the "confObjId" parameter. The object identified by the "confObjID" parameter. The
"sidebarsByRefRequest" message is of a "retrieve-only" type, so an "sidebarsByRefRequest" message is of a "retrieve-only" type, so an
"operation" parameter MUST NOT be included in a "operation" parameter MUST NOT be included in a
"sidebarsByRefRequest" message. In the case of a responseCode of "sidebarsByRefRequest" message. In the case of a "response-code" of
"success", the "sidebarsByRefInfo" parameter, containing the "success", the "sidebarsByRefInfo" parameter, containing the
<sidebars-by-ref> element of the conference object, MUST be included <sidebars-by-ref> element of the conference object, MUST be included
in the response. The <sidebars-by-ref> element represents the set of in the response. The <sidebars-by-ref> element represents the set of
URIs of the sidebars associated with the main conference, whose URIs of the sidebars associated with the main conference, whose
description (in the form of a standard XCON conference document) is description (in the form of a standard XCON conference document) is
external to the main conference itself. Through the retrieved URIs, external to the main conference itself. Through the retrieved URIs,
it is then possible to access single sidebars using the it is then possible to access single sidebars using the
"sidebarByRef" request message, described in Section 6.3.10. "sidebarByRef" request message, described in Section 6.3.10. The
"version" parameter contained in the response is related to the
current version of the main conference referenced by the "confObjId"
parameter of the request.
<!-- sidebarsByRefRequest --> <!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefRequest"/> <xs:element ref="sidebarsByRefRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
skipping to change at page 42, line 14 skipping to change at page 45, line 14
Figure 15: Structure of the sidebarsByRefRequest and Figure 15: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
6.3.10. sidebarByRefRequest and sidebarByRefResponse 6.3.10. sidebarByRefRequest and sidebarByRefResponse
A sidebarByRefRequest message MUST contain the "operation" parameter A sidebarByRefRequest message MUST contain the "operation" parameter
which discriminates among retrieval, creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The other required parameters depend deletion of a specific sidebar. The other required parameters depend
upon the type of operation. upon the type of operation.
In the case of an "operation of "create", the "confObjId" parameter In the case of an "operation of "create", the "confObjID" parameter
representing the XCON-URI of the conference from which the sidebar is representing the XCON-URI of the conference from which the sidebar is
to be created (cloned) MUST be included in all sidebarByRefRequest to be created (cloned) MUST be included in all sidebarByRefRequest
messages. The "sidebarByRefInfo" parameter SHOULD NOT be included in messages. The "sidebarByRefInfo" parameter SHOULD NOT be included in
the request, since, as envisaged in the XCON framework ([RFC5239]), the request, since, as envisaged in the XCON framework ([RFC5239]),
sidebars are always created by cloning the main conference. Any sidebars are always created by cloning the main conference. Any
"sidebarByRefInfo" included in the request MUST be ignored. If the "sidebarByRefInfo" included in the request MUST be ignored. If the
creation of the sidebar is successful, the conference server MUST creation of the sidebar is successful, the conference server MUST
update the "sidebars-by-ref" element in the conference object from update the "sidebars-by-ref" element in the conference object from
which the sidebar was created (i.e., as identified by the "confObjID" which the sidebar was created (i.e., as identified by the "confObjID"
in the original sidebarByRef request), with the URI for the newly in the original sidebarByRef request), with the URI for the newly
created sidebar. The newly created conference object MAY be included created sidebar. The newly created conference object MAY be included
in the response in the "sidebarByRefInfo" parameter with a in the response in the "sidebarByRefInfo" parameter with a "response-
responseCode "success". The URI for the conference object associated code" "success". The URI for the conference object associated with
with the newly created sidebar object MUST appear in the "confObjID" the newly created sidebar object MUST appear in the "confObjID"
parameter of the response. The conference server can notify any parameter of the response. The conference server can notify any
conferencing clients that have subscribed to the conference event conferencing clients that have subscribed to the conference event
package, and are authorized to receive the notifications, of the package, and are authorized to receive the notifications, of the
addition of the sidebar to the conference. addition of the sidebar to the conference.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"retrieve", the URI for the conference object created for the sidebar "retrieve", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. A MUST be included in the "confObjID" parameter in the request. A
"retrieve" operation on the "sidebarByRefInfo" is handled by the "retrieve" operation on the "sidebarByRefInfo" is handled by the
conference server in the same manner as a "retrieve" operation on the conference server in the same manner as a "retrieve" operation on the
confInfo included in a confRequest message as detailed in confInfo included in a confRequest message as detailed in
Section 6.3.4. Section 6.3.4.
In the case of a "sidebarByRef" request with an operation of In the case of a "sidebarByRef" request with an operation of
"update", the URI for the conference object created for the sidebar "update", the URI for the conference object created for the sidebar
MUST be included in the "confObjID" parameter in the request. The MUST be included in the "confObjID" parameter in the request. The
"sidebarByRefInfo" MUST also be included in the request in the case "sidebarByRefInfo" MUST also be included in the request in the case
of an "operation" of "update". An "update" operation on the of an "operation" of "update". An "update" operation on the
"sidebarByRefInfo" is handled by the conference server in the same "sidebarByRefInfo" is handled by the conference server in the same
manner as an "update" operation on the confInfo included in a manner as an "update" operation on the confInfo included in a
confRequest message as detailed in Section 6.3.4. confRequest message as detailed in Section 6.3.4. The "version"
parameter contained in the response is related to the current version
of the conference object associated with the sidebar referenced by
the "confObjId" parameter of the request.
If an "operation" of "delete" is included in the sidebarByRef If an "operation" of "delete" is included in the sidebarByRef
request, the "sidebarByRefInfo" parameter MUST NOT be included in the request, the "sidebarByRefInfo" parameter MUST NOT be included in the
request. Any "sidebarByRefInfo" included in the request MUST be request. Any "sidebarByRefInfo" included in the request MUST be
ignored by the conference server. The URI for the conference object ignored by the conference server. The URI for the conference object
for the sidebar MUST be included in the "confObjID" parameter in the for the sidebar MUST be included in the "confObjID" parameter in the
request. If the specific conferencing user as reflected by the request. If the specific conferencing user as reflected by the
"confUserID" in the request is authorized to delete the conference, "confUserID" in the request is authorized to delete the conference,
the conference server SHOULD delete the conference object reflected the conference server SHOULD delete the conference object reflected
by the "confObjID" parameter and SHOULD update the "sidebars-by-ref" by the "confObjID" parameter and SHOULD update the "sidebars-by-ref"
skipping to change at page 45, line 9 skipping to change at page 48, line 9
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 16: Structure of the sidebarByRefRequest and Figure 16: Structure of the sidebarByRefRequest and
sidebarByRefResponse messages sidebarByRefResponse messages
6.4. CCMP Response Codes 6.4. CCMP Response Codes
All CCMP response messages MUST include a "responseCode". The All CCMP response messages MUST include a "response-code". The
following summarizes the CCMP response codes: following summarizes the CCMP response codes:
success: Successful completion of the requested operation. success: Successful completion of the requested operation.
badRequest: Syntactically malformed request. badRequest: Syntactically malformed request.
objectNotFound: Target conference object missing at the server (it objectNotFound: Target conference object missing at the server (it
refers to the "confObjId" parameter in the generic request refers to the "confObjID" parameter in the generic request
message) message)
userNotFound: Target user missing at the server (it is related to userNotFound: Target user missing at the server (it is related to
the XCON-USERID in the "entity" attribute of the "userInfo" the XCON-USERID in the "entity" attribute of the "userInfo"
parameter when it is included in userRequests) parameter when it is included in userRequests)
invalidConfUserID: User missing at the server (this code is returned invalidConfUserID: User missing at the server (this code is returned
in the case of requests in which the "confUserID" of the sender is in the case of requests in which the "confUserID" of the sender is
invalid). invalid).
skipping to change at page 46, line 11 skipping to change at page 49, line 11
requestTimeout: The time required to serve the request has exceeded requestTimeout: The time required to serve the request has exceeded
the envisaged service threshold. the envisaged service threshold.
serverInternalError: The server cannot complete the required service serverInternalError: The server cannot complete the required service
due to a system internal error. due to a system internal error.
notImplemented: Operation envisaged in the protocol, but not notImplemented: Operation envisaged in the protocol, but not
implemented in the contacted server. implemented in the contacted server.
updateFailed A generic error associated with all those situations in updateFailed: A generic error in the case that a requested "update"
which a requested "update" cannot be successfully completed by the cannot be successfully completed by the server. An example is
server. An example of such situation is when the modification of when the modification of an object cannot be applied due to
an object cannot be applied due to conflicts arising at the conflicts arising at the server's side (e.g. because the client
server's side (e.g. because the client version of the object is an version of the object is an obsolete one and the requested
obsolete one and the requested modifications collide with the up- modifications collide with the up-to-date state of the object
to-date state of the object stored at the server). stored at the server).
The handling of a "responseCode" of "objectNotFound", "userNotFound", The handling of a "response-code" of "objectNotFound",
"deleteParentFailed" and "changeFailedProtected" are only applicable "userNotFound", "deleteParentFailed" and "changeFailedProtected" are
to specific operations for specialized message responses and the only applicable to specific operations for specialized message
details are provided in Section 6.3. The following table summarizes responses and the details are provided in Section 6.3. The following
these "responseCodes" and the specialized message and operation to table summarizes these response codes and the specialized message and
which they are applicable: operation to which they are applicable:
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Response code | Create | Retrieve | Update | Delete | | Response code | Create | Retrieve | Update | Delete |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| updateFailed | N/A | N/A | All update | N/A | | updateFailed | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| objectNotFoun | userReques | All | All update | All delete | | objectNotFoun | userReques | All | All update | All delete |
skipping to change at page 47, line 29 skipping to change at page 50, line 29
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| forbiddenChan | N/A | N/A | All update | N/A | | forbiddenChan | N/A | N/A | All update | N/A |
| geProtected | | | requests | | | geProtected | | | requests | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 2: Response codes and associated operations Table 2: Response codes and associated operations
(*) "userNotFound" in answer to a "userRequest/create" operation: in (*) "userNotFound" in answer to a "userRequest/create" operation: in
the case of a third-party invite, this code can be returned if the the case of a third-party invite, this code can be returned if the
"confUserId" (contained in the "entity" attribute of the "userInfo" "confUserID" (contained in the "entity" attribute of the "userInfo"
parameter) of the user to be added is unknown. In the case above, if parameter) of the user to be added is unknown. In the case above, if
instead it is the "confUserID" of the sender of the request that is instead it is the "confUserID" of the sender of the request that is
invalid, an "invalidConfUserID" error code is returned to the client. invalid, an "invalidConfUserID" error code is returned to the client.
(**) "invalidConfUserID" is not sent in answers to "userRequest/ (**) "invalidConfUserID" is not sent in answers to "userRequest/
create" messages having a "null" confUserId, since this case is create" messages having a "null" confUserID, since this case is
associated with a user who is unaware of his own XCON-USERID, but associated with a user who is unaware of his own XCON-USERID, but
wants to enter a known conference. wants to enter a known conference.
In the case of a response code of "requestTimeout", a conferencing In the case of a response code of "requestTimeout", a conferencing
client MAY re-attempt the request within a period of time that would client MAY re-attempt the request within a period of time that would
be specific to a conference control client or conference control be specific to a conference control client or conference control
server. server.
A response code of "badRequest" indicates that the conference control A response code of "badRequest" indicates that the conference control
client sent a malformed request, which is indicative of an error in client sent a malformed request, which is indicative of an error in
skipping to change at page 48, line 10 skipping to change at page 51, line 10
The handling is specific to the conference control client The handling is specific to the conference control client
implementation (e.g., generate a log, display an error message, implementation (e.g., generate a log, display an error message,
etc.). It is NOT RECOMMENDED that the client re-attempt the request etc.). It is NOT RECOMMENDED that the client re-attempt the request
in this case. in this case.
Response codes such as "unauthorized" and "forbidden" indicate the Response codes such as "unauthorized" and "forbidden" indicate the
client does not have the appropriate permissions, or there is an client does not have the appropriate permissions, or there is an
error in the permissions: re-attempting the request would likely not error in the permissions: re-attempting the request would likely not
succeed and thus it is NOT RECOMMENDED. succeed and thus it is NOT RECOMMENDED.
Any unexpected or unknown responseCode SHOULD be treated by the Any unexpected or unknown "response-code" SHOULD be treated by the
client in the same manner as a "serverInternalError" responseCode, client in the same manner as a "serverInternalError" "response-code",
the handling of which is specific to the conference control client the handling of which is specific to the conference control client
implementation. implementation.
7. A complete example of the CCMP in action 7. A complete example of the CCMP in action
[spromano-09] This section has to be updated, since we added the
"operation" parameter in response messages. Hence, we first have to
update the schema file; then, we have to change the excrpts in this
section.
In this section a typical scenario in which the CCMP comes into play In this section a typical scenario in which the CCMP comes into play
is described, by showing the actual composition of the various CCMP is described, by showing the actual composition of the various CCMP
messages. In the call flows of the example, the Conference Control messages. In the call flows of the example, the Conference Control
Client is a CCMP-enabled client, whereas the Conference Control Client is a CCMP-enabled client, whereas the Conference Control
Server is a CCMP-enabled server. The "confUserId" of the client is Server is a CCMP-enabled server. The "confUserID" of the client,
"Alice" and appears in all requests. The sequence of operations is Alice, is "xcon-userid:Alice@example.com" and appears in all
as follows: requests. The sequence of operations is as follows:
1. Alice retrieves from the server the list of available blueprints 1. Alice retrieves from the server the list of available blueprints
(Section 7.1); (Section 7.1);
2. Alice asks for detailed information about a specific blueprint 2. Alice asks for detailed information about a specific blueprint
(Section 7.2); (Section 7.2);
3. Alice decides to create a new conference by cloning the retrieved 3. Alice decides to create a new conference by cloning the retrieved
blueprint (Section 7.3); blueprint (Section 7.3);
4. Alice modifies information (e.g. XCON-URI, name, description) 4. Alice modifies information (e.g. XCON-URI, name, description)
associated with the newly created blueprint (Section 7.4); associated with the newly created blueprint (Section 7.4);
5. Alice specifies a list of users to be contacted when the 5. Alice specifies a list of users to be contacted when the
conference is activated (Section 7.5); conference is activated (Section 7.5);
6. Alice joins the conference (Section 7.6); 6. Alice joins the conference (Section 7.6);
7. Alice lets a new user (whose "confUserId" is "Ciccio") join the 7. Alice lets a new user, Ciccio, (whose "confUserID" is
conference (Section 7.7). "xcon-userid:Ciccio@example.com") join the conference
(Section 7.7).
Note, the examples do not include any details beyond the basic Note, the examples do not include any details beyond the basic
operation. operation.
In the following sections we deal with each of the above mentioned In the following sections we deal with each of the above mentioned
actions separately. actions separately.
7.1. Alice retrieves the available blueprints 7.1. Alice retrieves the available blueprints
This section illustrates the transaction associated with retrieval of This section illustrates the transaction associated with retrieval of
skipping to change at page 50, line 14 skipping to change at page 53, line 11
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) |
| - responseCode: success | | - response-code: success |
| - blueprintsInfo: bp123,bp124,.. | | - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintsRequest message: 1. blueprintsRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
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="xcon:ccmp-blueprints-request-message-type"> xsi:type="xcon:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintsResponse message from 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>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintsResponse> <ccmp:blueprintsResponse>
<blueprintsInfo> <blueprintsInfo>
<info:entry> <info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri> <info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room: <info:purpose>Simple Room:
conference room with public access, conference room with public access,
where only audio is available, more users where only audio is available, more users
skipping to change at page 52, line 36 skipping to change at page 55, line 31
"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 |
| - responseCode: success | | - response-code: success |
| - blueprintInfo: bp123Info | | - blueprintInfo: bp123Info |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. blueprintRequest message: 1. blueprintRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
skipping to change at page 53, line 24 skipping to change at page 56, line 21
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type"> xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:blueprintRequest/> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintResponse message from the server: 2. blueprintResponse message 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-blueprint-response-message-type"> xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID> <confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation> <operation>retrieve</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com"> <blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description> <info:conference-description>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count> <info:maximum-user-count>2</info:maximum-user-count>
skipping to change at page 54, line 24 skipping to change at page 57, line 21
Figure 18: Getting info about a specific blueprint Figure 18: Getting info about a specific blueprint
7.3. Alice creates a new conference through a cloning operation 7.3. Alice creates a new conference through a cloning operation
This section illustrates the third transaction in the overall flow. This section illustrates the third transaction in the overall flow.
Alice decides to create a new conference by cloning the blueprint Alice decides to create a new conference by cloning the blueprint
having XCON-URI "xcon:AudioRoom@example.com", for which she just having XCON-URI "xcon:AudioRoom@example.com", for which she just
retrieved detailed information through the "blueprintRequest" retrieved detailed information through the "blueprintRequest"
message. This is achieved by sending a "confRequest/create" message message. This is achieved by sending a "confRequest/create" message
having the blueprint's URI in the "confObjId" parameter. The picture having the blueprint's URI in the "confObjID" parameter. The picture
shows such transaction. Notice that the response contains, in the shows such transaction. Notice that the response contains, in the
"confInfo" parameter, the document associated with the newly created "confInfo" parameter, the document associated with the newly created
conference, which is compliant with the standard XCON data model. conference, which is compliant with the standard XCON data model.
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 |
| - responseCode: success | | - response-code: success |
| - confInfo: newConfInfo | | - version: 1 |
| - 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"
skipping to change at page 55, line 45 skipping to change at page 58, line 42
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:version>1</ccmp:version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
xcon:8977794@example.com xcon:8977794@example.com
skipping to change at page 57, line 6 skipping to change at page 60, line 4
7.4. Alice updates conference information 7.4. Alice updates conference information
This section illustrates the fourth transaction in the overall flow. This section illustrates the fourth transaction in the overall flow.
Alice decides to modify some of the details associated with the Alice decides to modify some of the details associated with the
conference she just created. More precisely, she changes the conference she just created. More precisely, she changes the
<display-text> element under the <conference-description> element of <display-text> element under the <conference-description> element of
the document representing the conference. This is achieved through a the document representing the conference. This is achieved through a
"confRequest/update" message carrying the fragment of the conference "confRequest/update" message carrying the fragment of the conference
document to which the required changes have to be applied. As shown document to which the required changes have to be applied. As shown
in the picture, the response contains a code of "success", which in the picture, the response contains a code of "success", which
acknowledges the modifications requested by the client. acknowledges the modifications requested by the client, at the same
time updating the conference version number from 1 to 2, as reflected
in 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 |
| - responseCode: success | | - response-code: success |
| - confInfo: (null) | | - version: 2 |
| - 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"
skipping to change at page 58, line 4 skipping to change at page 61, line 5
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 from 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>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:version>2</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 20: Updating conference information Figure 20: Updating conference information
7.5. Alice inserts a list of users in the conference object 7.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
skipping to change at page 58, line 46 skipping to change at page 62, line 4
purpose, she exploits the "usersRequest" message provided by the purpose, she exploits the "usersRequest" message provided by the
CCMP. The picture below shows the transaction. CCMP. The picture below shows the transaction.
Alice updates information about the list of users to whom access to Alice updates information about the list of users to whom access to
the conference is permitted: the conference is permitted:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP usersRequest message | | CCMP usersRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - usersInfo: usersUpdates | | - usersInfo: usersUpdates |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP usersResponse message | | CCMP usersResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: update | | - operation: update |
| - responseCode: success | | - response-code: success |
| - usersInfo: (null) | | - version: 3 |
| - usersInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. usersRequest message: 1. usersRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
skipping to change at page 59, line 45 skipping to change at page 62, line 48
<xcon:target method="refer" <xcon:target method="refer"
uri="tel:+390817683823"/> uri="tel:+390817683823"/>
<xcon:target method="refer" <xcon:target method="refer"
uri="sip:Carol@example.com"/> uri="sip:Carol@example.com"/>
</xcon:allowed-users-list> </xcon:allowed-users-list>
</usersInfo> </usersInfo>
</ccmp:usersRequest> </ccmp:usersRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. usersResponse message from 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-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation> <operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:version>3</ccmp:version>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 21: Updating the list of allowed users for the conference Figure 21: Updating the list of allowed users for the conference
'xcon:8977794@example.com' 'xcon:8977794@example.com'
7.6. Alice joins the conference 7.6. Alice joins the conference
This section illustrates the sixth transaction in the overall flow. This section illustrates the sixth transaction in the overall flow.
Alice uses the CCMP to add herself to the newly created conference. Alice uses the CCMP to add herself to the newly created conference.
This is achieved through a "userRequest/create" message containing, This is achieved through a "userRequest/create" message containing,
in the "userInfo" parameter, a <user> element compliant with the XCON in the "userInfo" parameter, a <user> element compliant with the XCON
data model representation. Notice that such element includes data model representation. Notice that such element includes
information about the user's Address of Records, as well as her information about the user's Address of Records, as well as her
current end-point. The picture below shows the transaction. Notice current end-point. The picture below shows the transaction. Notice
how the "confUserId" parameter is equal to the "entity" attribute of how the "confUserID" parameter is equal to the "entity" attribute of
the <userInfo> element, which indicates that the request issued by the <userInfo> element, which indicates that the request issued by
the client is a first-party one. the client is a first-party one.
Alice joins the conference by issuing a "userRequest/create" message Alice joins the conference by issuing a "userRequest/create" message
with her own id to the server: with her own id to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: AliceUserInfo | | - userInfo: AliceUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - responseCode: success | | - response-code: success |
| - userInfo: (null) | | - version: 4 |
| - userInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. userRequest message: 1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
skipping to change at page 61, line 38 skipping to change at page 64, line 43
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. userResponse message 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:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:version>4</ccmp:version>
<ccmp:userResponse/> <ccmp:userResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Alice joins the conference through the CCMP Figure 22: Alice joins the conference through the CCMP
7.7. Alice adds a new user to the conference 7.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new user to the overall flow. Alice uses the CCMP to add a new user to the
conference. This is achieved through a "userRequest/create" message conference. This is achieved through a "userRequest/create" message
containing, in the "userInfo" parameter, a <user> element compliant containing, in the "userInfo" parameter, a <user> element compliant
with the XCON data model representation. Notice that such element with the XCON data model representation. Notice that such element
includes information about the user's Address of Records, as well as includes information about the user's Address of Records, as well as
his current end-point. The picture below shows the transaction. his current end-point. The picture below shows the transaction.
Notice how the "confUserId" parameter in the request is Alice's id, Notice how the "confUserID" parameter in the request is Alice's id,
whereas the <userInfo> element has no "entity" attribute and contains whereas the <userInfo> element has no "entity" attribute and contains
information about a different user, thus indicating that the request information about a different user, thus indicating that the request
issued by the client is a third-party one. This is also reflected in issued by the client is a third-party one. This is also reflected in
the response coming from the server, which this time contains a the response coming from the server, which this time contains a
"confUserID" parameter representing the conference user id of the "confUserID" parameter representing the conference user id of the
user just added to the conference with Alice's third-party request. user just added to the conference with Alice's third-party request.
This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new user, Ciccio, to the
conference. This "third-party" request is realized through a
"userRequest/create" message containing, in the "userInfo" parameter,
a <user> element compliant with the XCON data model representation.
Notice that such element includes information about Ciccio's Address
of Records, as well as his current end-point, but has no "entity"
attribute, since such information is unknown to Alice, in this
example. Thus, the server is in charge of: (i) generating a new
xcon-userid for the user indicated by Alice; (ii) returning it in the
"entity" attribute of the "userInfo" parameter carried in the
response; (iii) adding the user to the conference. The picture below
shows the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server: "userRequest/create" message to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - userInfo: CiccioUserInfo | | - userInfo: CiccioUserInfo(without "entity") |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: ciccio | | - confUserID: Ciccio |
| - confObjId: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
| - responseCode: success | | - response-code: success |
| - userInfo: (null) | | - version: 5 |
| - userInfo: CiccioUserInfo |
| (with "entity") |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. "third party" userRequest message from Alice: 1. "third party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
skipping to change at page 63, line 24 skipping to change at page 66, line 44
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo> <userInfo>
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:ciccio@pernacchio.com mailto:Ciccio@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:ciccio@pernacchio.com"/> <info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo> </userInfo>
</ccmp:userRequest> </ccmp:userRequest>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. "third party" userResponse message form the server: 2. "third party" userResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
skipping to change at page 63, line 44 skipping to change at page 67, line 16
2. "third party" userResponse message form the server: 2. "third party" userResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type"> xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:ciccio@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:userResponse/> <ccmp:version>5</ccmp:version>
<ccmp:userResponse>
<userInfo entity="xcon-userid:Ciccio@example.com"/>
</ccmp:userResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 23: Alice adds a new user to the conference through the CCMP Figure 23: Alice adds a new user to the conference through the CCMP
8. Locating a Conference Control Server 8. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. The result of the discovery process, is the address of the requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server. http: or https: URI, which identifies a conference server.
skipping to change at page 68, line 23 skipping to change at page 71, line 23
conferencing server may not a fully compliant HTTP server. It is conferencing server may not a fully compliant HTTP server. It is
intended that a conference server can easily be built using an HTTP intended that a conference server can easily be built using an HTTP
server with extensibility mechanisms, and that a conferencing client server with extensibility mechanisms, and that a conferencing client
can trivially use existing HTTP libraries. This subset of can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options requirements helps implementors avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
A conferencing client that conforms to this specification is not A conferencing client that conforms to this specification is not
required to support HTTP authentication [RFC2617] or cookies required to support HTTP authentication [RFC2617] or cookies
[RFC2965]. These mechanism are unnecessary because CCMP requests [RFC2965]. These mechanism are unnecessary because CCMP requests
carry their own authentication information (in the "confUserId" and carry their own authentication information (in the "confUserID" and
"password" fields; see Section 7.2.1). "password" fields; see Section 6.1).
A CCMP request is carried in the body of an HTTP POST request. The A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request. conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/ The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields. provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content- If the conference server does not receive the appropriate Content-
Type and Accept header fields, the conference server SHOULD fail the Type and Accept header fields, the conference server SHOULD fail the
request, returning a 406 (not acceptable) response. CCMP responses request, returning a 406 (not acceptable) response. CCMP responses
skipping to change at page 73, line 12 skipping to change at page 76, line 12
"provide-anonymity" element is not included in the conference object, "provide-anonymity" element is not included in the conference object,
then other users can see the participant's identity. then other users can see the participant's identity.
12. XML Schema 12. XML Schema
This section provides the XML schema definition of the "application/ This section provides the XML schema definition of the "application/
ccmp+xml" format. ccmp+xml" format.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp" targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import <xs:import
namespace="urn:ietf:params:xml:ns:xcon-conference-info" namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/> schemaLocation="DataModel.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info" <xs:import
namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/> schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP request definition --> <!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type"> <xs:complexType name="ccmp-request-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpRequest" <xs:element name="ccmpRequest"
type="ccmp-request-message-type" /> type="ccmp-request-message-type" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- CCMP response definition --> <!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type"> <xs:complexType name="ccmp-response-type">
<xs:sequence> <xs:sequence>
<xs:element name="ccmpResponse" <xs:element name="ccmpResponse"
type="ccmp-response-message-type" /> type="ccmp-response-message-type" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- Definition of ccmp-request-message-type --> <!-- Definition of ccmp-request-message-type -->
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation"
type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<!-- blueprintsRequest --> <xs:complexType abstract="true"
<xs:complexType name="ccmp-blueprints-request-message-type"> name="ccmp-request-message-type">
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:element name="confUserID" type="xs:string"
</xs:complexContent> minOccurs="0" maxOccurs="1" />
</xs:complexType> <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<!-- blueprintRequest --> </xs:sequence>
<xs:complexType name="ccmp-blueprint-request-message-type"> </xs:complexType>
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest"
type="blueprintsRequestType" />
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- blueprintRequestType -->
<xs:element name="blueprintRequest" <xs:element name="blueprintRequest"
type="blueprintRequestType" /> type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type" type="info:conference-type" minOccurs="0"/>
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confsRequest --> <!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confRequest --> <!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type"> <xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confRequest" /> <xs:element ref="confRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confRequestType --> <!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" /> <xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType"> <xs:complexType name="confRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" <xs:element name="confInfo"
type="info:conference-type" type="info:conference-type"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- usersRequest --> <!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type"> <xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersRequest" /> <xs:element ref="usersRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType --> <!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo"
type="info:users-type"
minOccurs="0" />
</xs:sequence> <xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo"
type="info:users-type"
minOccurs="0" />
</xs:sequence>
</xs:complexType> </xs:complexType>
<!-- userRequest --> <!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userRequestType --> <!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" /> <xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:complexType name="userRequestType"> <xs:sequence>
<xs:sequence> <xs:element name="userInfo"
<xs:element name="userInfo" type="info:user-type" minOccurs="0" />
type="info:user-type" </xs:sequence>
minOccurs="0" /> </xs:complexType>
</xs:sequence>
</xs:complexType>
<!-- sidebarsByValRequest --> <!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type"> <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequest --> <!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type"> <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequest --> <!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type"> <xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValRequest" /> <xs:element ref="sidebarByValRequest" />
</xs:sequence>
</xs:sequence> </xs:extension>
</xs:extension> </xs:complexContent>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValRequestType --> <!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest" <xs:element name="sidebarByValRequest"
type="sidebarByValRequestType" /> type="sidebarByValRequestType" />
<xs:complexType name="sidebarByValRequestType"> <xs:complexType name="sidebarByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type" type="info:conference-type" minOccurs="0"/>
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefRequest --> <!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type"> <xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefRequest" /> <xs:element ref="sidebarByRefRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefRequestType --> <!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest" <xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" /> type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType"> <xs:complexType name="sidebarByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" type="info:conference-type" minOccurs="0"/>
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- Definition of ccmp-response-message-type --> <!-- Definition of ccmp-response-message-type -->
<xs:complexType abstract="true" <xs:complexType abstract="true"
name="ccmp-response-message-type"> name="ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element name="confUserID" type="xs:string" <xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" <xs:element name="operation" minOccurs="0"
minOccurs="0" maxOccurs="1" />
maxOccurs="1" /> <xs:element ref="response-code" minOccurs="1"
<xs:element ref="response-code" minOccurs="1" maxOccurs="1" />
maxOccurs="1" /> <xs:element name="response-string" type="xs:string"
<xs:element name="response-string" minOccurs="0" maxOccurs="1" />
type="xs:string" <xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="version" </xs:sequence>
type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponse --> <!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type"> <xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintsResponse" /> <xs:element ref="blueprintsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintsResponseType --> <!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" <xs:element name="blueprintsResponse"
type="blueprintsResponseType" /> type="blueprintsResponseType" />
<xs:complexType name="blueprintsResponseType"> <xs:complexType name="blueprintsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintsInfo" <xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- blueprintResponse --> <!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type"> <xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintResponse" /> <xs:element ref="blueprintResponse" />
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:extension> </xs:complexContent>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintResponseType --> <!-- blueprintResponseType -->
<xs:element name="blueprintResponse" <xs:element name="blueprintResponse"
type="blueprintResponseType" /> type="blueprintResponseType" />
<xs:complexType name="blueprintResponseType"> <xs:complexType name="blueprintResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confsResponse --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confsResponse" /> <xs:element ref="confsResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsResponseType --> <!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType" /> <xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsResponseType"> <xs:complexType name="confsResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confsInfo" <xs:element name="confsInfo"
type="info:uris-type" type="info:uris-type" minOccurs="0"/>
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- confResponse --> <!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type"> <xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="confResponse" /> <xs:element ref="confResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confResponseType --> <!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType"> <xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type"/> <xs:element name="confInfo" type="info:conference-type"/>
</xs:sequence> </xs:sequence>
skipping to change at page 80, line 17 skipping to change at page 83, line 45
<!-- confResponseType --> <!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" /> <xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType"> <xs:complexType name="confResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confInfo" type="info:conference-type"/> <xs:element name="confInfo" type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- usersResponse --> <!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type"> <xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersResponse" /> <xs:element ref="usersResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersResponseType --> <!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
skipping to change at page 80, line 38 skipping to change at page 84, line 19
<!-- usersResponseType --> <!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" /> <xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType"> <xs:complexType name="usersResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="usersInfo" type="info:users-type"/> <xs:element name="usersInfo" type="info:users-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- userResponse --> <!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type"> <xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userResponse" /> <xs:element ref="userResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- userResponseType --> <!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" /> <xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType"> <xs:complexType name="userResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="userInfo" type="info:user-type"/> <xs:element name="userInfo" type="info:user-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponse --> <!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type"> <xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByValResponse" /> <xs:element ref="sidebarsByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValResponseType --> <!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse" <xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" /> type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type"/> type="info:sidebars-by-val-type"/>
</xs:sequence> </xs:sequence>
skipping to change at page 81, line 37 skipping to change at page 85, line 19
<xs:complexType name="sidebarsByValResponseType"> <xs:complexType name="sidebarsByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByValInfo" <xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type"/> type="info:sidebars-by-val-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefResponse --> <!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByref-response-message-type"> <xs:complexType name="ccmp-sidebarsByref-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarsByRefResponse" /> <xs:element ref="sidebarsByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefResponseType --> <!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse" <xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" /> type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType"> <xs:complexType name="sidebarsByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo"
type="info:uris-type"/> type="info:uris-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponse --> <!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type"> <xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByValResponse" /> <xs:element ref="sidebarByValResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByValResponseType --> <!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse" <xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" /> type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
skipping to change at page 82, line 37 skipping to change at page 86, line 19
<xs:complexType name="sidebarByValResponseType"> <xs:complexType name="sidebarByValResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponse --> <!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByref-response-message-type"> <xs:complexType name="ccmp-sidebarByref-response-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type"> <xs:extension base="tns:ccmp-response-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="sidebarByRefResponse" /> <xs:element ref="sidebarByRefResponse" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarByRefResponseType --> <!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse" <xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" /> type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType"> <xs:complexType name="sidebarByRefResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
skipping to change at page 89, line 9 skipping to change at page 93, line 9
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
This section pre-registers the following thirteen initial response This section pre-registers the following thirteen initial response
codes as described above in Section 5.1: codes as described above in Section 5.1:
success: This code indicates that the request was successfully success: This code indicates that the request was successfully
processed. processed.
updateFailed: This code indicates that a requested "update" cannot updateFailed: This code indicates that a requested "update" cannot
be successfully completed by the server. An example of such be successfully completed by the server. An example is when the
situation is when the modification of an object cannot be applied modification of an object cannot be applied due to conflicts
due to conflicts arising at the server's side (e.g. because the arising at the server's side (e.g. because the client version of
client version of the object is an obsolete one and the requested the object is an obsolete one and the requested modifications
modifications collide with the up-to-date state of the object collide with the up-to-date state of the object stored at the
stored at the server). server).
badRequest: This code indicates that the request was badly formed in badRequest: This code indicates that the request was badly formed in
some fashion. some fashion.
unauthorized: This code indicates that the user was not authorized unauthorized: This code indicates that the user was not authorized
for the specific operation on the conference object. for the specific operation on the conference object.
forbidden: This code indicates that the specific operation is not forbidden: This code indicates that the specific operation is not
valid for the target conference object. valid for the target conference object.
objectNotFound: This code indicates that the specific conference objectNotFound: This code indicates that the specific conference
object was not found. object was not found.
userNotFound: This code is returned in answer to a "userRequest/ userNotFound: This code is returned in answer to a "userRequest/
create" operation, in the case of a third-party invite, when the create" operation, in the case of a third-party invite, when the
"confUserId" (contained in the "entity" attribute of the "confUserID" (contained in the "entity" attribute of the
"userInfo" parameter) of the user to be added is unknown. "userInfo" parameter) of the user to be added is unknown.
invalidConfUserID: This code is returned in the case of requests in invalidConfUserID: This code is returned in the case of requests in
which the "confUserID" of the sender is invalid. which the "confUserID" of the sender is invalid.
invalidPassword: This code is returned in response to all requests invalidPassword: This code is returned in response to all requests
wishing to access/manipulate a password-protected conference wishing to access/manipulate a password-protected conference
object, when the "password" parameter contained in the request is object, when the "password" parameter contained in the request is
wrong. wrong.
skipping to change at page 91, line 9 skipping to change at page 95, line 9
serverInternalError: This code indicates that the conferencing serverInternalError: This code indicates that the conferencing
system experienced some sort of internal error. system experienced some sort of internal error.
notImplemented: This code indicates that the specific operation is notImplemented: This code indicates that the specific operation is
not implemented on that conferencing system. not implemented on that conferencing system.
14. Acknowledgments 14. Acknowledgments
The authors appreciate the feedback provided by Dave Morgan, Pierre The authors appreciate the feedback provided by Dave Morgan, Pierre
Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean
Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen and Yu Guo.
thanks go to Roberta Presta for her invaluable contribution to this Special thanks go to Roberta Presta for her invaluable contribution
document. Roberta has worked on the specification of the CCMP to this document. Roberta has worked on the specification of the
protocol at the University of Napoli for the preparation of her CCMP protocol at the University of Napoli for the preparation of her
Master thesis. She has also implemented the CCMP prototype used for Master thesis. She has also implemented the CCMP prototype used for
the trials and from which the dumps provided in Section 7 have been the trials and from which the dumps provided in Section 7 have been
extracted. extracted.
15. Changes since last Version 15. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
The following summarizes the changes between the WG 04 and the 05:
1. Added versioning.
2. Added string to response codes.
3. Removed "modified" response code.
4. Added filtering for conference info in responses.
5. Editorial clarifications and nits.
The following summarizes the changes between the WG 03 and the 04: The following summarizes the changes between the WG 03 and the 04:
1. Re-organized document based on feedback from Richard Barnes. 1. Re-organized document based on feedback from Richard Barnes.
2. Editorial clarifications and nits, including those identified by 2. Editorial clarifications and nits, including those identified by
Richard and Simo Veikkolainen. Richard and Simo Veikkolainen.
The following summarizes the changes between the WG 02 and the 03: The following summarizes the changes between the WG 02 and the 03:
1. Clarified that the confUserID is optional in the generic CCMP 1. Clarified that the confUserID is optional in the generic CCMP
request message for a userRequest with a "create" operation. request message for a userRequest with a "create" operation.
2. Added responseCode (error cases) handling - a general section for 2. Added response-code (error cases) handling - a general section
each of the operations (as part of CCMP Response Code section), for each of the operations (as part of CCMP Response Code
so we don't need to re-iterate for each of the messages and section), so we don't need to re-iterate for each of the messages
message specific cases as appropriate (e.g., deleteParentFailed, and message specific cases as appropriate (e.g.,
modified) deleteParentFailed, modified)
3. Moved "operation" parameter to be part of general CCMP request 3. Moved "operation" parameter to be part of general CCMP request
and response messages since it is used for more than one message and response messages since it is used for more than one message
type. And, it's necessary to define before describing the type. And, it's necessary to define before describing the
operation specific responseCode handling. operation specific response-code handling.
4. Revised normative statements for the various protocol messages 4. Revised normative statements for the various protocol messages
and operations - e.g., messages MUST include parameter x versus and operations - e.g., messages MUST include parameter x versus
SHOULD, adding text for handling of cases where the SHOULDs don't SHOULD, adding text for handling of cases where the SHOULDs don't
happen and the SHOULD NOTs do. Added descriptions for all the happen and the SHOULD NOTs do. Added descriptions for all the
operation types, as appropriate. operation types, as appropriate.
5. Added lots more details in the security section. 5. Added lots more details in the security section.
6. Added section to describe requirements for an HTTP implementation 6. Added section to describe requirements for an HTTP implementation
skipping to change at page 95, line 9 skipping to change at page 99, line 9
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.ietf-xcon-examples]
Barnes, M., Boulton, C., Miniero, L., Presta, R., and S.
Romano, "Centralized Conferencing Manipulation Protocol
(CCMP) Call Flow Examples", draft-ietf-xcon-examples-01
(work in progress), July 2009.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Nielsen, H., Gudgin, M., Moreau, J., Mendelsohn, N., and Hadley, M., Gudgin, M., Nielsen, H., Moreau, J., and N.
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", Mendelsohn, "SOAP Version 1.2 Part 1: Messaging
World Wide Web Consortium FirstEdition REC-soap12-part1- Framework", World Wide Web Consortium FirstEdition REC-
20030624, June 2003, soap12-part1-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Mendelsohn, N., Nielsen, H., Moreau, J., Hadley, M., and
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
[W3C.REC-xpath-19991116]
DeRose, S. and J. Clark, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
In both approaches, servers will have to recreate their internal In both approaches, servers will have to recreate their internal
state representation of the object with each update request, checking state representation of the object with each update request, checking
 End of changes. 195 change blocks. 
568 lines changed or deleted 692 lines changed or added

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