draft-ietf-xcon-ccmp-02.txt   draft-ietf-xcon-ccmp-03.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: September 11, 2009 NS-Technologies Expires: January 14, 2010 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
March 10, 2009 July 13, 2009
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-02 draft-ietf-xcon-ccmp-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 11, 2009. This Internet-Draft will expire on January 14, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. CCMP is a state-less centralized conferencing data model schema. CCMP is a state-less
client-server protocol based on a request/response model. client-server protocol based on a request/response model.
Conferencing clients send requests to conference servers, which Conferencing clients send requests to conference servers, which
respond to the client with the conference information. respond to the client with the conference information.
This document also discusses options for using existing notification
protocols to inform conference client about the changes in the state
of a conference during its entire lifetime.
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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. System Architecture . . . . . . . . . . . . . . . . . . . . . 8 5. System Architecture . . . . . . . . . . . . . . . . . . . . . 9
6. Conference Object and User Identifiers . . . . . . . . . . . . 10 6. Conference Object and User Identifiers . . . . . . . . . . . . 11
6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 10 6.1. Conference Object . . . . . . . . . . . . . . . . . . . . 11
6.2. Conference Users and Participants . . . . . . . . . . . . 10 6.2. Conference Users and Participants . . . . . . . . . . . . 11
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 12 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Implementation Approach . . . . . . . . . . . . . . . . . 13 7.1. Implementation Approach . . . . . . . . . . . . . . . . . 14
7.2. CCMP protocol messages . . . . . . . . . . . . . . . . . . 13 7.2. CCMP protocol messages . . . . . . . . . . . . . . . . . . 14
7.2.1. CCMP Request Message . . . . . . . . . . . . . . . . . 13 7.2.1. CCMP Request Message . . . . . . . . . . . . . . . . . 14
7.2.2. CCMP Response Message . . . . . . . . . . . . . . . . 14 7.2.2. CCMP Response Message . . . . . . . . . . . . . . . . 16
7.2.2.1. CCMP Response Codes . . . . . . . . . . . . . . . 15 7.2.2.1. CCMP Response Codes . . . . . . . . . . . . . . . 18
7.2.3. Detailed CCMP Messages . . . . . . . . . . . . . . . . 16 7.2.3. Detailed CCMP Messages . . . . . . . . . . . . . . . . 21
7.2.3.1. blueprintsRequest and blueprintsResponse 7.2.3.1. blueprintsRequest and blueprintsResponse
messages . . . . . . . . . . . . . . . . . . . . . 20 messages . . . . . . . . . . . . . . . . . . . . . 23
7.2.3.2. confsRequest and confsResponse messages . . . . . 21 7.2.3.2. confsRequest and confsResponse messages . . . . . 25
7.2.3.3. blueprintRequest and blueprintResponse messages . 22 7.2.3.3. blueprintRequest and blueprintResponse messages . 26
7.2.3.4. confRequest and confResponse messages . . . . . . 25 7.2.3.4. confRequest and confResponse messages . . . . . . 28
7.2.3.5. usersRequest and usersResponse messages . . . . . 28 7.2.3.5. usersRequest and usersResponse messages . . . . . 31
7.2.3.6. userRequest and userResponse messages . . . . . . 31 7.2.3.6. userRequest and userResponse messages . . . . . . 34
7.2.3.7. sidebarsByValRequest and sidebarsByValResponse 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse
messages . . . . . . . . . . . . . . . . . . . . . 33 messages . . . . . . . . . . . . . . . . . . . . . 39
7.2.3.8. sidebarByValRequest and sidebarByValResponse 7.2.3.8. sidebarByValRequest and sidebarByValResponse
messages . . . . . . . . . . . . . . . . . . . . . 34 messages . . . . . . . . . . . . . . . . . . . . . 41
7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse
messages . . . . . . . . . . . . . . . . . . . . . 36 messages . . . . . . . . . . . . . . . . . . . . . 44
7.2.3.10. sidebarByRefRequest and sidebarByRefResponse 7.2.3.10. sidebarByRefRequest and sidebarByRefResponse
messages . . . . . . . . . . . . . . . . . . . . . 37 messages . . . . . . . . . . . . . . . . . . . . . 46
8. A complete example of the CCMP in action . . . . . . . . . . . 40 8. A complete example of the CCMP in action . . . . . . . . . . . 50
8.1. Alice retrieves the available blueprints . . . . . . . . . 40 8.1. Alice retrieves the available blueprints . . . . . . . . . 50
8.2. Alice gets detailed information about a specific 8.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 43 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 53
8.3. Alice creates a new conference through a cloning 8.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 45 operation . . . . . . . . . . . . . . . . . . . . . . . . 55
8.4. Alice updates conference information . . . . . . . . . . . 47 8.4. Alice updates conference information . . . . . . . . . . . 57
8.5. Alice inserts a list of users in the conference object . . 49 8.5. Alice inserts a list of users in the conference object . . 59
8.6. Alice joins the conference . . . . . . . . . . . . . . . . 51 8.6. Alice joins the conference . . . . . . . . . . . . . . . . 61
8.7. Alice adds a new user to the conference . . . . . . . . . 52 8.7. Alice adds a new user to the conference . . . . . . . . . 63
9. Locating a Conference Control Server . . . . . . . . . . . . . 55 9. Locating a Conference Control Server . . . . . . . . . . . . . 66
10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 57 10. Managing Notifications . . . . . . . . . . . . . . . . . . . . 68
11. Managing notifications . . . . . . . . . . . . . . . . . . . . 69 11. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 69
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 71
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 70 12.1. Assuring that the Proper Conferencing Server has been
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 70 contacted . . . . . . . . . . . . . . . . . . . . . . . . 72
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 71 12.2. User Authentication and Authorization . . . . . . . . . . 72
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 72 12.3. Security and Privacy of Identity . . . . . . . . . . . . . 73
12.4.1. Registration of a Location Server Application 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Service Tag . . . . . . . . . . . . . . . . . . . . . 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
12.4.2. Registration of a Location Server Application 14.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 85
Protocol Tag for HELD . . . . . . . . . . . . . . . . 72 14.2. XML Schema Registration . . . . . . . . . . . . . . . . . 85
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 73 14.3. MIME Media Type Registration for 'application/ccmp+xml' . 86
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 73 14.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 87
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 74 14.4.1. Registration of a Location Server Application
13. Security Considerations . . . . . . . . . . . . . . . . . . . 76 Service Tag . . . . . . . . . . . . . . . . . . . . . 87
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 14.4.2. Registration of a Location Server Application
15. Changes since last Version . . . . . . . . . . . . . . . . . . 78 Protocol Tag for HELD . . . . . . . . . . . . . . . . 87
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 14.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . . 88
16.1. Normative References . . . . . . . . . . . . . . . . . . . 79 14.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . . 88
16.2. Informative References . . . . . . . . . . . . . . . . . . 79 14.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 89
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92
16. Changes since last Version . . . . . . . . . . . . . . . . . . 93
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95
17.1. Normative References . . . . . . . . . . . . . . . . . . . 95
17.2. Informative References . . . . . . . . . . . . . . . . . . 95
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . . 81 considered for CCMP . . . . . . . . . . . . . . . . . 97
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 81 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 97
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 82 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99
1. Introduction 1. Introduction
The Framework for Centralized Conferencing [RFC5239] (XCON Framework) The Framework for Centralized Conferencing [RFC5239] (XCON Framework)
defines a signaling-agnostic framework, naming conventions and defines a signaling-agnostic framework, naming conventions and
logical entities required for building advanced conferencing systems. logical entities required for building advanced conferencing systems.
The XCON Framework introduces the conference object as a logical The XCON Framework introduces the conference object as a logical
representation of a conference instance, representing the current representation of a conference instance, representing the current
state and capabilities of a conference. state and capabilities of a conference.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
use of REST for the CCMP, as well as other protocols considered use of REST for the CCMP, as well as other protocols considered
(e.g., SOAP) are provided in Appendix A. (e.g., SOAP) are provided in Appendix A.
Section 4 provides an overview of the design of the CCMP, followed by Section 4 provides an overview of the design of the CCMP, followed by
the system architecture in Section 5. Section 6 discusses the the system architecture in Section 5. Section 6 discusses the
primary keys in the conference object carried in the protocol. An primary keys in the conference object carried in the protocol. An
overview of the operations associated with each protocol request and overview of the operations associated with each protocol request and
response is provided in Section 7. A complete example of the response is provided in Section 7. A complete example of the
operation of the CCMP, describing a typical call flow associated with operation of the CCMP, describing a typical call flow associated with
conference creation and manipulation, is provided in Section 8. conference creation and manipulation, is provided in Section 8.
Section 10 provides the XML schema. Section 13 provides the XML schema.
2. Conventions 2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as document are to be interpreted as described in [RFC2119].
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
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:
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.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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. Protocol Overview 4. Protocol Overview
This document specifies the basic operations that can create, This document specifies the basic operations that can create,
retrieve, modify and delete conference-related information in a retrieve, modify and delete conference-related information in a
centralized conference. The core set of objects includes conference centralized conference. The core set of objects manipulated in the
blueprints, the conference itself, users, and sidebars. CCMP protocol described in this document includes conference
blueprints, the conference object, users, and sidebars.
Each update operation in the protocol model is atomic and either
succeeds or fails as a whole. Thus, a server has to first check all
parameters, before making any changes to the internal representation
of the conference object. For example, it would be undesirable to
change the <subject> of the conference, but then detect an invalid
URI in one of the <service-uris> and abort the remaining updates.
Because multiple clients can modify the same conference objects,
clients need to obtain the current object and then update the whole
object.
Editor's Note: Do we need locking, using WebDAV or floor control? Each operation in the protocol model is atomic and either succeeds or
Otherwise, changes made by user A could get lost when user B wants to fails as a whole. The conference server MUST ensure that the
modify some other parameter. For example, A changes the subject, B operations are atomic in that the operation invoked by a specific
adds the a service URI. conference client completes prior to another client's operation on
the same conference object. The details for this data locking
functionality are out of scope for the CCMP protocol specification
and are implementation specific for a conference server. Thus, the
conference server first checks all the parameters, before making any
changes to the internal representation of the conference object. For
example, it would be undesirable to change the <subject> of the
conference, but then detect an invalid URI in one of the <service-
uris> and abort the remaining updates. Also, since multiple clients
can modify the same conference objects, conference clients SHOULD
first obtain the current object from the conference server and then
update the relevant data elements in the conference object prior to
invoking a specific operation on the conference server. In some
cases, the data changes are not fully applied, since a previous
operation by another conference client may have altered some of the
data. Where appropriate (i.e., depending upon the specific data and
policies), the conference server SHOULD indicate that the data has
been modified and return the current conference object to the client.
For example, one conferencing client may add a new user to the
conference object. Thus, a subsequent request by another
conferencing client should provide a conference object containing
this new user.
It is likely that implementations and future standardization work It is likely that implementations and future standardization work
will add more conference attributes and parameters. There are three will add more conference attributes and parameters. There are three
types of extensions. The first and simplest type of extension adds types of extensions. The first and simplest type of extension adds
elements to the overall conference description, media descriptions or elements to the overall conference description, media descriptions or
descriptions of users. The XML namespace mechanism makes such descriptions of users. The XML namespace mechanism makes such
extensions relatively easy, although implementations still have to extensions relatively easy, although implementations still have to
deal with implementations that may not understand the new namespaces. deal with companion implementations that may not understand the new
The CCMP "blueprintsRequest" message allows clients to determine the namespaces. The CCMP "blueprintsRequest" message allows clients to
capabilities of a specific server, reflected by the specific determine the capabilities of a specific server, reflected by the
blueprints supported by that server. specific blueprints supported by that server.
A second type of extension replaces the conference, user or media A second type of extension replaces the conference, user or media
objects with completely new schema definitions, i.e., the namespaces objects with completely new schema definitions, i.e., the namespaces
for these objects themselves differ from the basic one defined in for these objects themselves differ from the basic one defined in
this document. As long as the OPTIONS request remains available and this document. As long as the blueprintsRequest message remains
keeps to a mutually-understood definition, a compatible client and available and keeps to a mutually-understood definition, a compatible
server will be able to bootstrap themselves into using these new client and server will be able to bootstrap themselves into using
objects. these new objects.
Finally, it is conceivable that new object types are needed beyond Finally, it is conceivable that new object types are needed beyond
the core conference, user and media objects and their children. the core conference, user and media objects and their children.
These would also be introduced by namespaces and new URIs. These would also be introduced by namespaces and new URIs.
5. System Architecture 5. 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
skipping to change at page 11, line 19 skipping to change at page 12, line 19
conference control server uses the XCON-USERID to change or delete conference control server uses the XCON-USERID to change or delete
<user> elements. Depending upon policies and privileges, specific <user> elements. Depending upon policies and privileges, specific
users MAY also manipulate <user> elements. users MAY also manipulate <user> elements.
In many conferences, users can dial in if they know the XCON-URI and In many conferences, users can dial in if they know the XCON-URI and
an access code shared by all conference participants. In this case, an access code shared by all conference participants. In this case,
the system is typically not aware of the call signaling URL. Thus, the system is typically not aware of the call signaling URL. Thus,
the initial <user> element does not have an entity attribute and the the initial <user> element does not have an entity attribute and the
default type of <dial-in> is used to support this type of user. For default type of <dial-in> is used to support this type of user. For
this case, the server assigns a locally-unique URI, such as a this case, the server assigns a locally-unique URI, such as a
locally-scoped tel URI. The conference control server assigns a locally-scoped tel URI [RFC3966]. The conference control server
unique Conference User Identifier (XCON-USERID) to these users when assigns a unique Conference User Identifier (XCON-USERID) to these
they dial-in to join the conference. If the user supports the users when they dial-in to join the conference. If the user supports
notification event package [I-D.ietf-xcon-event-package], they can the notification event package [I-D.ietf-xcon-event-package], they
receive their XCON-USERID, thus allowing them to also manipulate the can receive their XCON-USERID, thus allowing them to also manipulate
<user> attribute, including the entity attribute, in the conference the <user> attribute, including the entity attribute, in the
object. conference object.
7. Protocol Operations 7. Protocol Operations
CCMP is a client-server, XML-based, stateless protocol, which has CCMP is a client-server, XML-based, stateless protocol, which has
been specifically conceived to provide users with the necessary means been specifically conceived to provide users with the necessary means
for the creation, retrieval, modification and deletion of conference for the creation, retrieval, modification and deletion of conference
objects. Conference-related information is encapsulated into CCMP objects. Conference-related information is encapsulated into CCMP
messages in the form of documents or document fragments compliant messages in the form of documents or document fragments compliant
with the XCON data model representation. with the XCON data model representation.
skipping to change at page 13, line 10 skipping to change at page 14, line 10
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.
7.1. Implementation Approach 7.1. 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
proposed solution for the CCMP is viewed as a good compromise amongst solution for the CCMP defined in this document is viewed as a good
the most notable past candidates and is referred to as 'HTTP single compromise amongst the most notable past candidates and is referred
verb transport plus CCMP body'. With this approach, CCMP is able to to as 'HTTP transport plus CCMP body'. With this approach, CCMP is
take advantage of existing HTTP functionality. As with SOAP, the able to take advantage of existing HTTP functionality. As with SOAP,
CCMP uses a 'single HTTP verb' for transport (i.e. a single the CCMP uses a 'single HTTP verb' for transport (i.e. a single
transaction type for each request/response pair); this allows transaction type for each request/response pair); this allows
decoupling CCMP messages from HTTP messages. Similarly, as with any decoupling CCMP messages from HTTP messages. Similarly, as with any
RESTful approach, CCMP messages are inserted directly in the body of RESTful approach, CCMP messages are inserted directly in the body of
HTTP messages, thus avoiding any unnecessary processing and HTTP messages, thus avoiding any unnecessary processing and
communication burden associated with further intermediaries. With communication burden associated with further intermediaries. With
this approach, no modification to the CCMP messages/operations is this approach, no modification to the CCMP messages/operations is
required to use a different transport protocol. required to use a different transport protocol.
The remainder of this document focuses on the selected approach. The The remainder of this document focuses on the selected approach. The
CCMP protocol inserts XML-based CCMP requests into the body of HTTP CCMP protocol inserts XML-based CCMP requests into the body of HTTP
POST operations and retrieves responses from the body of HTTP '200 POST operations and retrieves responses from the body of HTTP '200
OK' messages. CCMP messages have a MIME-type of "application/ OK' messages. CCMP messages have a MIME-type of "application/
ccmp+xml", which appears inside the "Content-Type" and "Accept" ccmp+xml", which appears inside the "Content-Type" and "Accept"
fields of HTTP requests and responses. fields of HTTP requests and responses. Section 11 provides the
complete requirements for an HTTP implementation to support the CCMP.
7.2. CCMP protocol messages 7.2. CCMP protocol messages
CCMP messages are either requests or responses. The general CCMP CCMP messages are either requests or responses. The general CCMP
request message is defined in Section 7.2.1. The general CCMP request message is defined in Section 7.2.1. The general CCMP
response message is defined in Section 7.2.2. The details of the response message is defined in Section 7.2.2. The details of the
specific message type which is carried in the CCMP request and specific message type which is carried in the CCMP request and
response messages are described in Section 7.2.3. response messages are described in Section 7.2.3.
7.2.1. CCMP Request Message 7.2.1. CCMP Request Message
A CCMP request message is comprised of the following parameters: A CCMP request message is comprised of the following parameters:
confUserId: A mandatory parameter containing the XCON-URI of the confUserId: An optional parameter containing the XCON-USERID of the
client. This parameter is REQUIRED by the conferencing server for client. The "confUserID" parameter is used to determine if the
system specific Authorization, Authentication and Accounting (AAA) conference control client has the authority to perform the
procedures. operation, as well as other Authorization, Authentication and
Accounting (AAA) procedures. The attribute is required in the
CCMP request and response messages with the exception of the case
of a user who has no XCON-USERID and who wants to enter, via CCMP,
a conference whose identifier is known. In such case, a side-
effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 7.2.3.6.
confObjId: an optional parameter containing, whenever necessary, the confObjId: An optional parameter containing the XCON-URI of the
XCON-URI of the target conference object; target conference object.
specialized request message: this is specialization of the generic
operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest"
specialized messages.
password: An optional parameter that MUST be inserted in all
requests whose target conference object is password-protected (as
per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]).
specialized request message: This is specialization of the generic
request message (e.g., blueprintsRequest), containing parameters request message (e.g., blueprintsRequest), containing parameters
that are dependent on the specific request sent to the server, the that are dependent on the specific request sent to the server. A
details of which are provided in Section 7.2.3 specialized response message MUST be included in the CCMP request
message. The details for the specialized messages and associated
parameters are provided in Section 7.2.3.
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-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>
<!-- Definition of ccmp-request-message-type --> <!-- Definition of ccmp-request-message-type -->
<xs:complexType abstract="true" <xs:complexType abstract="true"
name="ccmp-request-message-type"> name="ccmp-request-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="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
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
7.2.2. CCMP Response Message 7.2.2. CCMP Response Message
A CCMP response message is comprised of the following parameters: A CCMP response message is comprised of the following parameters:
confUserId: A mandatory parameter containing the XCON-URI of the confUserId: A mandatory parameter in CCMP response messages
client which issued the request containing the XCON-USERID of the conferencing client who issued
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
parameter is REQUIRED in all responses except for the
"blueprintsResponse" and "confsResponse" specialized messages.
responseCode: A mandatory parameter containing the response code responseCode: A mandatory parameter containing the response code
associated with the request, chosen among the codes listed in associated with the request. The response code MUST be chosen
Section 7.2.2.1 from the codes listed in Section 7.2.2.1.
specialized response message: This is specialization of the generic specialized response message: This is specialization of the generic
response message, containing parameters that are dependent on the response message, containing parameters that are dependent on the
specific request sent to the server(e.g., blueprintsResponse), the specific request sent to the server (e.g., blueprintsResponse). A
details of which are provided in Section 7.2.3 specialized request 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 responseCode of
"badRequest". The details for the specialized messages and
associated parameters are provided in Section 7.2.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>
</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="0" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" minOccurs="0"
maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element ref="response-code" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 3: Structure of CCMP Response message Figure 3: Structure of CCMP Response message
7.2.2.1. CCMP Response Codes 7.2.2.1. CCMP Response Codes
All CCMP response messages MUST include a "responseCode". The All CCMP response messages MUST include a "responseCode". The
skipping to change at page 16, line 14 skipping to change at page 18, line 19
success: Successful completion of the requested operation. success: Successful completion of the requested operation.
modified: Successful completion of the requested operation, with modified: Successful completion of the requested operation, with
partial data returned in the confObjID having been modified from partial data returned in the confObjID having been modified from
the data included in the confObjID included request, either for a the data included in the confObjID included request, either for a
"create" or a "change" operation "create" or a "change" operation
badRequest: Syntactically malformed request badRequest: Syntactically malformed request
objectNotFound: Target object missing at the server objectNotFound: Target conference object missing at the server (it
refers to the 'confObjId' parameter in the generic request
message)
userNotFound: Target user missing at the server (it is related to
the XCON-USERID in the 'entity' attribute of the 'userInfo'
parameter when it is included in userRequests)
invalidConfUserID: User missing at the server (this code is returned
in the case of requests in which the 'confUserID' of the sender is
invalid).
invalidPassword: Target conference object's password contained in
the request is wrong.
passwordRequired: Conference password missing in a request to access
a password-protected conference object.
unauthorized: User not allowed to perform the required operation unauthorized: User not allowed to perform the required operation
forbidden: Operation not allowed (e.g., cancellation of a blueprint) forbidden: Operation not allowed (e.g., cancellation of a blueprint)
forbiddenDeleteParent: Cancel operation failed since the target forbiddenDeleteParent: Cancel operation failed since the target
object is a parent of child objects which depend on it, or because object is a parent of child objects which depend on it, or because
it effects, based on the 'parent-enforceable' mechanism, the it effects, based on the 'parent-enforceable' mechanism, the
corresponding element in a child object corresponding element in a child object
skipping to change at page 16, line 28 skipping to change at page 19, line 4
forbidden: Operation not allowed (e.g., cancellation of a blueprint) forbidden: Operation not allowed (e.g., cancellation of a blueprint)
forbiddenDeleteParent: Cancel operation failed since the target forbiddenDeleteParent: Cancel operation failed since the target
object is a parent of child objects which depend on it, or because object is a parent of child objects which depend on it, or because
it effects, based on the 'parent-enforceable' mechanism, the it effects, based on the 'parent-enforceable' mechanism, the
corresponding element in a child object corresponding element in a child object
forbiddenChangeProtected: Update refused by the server because the forbiddenChangeProtected: Update refused by the server because the
target element cannot be modified due to its implicit dependence target element cannot be modified due to its implicit dependence
on the value of a parent object ('parent-enforceable' mechanism) on the value of a parent object ('parent-enforceable' mechanism)
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.
The handling of a responseCode of 'modified', 'objectNotFound',
'userNotFound', 'deleteParentFailed' and 'changeFailedProtected' are
only applicable to specific operations for specialized message
responses and the details are provided in Section 7.2.3. The
following table summarizes these responseCodes and the specialized
message and operation to which they are applicable:
+---------------+------------+------------+------------+------------+
| Response code | Create | Retrieve | Update | Delete |
+---------------+------------+------------+------------+------------+
| Modified | All create | N/A | All update | N/A |
| | requests | | requests | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| objectNotFoun | userReques | All | All update | All delete |
| d | t, | retrieve | requests | requests |
| | sidebarBy | requests, | | |
| | ValRequest | EXCEPT: | | |
| | sidebars | blueprints | | |
| | ByRefReque | Request, | | |
| | st | confsRequ | | |
| | | est | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| userNotFound | userReques | userReques | userReques | userReques |
| | t(3rd part | t | t | t |
| | yinvite | | | |
| | with thir | | | |
| | duser | | | |
| | entity) | | | |
| | (*) | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| invalidConfUs | All create | All | All update | All delete |
| erID | requests, | retrieve | requests | requests |
| | EXCEPT: | requests | | |
| | userReques | | | |
| | twith no | | | |
| | confUserI | | | |
| | D(**) | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| forbiddenDele | N/A | N/A | N/A | All delete |
| teParent | | | | request |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | |
| forbiddenChan | N/A | N/A | All update | N/A |
| geProtected | | | requests | |
+---------------+------------+------------+------------+------------+
Table 1: Response codes and associated operations
(*) 'userNotFound' in answer to a 'userRequest/create' operation: in
the case of a third-party invite, this code can be returned if the
'confUserId' (contained in the 'entity' attribute of the 'userInfo'
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
invalid, an 'invalidConfUserID' error code is returned to the client.
(**) 'invalidConfUserID' is not sent in answers to 'userRequest/
create' messages having a 'null' confUserId, since this case is
associated with a user who is unaware of his own XCON-USERID, but
wants to enter a known conference.
In the case of a response code of 'requestTimeout', a conferencing
client MAY re-attempt the request within a period of time that would
be specific to a conference control client or conference control
server.
A response code of 'badRequest' indicates that the conference control
client sent a malformed request, which is indicative of an error in
the conference control client or in the conference control server.
The handling is specific to the conference control client
implementation (e.g., generate a log, display an error message,
etc.). It is NOT RECOMMENDED that the client re-attempt the request
in this case.
Response codes such as 'unauthorized', "forbidden' and
'operationNotAllowed' indicate the client does not have the
appropriate permissions, there is an error in the permissions, or
there is a system error in the client or conference control server,
thus re-attempting the request would likely not succeed and thus is
NOT RECOMMENDED.
Any unexpected or unknown responseCode SHOULD be treated by the
client in the same manner as a 'serverInternalError' responseCode,
the handling of which is specific to the conference control client
implementation.
7.2.3. Detailed CCMP Messages 7.2.3. Detailed CCMP Messages
Based on the request and response message structures described in Based on the request and response message structures described in
Section 7.2.1 and Section 7.2.2, the following summarizes the Section 7.2.1 and Section 7.2.2, the following summarizes the
specialized CCMP request/response types described in this document: specialized CCMP request/response types described in this document:
1. blueprintsRequest/blueprintsResponse 1. blueprintsRequest/blueprintsResponse
2. confsRequest/confsResponse 2. confsRequest/confsResponse
skipping to change at page 17, line 17 skipping to change at page 21, line 41
7. sidebarsByValRequest/sidebarsByValResponse 7. sidebarsByValRequest/sidebarsByValResponse
8. sidebarsByRefRequest/sidebarsByRefResponse 8. sidebarsByRefRequest/sidebarsByRefResponse
9. sidebarByValRequest/sidebarByValResponse 9. sidebarByValRequest/sidebarByValResponse
10. sidebarByRefRequest/sidebarByRefResponse 10. sidebarByRefRequest/sidebarByRefResponse
These CCMP request/response pairs use the fundamental CCMP operations These CCMP request/response pairs use the fundamental CCMP operations
as defined in Section 7 to manipulate the conference data. Table 1 as defined in Section 7 to manipulate the conference data. Table 2
summarizes the CCMP operations and corresponding actions that are summarizes the CCMP operations and corresponding actions that are
valid for a specific CCMP request type, noting that neither the valid for a specific CCMP request type, noting that neither the
blueprintsRequest/blueprints/Response or confsRequest/ConfsResponse blueprintsRequest/blueprintsResponse or confsRequest/ConfsResponse
require an "operation" parameter. The corresponding response MUST require an "operation" parameter. The corresponding response MUST
contain the same operation. Note that some entries are labeled "N/A" contain the same operation. Note that some entries are labeled "N/A"
indicating the operation is invalid for that request type. In the indicating the operation is invalid for that request type. In the
case of an "N/A*", the operation MAY be allowed for specific case of an "N/A*", the operation MAY be allowed for specific
privileged users or system administrators, but is not part of the privileged users or system administrators, but is not part of the
functionality included in this document. functionality included in this document.
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete | | Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | | | ------------- | | | | |
| -Request Type | | | | | | -Request Type | | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| blueprintsReq | Get list | N/A | N/A | N/A | | blueprintsReq | Get list | N/A | N/A | N/A |
| uest | of | | | | | uest | of | | | |
| | blueprints | | | | | | blueprints | | | |
| | . | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| blueprintRequ | Get | N/A* | N/A* | N/A* | | blueprintRequ | Get | N/A* | N/A* | N/A* |
| est | blueprint. | | | | | est | blueprint | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| confsRequest | Get list | N/A | N/A | N/A | | confsRequest | Get list | N/A | N/A | N/A |
| | of | | | | | | of confs | | | |
| | conference | | | | | | (active, | | | |
| | s (active, | | | |
| | etc.) | | | | | | etc.) | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| confRequest | Gets | Creates | Changes | Deletes | | confRequest | Gets | Creates | Changes | Deletes |
| | conference | conference | conference | conference | | | conference | conference | conference | conference |
| | object or | object | object | Object as | | | object or | object | object | Object as |
| | blueprint. | | | a whole. | | | blueprint | | | a whole |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| usersRequest | Gets a | N/A | Adds or | N/A | | usersRequest | Gets | N/A | Changes | N/A |
| | specific | | modifies | | | | specific | | specified | |
| | users | | the | | | | users | | users | |
| | element. | | specified | | | | element | | element | |
| | | | users | |
| | | | element. | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| userRequest | Gets a | Creates | Adds or | Deletes a | | userRequest | Gets | Adds a | Changes | Deletes |
| | specific | XCON-UserI | modifies | user | | | specific | user to a | specified | user |
| | user | D . | the | element as | | | user | conference | user | element as |
| | element. | | specified | a whole. | | | element. | . * | element. | a whole. |
| | | | user | |
| | | | element. | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarsByVal | Gets | N/A | N/A | N/A | | sidebarsByVal | Gets | N/A | N/A | N/A |
| Request | sidebars-b | | | | | Request | sidebars-b | | | |
| | y -val | | | | | | y -val | | | |
| | element | | | | | | element | | | |
| | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarsByRef | Gets | N/A | N/A | N/A | | sidebarsByRef | Gets | N/A | N/A | N/A |
| Request | sidebars-b | | | | | Request | sidebars-b | | | |
| | y -ref | | | | | | y -ref | | | |
| | element | | | | | | element | | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarByValR | Gets a | N/A | Adds or | Removes/de | | sidebarByValR | Gets a | Creates a | Adds or | Removes/ |
| equest | sidebar | | modifies a | l etes the | | equest | sidebar | sidebar by | modifies a | deletes |
| | element. | | sidebar. | entire | | | element | cloning | sidebar | entire |
| | | | | sidebar. | | | | existing | | sidebar |
| | | conf | | |
| | | object | | |
| | | | | | | | | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| | | | | | | | | | | |
| sidebarByRefR | Gets a | N/A | Adds or | Removes/de | | sidebarByRefR | Gets a | Creates | Adds or | Removes/ |
| equest | sidebar | | modifies a | l etes the | | equest | sidebar | sidebar by | modifies | deletes |
| | element. | | sidebar. | entire | | | element | cloning | sidebar | entire |
| | | | | sidebar. | | | | existing | | sidebar |
| | | conf | | |
| | | object | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 1: Request Type Operation Specific Processing Table 2: Request Type Operation Specific Processing
The following additional parameters are included in the specialized
CCMP request/response messages detailed in the subsequent sections:
operation: An optional parameter for each CCMP request/response
message. This parameter is REQUIRED in all messages except for
the "blueprintRequest", "blueprintResponse", "confsRequest" and
"confsResponse" messages.
blueprintInfo: An optional parameter used for the blueprintResponse
message. It is of type "conference-type" as defined in the XCON
data model and contains the data of the conference object
representing the blueprint in the conference server. This
parameter SHOULD not be included in any other response type
messages and SHOULD only be included in a "create", "update" or
"delete" operation for a blueprintRequest message in special cases
where a user has special privileges such as an administrator.
blueprintsInfo: An optional parameter used for the
blueprintsResponse message. It contains a list of elements of
type "blueprintInfo". This parameter SHOULD not be included in
any other response type messages and SHOULD only be included in a
"create", "update" or "delete" operation for a blueprintRequest
message in special cases where a user has special privileges such
as an administrator.
confsInfo: An optional parameter used for the confsResponse message. *: This operation can involve the creation of an XCON-UserID, if the
It contains a list of XCON-URIs. This parameter SHOULD not be sender does not add it in the 'confUserId' parameter, or if the
included in any other response type messages and SHOULD only be 'entity' field of the userInfo parameter is void.
included in a "create", "update" or "delete" operation for a
blueprintRequest message in special cases where a user has special
privileges such as an administrator.
usersInfo: An OPTIONAL parameter that MAY be included in a Additional parameters included in the specialized CCMP request/
usersRequest and usersReponse message, depending upon the response messages are detailed in the subsequent sections.
operation. The 'usersInfo' parameter carries an object compliant
with the <users> field of the XCON data model.
7.2.3.1. blueprintsRequest and blueprintsResponse messages 7.2.3.1. blueprintsRequest and blueprintsResponse messages
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 7.2.3.3. A specific 'blueprintRequest' message per Section 7.2.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 associated those specified for the basic CCMP request message. The 'confObjId'
'blueprintsResponse' message SHOULD contain, as shown in Figure 4, a and 'operation' parameters MUST NOT be included in the request or
'blueprintsInfo' parameter containing the above mentioned XCON-URI
list. The 'confObjId' parameter is NOT REQUIRED in the request or
response for this transaction. response for this transaction.
The associated 'blueprintsResponse' message SHOULD contain, as shown
in Figure 4, a 'blueprintsInfo' parameter containing the above
mentioned XCON-URI list. If the 'blueprintsInfo' parameter is empty,
the conference control client MAY attempt to use a local default
blueprint to create conferences. However, the handling in this
situation is specific to the conference control client
implementation.
<!-- blueprintsRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</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>
skipping to change at page 21, line 43 skipping to change at page 25, line 10
</xs:complexType> </xs:complexType>
Figure 4: Structure of the blueprintsRequest and blueprintsResponse Figure 4: Structure of the blueprintsRequest and blueprintsResponse
messages messages
7.2.3.2. confsRequest and confsResponse messages 7.2.3.2. confsRequest and confsResponse messages
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 A
'confsRequest' message REQUIRES no additional parameters beyond those 'confsRequest' message REQUIRES no additional parameters beyond those
specified for the basic CCMP request message. The associated specified for the basic CCMP request message. The 'confObjId'
'confsResponse' message SHOULD contain the list of XCON-URIs in the parameter MUST NOT be included in the confsRequest message. The
'confsInfo' parameter. The 'confObjId' parameter is NOT REQUIRED for 'confsRequest' message is of a "retrieve-only" type, since the sole
this transaction. A user, upon receipt of the response message, can purpose is to collect information available at the conference server.
interact with the available conference objects through further CCMP Thus, an 'operation' parameter MUST NOT be included in a
messages. The 'confsRequest' message is of a "retrieve-only" type, 'confsRequest' message. The associated 'confsResponse' message
since the sole purpose is to collect information available at the SHOULD contain the list of XCON-URIs in the 'confsInfo' parameter. A
conference server. Thus, an 'operation' parameter SHOULD NOT be user, upon receipt of the response message, can interact with the
included in a 'confsRequest' message. available conference objects through further CCMP messages.
<!-- confsRequest --> <!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type"> <xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- confsResponse --> <!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type"> <xs:complexType name="ccmp-confs-response-message-type">
skipping to change at page 22, line 34 skipping to change at page 26, line 4
<!-- 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
7.2.3.3. blueprintRequest and blueprintResponse messages 7.2.3.3. blueprintRequest and blueprintResponse messages
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. Only include an 'operation' parameter and a 'confObjId' parameter. The
the "retrieve" 'operation' SHOULD should be included in a 'confObjId' parameter MUST contain the XCON-URI of the blueprint,
'blueprintRequest message. The 'create', 'update' and 'delete' which might have been previously retrieved through a
operations SHOULD NOT be included in a 'blueprintRequest' message 'blueprintsRequest' message. The blueprintRequest message SHOULD NOT
except in the case of privileged users (e.g. the conference server contain an 'operation' parameter other than 'retrieve'. The
administration staff). The 'confObjId' parameter contains the XCON- 'create', 'update' and 'delete' operations SHOULD NOT be included in
URI of the blueprint, which might have been previously retrieved a 'blueprintRequest' message except in the case of privileged users
through a 'blueprintsRequest' message. (e.g. the conference server administration staff).
In the case of responseCode of "success" for a 'retrieve' operation, In the case of responseCode of "success" for a 'retrieve' operation,
the 'blueprintInfo' parameter SHOULD be included in the the 'blueprintInfo' parameter MUST be included in the
'blueprintResponse' message. Inside responses, the 'blueprintInfo' 'blueprintResponse' message. The 'blueprintInfo' parameter contains
parameter carries the conference document associated with the the conference document associated with the blueprint as identified
blueprint specified in the request. by the 'confObjID' parameter specified in the blueprintRequest.
If a response code of "objectNotFound" is received in a
'blueprintResponse' message, it is RECOMMENDED that a conference
control client attempt to retrieve another conference blueprint if
more than one had been received in the "blueprintsResponse" message.
If there was only one blueprint in the "blueprintsResponse"
initially, then the client should send another "blueprintsRequest"
message to determine if there may be new or additional blueprints for
the specific conferencing system. If this "blueprintsResponse"
message contains no blueprints, the handling is specific to the
conference control client.
<!-- blueprintRequest --> <!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type"> <xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="blueprintRequest" /> <xs:element ref="blueprintRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType"/> <xs:element name="blueprintRequest" type="blueprintRequestType"/>
<xs:complexType name="blueprintRequestType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-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>
skipping to change at page 25, line 12 skipping to change at page 28, line 11
Figure 6: Structure of the blueprintRequest and blueprintResponse Figure 6: Structure of the blueprintRequest and blueprintResponse
messages messages
7.2.3.4. confRequest and confResponse messages 7.2.3.4. confRequest and confResponse messages
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 and/or 'confInfo' parameter MAY be included. 'confObjId' parameter MAY be included. The 'confObjId' parameter
The 'confObjId' parameter contains the XCON-URI of the specific contains the XCON-URI of the specific active or registered
active or registered conference. The 'confInfo' parameter contains conference. The requirements for inclusion of 'confInfo' parameter
the conference data that is the target of the 'confRequest' - i.e. depends upon the specific 'operation' in the confRequest/confResponse
the <conference-info> document (compliant with the XCON data model and are detailed below. The detailed information included in the
structure). 'confInfo' parameter MUST follow the rules as specified in the XCON
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 embraced: 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 the blueprint to be cloned, while the
'confInfo' parameter SHOULD NOT be included in the request; '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 SHOULD NOT be included in creation"): the 'confObjId' parameter MUST NOT be included in the
the request, whereas the 'confInfo' parameter describing the request, whereas the 'confInfo' parameter describing the
conference to be created MUST be included in the request. conference to be created MUST be included in the confRequest.
In both cases, a successful completion of the request carries back a In both cases, the confResponse, for a successful completion of a
responseCode of 'success' and SHOULD contain, in the 'confObjId' 'create' operation, contains a responseCode of 'success' and MUST
parameter, the XCON-URI of the created conference. In addition, the contain the XCON-URI of the created conference in the 'confObjID'
'confInfo' parameter transporting the created conference document parameter. In addition, the 'confInfo' parameter transporting the
SHOULD be included. Obviously, the newly created object can be created conference document MUST be included. Obviously, the newly
manipulated by the client through subsequent 'update' operations. created object can be manipulated by the client through a subsequent
'update' operation. For example, after the creation and addition of
the participants, the creator may want to lock the conference object.
This can be accomplished with a confRequest with an operation of
'update' by setting the 'locked' element in the confInfo included in
the confRequest message described below.
In the case of 'retrieve' or 'delete' operations, the 'confObjId' In the case of a confRequest with a 'retrieve' operation, the
representing the XCON-URI of the target conference MUST be included 'confObjId' representing the XCON-URI of the target conference the
and the 'confInfo' SHOULD NOT be included in the request. Inside the conference control client MUST be included and the 'confInfo'
response to a 'retrieve' request, in case of responseCode of parameter SHOULD NOT be included in the request. The conferencing
'success', the 'confInfo' containing a description of the target server MUST ignore any 'confInfo' parameter that is received in a
conference object MUST be included. On the other hand, a response to 'confRequest' and this 'confInfo' parameter MUST NOT be included in
a 'delete' operation SHOULD NOT include the 'confInfo' parameter. the confResponse. If the confResponse for the 'retrieve' operation
contains a responseCode of 'success', the 'confInfo' parameter MUST
be included in the response. The 'confInfo' parameter MUST contain
the entire conference document describing the target conference
object in its current state.
In case of an 'update' operation, the 'confInfo' and 'confObjID MUST In case of of a confRequest with an 'update' operation, the
be included in the request. The 'confInfo' represents an object of 'confInfo' and 'confObjID' MUST be included in the request. The
type "conference-type" containing all the changes to be applied to 'confInfo' represents an object of type "conference-type" containing
the conference whose identifier is 'confObjId'. In the case of a all the changes to be applied to the conference whose identifier is
responseCode of success, no additional information is REQUIRED in the 'confObjId'. In the case of a confResponse with a responseCode of
'confResponse'message. For a successful response, the conference 'success', no additional information is REQUIRED in the
server should consider as unchanged all parts of the referenced 'confResponse' message. A responseCode of 'success' indicates that
conference document. However, if the target conference object has the referenced conference document has not been changed by the
not been modified exactly as required by the client the responsecode conference server. However, if the target conference object was not
MUST be set to 'modified' and the 'confInfo' parameter MUST contain updated exactly as indicated by the client a responseCode of
the entire conference document to which the required changes have 'modified' MUST be included in the 'confResponse' and the 'confInfo'
been (at least partially) applied. parameter MUST contain the entire conference document to which any
changes have been applied. A responseCode of 'changeFailedProtected'
indicates that the conferencing client is not allowed to make the
changes reflected in the 'confInfo' in the initial request. This
could be due to policies, roles, specific privileges, etc.), with the
reason specific to a conferencing system and its configuration.
Thus, it is 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
'confObjId' representing the XCON-URI of the target conference MUST
be included and the 'confInfo' SHOULD NOT be included in the request.
The conferencing server MUST ignore any 'confInfo' parameter that is
received. The confResponse MUST contain the same 'confObjId'that was
included in the confRequest. The confResponse MUST contain a
responseCode of 'success' if the targeted conference is successfully
deleted. If the confResponse for the 'retrieve' operation contains a
responseCode of 'success', the confResponse SHOULD NOT contain the
'confInfo' parameter. If the conferencing server cannot delete the
conference referenced by the 'confObjId' received in the confRequest
because it is the parent of another conference object that is in use,
the conferencing server MUST return a responseCode 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 27, line 22 skipping to change at page 30, line 22
</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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="confInfo" <xs:element name="confInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" 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>
skipping to change at page 28, line 39 skipping to change at page 31, line 38
7.2.3.5. usersRequest and usersResponse messages 7.2.3.5. usersRequest and usersResponse messages
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. Besides the usual this specific part of a conference document.
'operation' parameter, a 'usersInfo' parameter MAY also be included
depending upon the operation. The 'usersInfo' parameter carries an
object compliant with the <users> field of the XCON data model.
An 'operation' parameter MUST be included in a "usersRequest" A 'usersInfo' parameter MAY be included in a usersRequest message
message. Two operations are allowed in a "usersRequest" message: depending upon the operation. If the 'userInfo' parameter is
included in the usersRequest message, the parameter MUST be compliant
with the <users> field of the XCON data model.
Two operations are allowed for a "usersRequest" message:
1. retrieve: In this case the request SHOULD NOT include a 1. retrieve: In this case the request SHOULD 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 desired <users> element in the 'usersInfo' parameter. The
conference server MUST be ignore a 'usersInfo' parameter if it is
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 responseCode is 'success', then the 'usersInfo' parameter
SHOULD NOT be returned. If the responseCode is 'modified', the SHOULD NOT be returned. Any 'usersInfo' parameter that is
'usersInfo' parameter MUST be included in the response. The returned SHOULD be ignored. If the responseCode is 'modified',
the 'usersInfo' parameter MUST be included in the response. The
'usersInfo' reflects to the client the (partial) modifications 'usersInfo' reflects to the client the (partial) modifications
that have been applied. that have been applied. A responseCode of
'changeFailedProtected' indicates that the conferencing client is
not allowed to make the changes reflected in the 'usersInfo' in
usersRequest message. This could be due to policies, roles,
specific privileges, etc.), with the reason specific to a
conferencing system and its configuration. Thus, it is
RECOMMENDED that the client continue using the previous version
of the 'usersInfo'.
Operations of 'create' and 'delete' make little sense in the case of Operations of 'create' and 'delete' are not applicable to a
a usersRequest and SHOULD NOT be considered by the server, which usersRequest message and MUST NOT be considered by the server, which
means that a responseCode of 'forbidden' SHOULD be included in the means that a responseCode 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>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType --> <!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" /> <xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="usersInfo" <xs:element name="usersInfo"
type="info:users-type" minOccurs="0" /> type="info:users-type" minOccurs="0" />
</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>
skipping to change at page 31, line 10 skipping to change at page 34, line 10
</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
7.2.3.6. userRequest and userResponse messages 7.2.3.6. userRequest and userResponse messages
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 MAY be used to either create, specific conference user, the message is used to request that the
or modify, or delete information about a user. A "userRequest" MUST conference server either create, modify, or delete information about
include the 'operation' parameter, and MAY include a 'userInfo' a user. A "userRequest" message MUST include the 'confObjID', the
parameter containing the detailed user's information. 'operation' parameter, and MAY include a 'userInfo' parameter
containing the detailed user's information depending upon the
operation and whether the 'userInfo' has already been populated for a
specific user. Note that a user may not necessarily be a
conferencing control client (i.e., some participants in a conference
are not "XCON aware").
Conference users can be created in a number of different ways. Let We remark that an XCON-USERID SHOULD be assigned to each and every
us first consider the case of a user who wants to enter a conference user subscribed to the system. In such a way, a user who is not a
(i.e. to add himself to the conference). In such a case, the conference participant can make requests (provided she has
'userInfo' parameter in the request (which MUST have an 'operation' successfully passed AAA checks), like creating a conference,
value set to "create") SHOULD contain a <user> element (compliant retrieving conference information, etc..
with the XCON data model) having its 'entity' attribute set to a
value which represents the XCON-USERID of the user in question.
A different situation is one in which the CCMP client acts on behalf Conference users can be created in a number of different ways. In
of a third user, whose XCON-USERID is known. In this case, the each of these cases the operation MUST be set to "create" in the
<user> element SHOULD contain an 'entity' attribute whose value is userRequest message. Each of the userResponse messages for these
set to the XCON-USERID of the user in question. As a final case, if cases MUST include the 'confObjID', 'confUserID', 'operation' and
the CCMP client is not aware of the XCON-USERID of the user to be 'responseCode' parameters. In the case of a response code of
inserted, the key attribute (i.e. 'entity') SHOULD NOT be included in 'success', the userResponse message MAY include the 'userInfo'
the request: the XCON-USERID generated by the conference server for parameter depending upon the manner in which the user was created:
such a user MUST be returned to the client as the value of the
'entity' attribute in the 'userInfo' parameter of the response if the o Conferencing client with an XCON-USERID adds itself to the
responseCode is "success". The last case also applies to a CCMP conference: In this case, the 'userInfo' parameter MAY be included
client that obtains a new user profile in the context of a in the userRequest. The 'userInfo' parameter MUST contain a
<user> element (compliant with the XCON data model) and the
'entity' attribute MUST be set to a value which represents the
XCON-USERID of the user initiating the request. No additional
parameters beyond those previously described are REQUIRED in the
userResponse message, in the case of a responseCode of 'success'.
o Conferencing client acts on behalf of a third user whose XCON-
USERID is known: in this case, the 'userInfo' parameter MUST be
included in the userRequest. The 'userInfo' parameter MUST
contain a <user> element and the 'entity' attribute value MUST be
set to the XCON-USERID of the third user in question. No
additional parameters beyond those previously described are
REQUIRED in the userResponse message, in the case of a
responseCode of 'success'.
o A conferencing client who has no XCON-USERID and who wants to
enter, via CCMP, a conference whose identifier is known. In such
case, a side-effect of the request is that the user is provided
with an appropriate XCON-USERID. The involved messages
(userRequest and userResponse) in such case should look like the
following:
Request fields:
confUserId=null;
confObjId=confXYZ;
operation=create;
userInfo=
<userInfo entity=null>
<endpoint entity=''sip:GHIL345@blablabla''>
...
Response fields (in case of success):
confUserId=user345;
confObjId=confXYZ;
operation=create;
response-code=success;
userInfo=null; //or the entire userInfo object
Figure 11: userRequest and userResponse in the absence of an xcon-
userid
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
request. The XCON-USERID generated by the conference server for
such a user MUST also be returned to the client as the value of
the 'entity' attribute in the 'userInfo' parameter of the response
if the responseCode is "success". This scenario is mainly
intended to support the case whereby an XCON aware client is added
to a conference by a third party, e.g. the chairperson of the
conference. conference.
o Conferencing client obtains a new user profile in the context of a
conference: this case is handled in the same manner as the
previous case associated with the creation of a user on behalf of
a third party when the XCON-USERID is unknown, thus indicating to
the conference server that the client wants a new XCON-USERID and
associated 'userInfo' parameter to be allocated and populated
respectively.
In both cases, the confResponse, for a successful completion of a
'create' operation, contains a responseCode of 'success' and MUST
contain the XCON-URI of the created conference in the 'confObjID'
parameter. In addition, the 'confInfo' parameter transporting the
created conference document MUST be included. Obviously, the newly
created object can be manipulated by the client through a subsequent
'update' operation.
In the case of a userRequest with a 'retrieve' operation, the
'confObjId' representing the XCON-URI of the target conference MUST
be included. The 'confUserId' MUST be included in the userRequest
message. This 'confUserId' indicates the specific <user> element in
XCON data model, as reflected by the 'entity' attribute in the <user>
element that the conference client is requesting to retrive. The
'userInfo' parameter SHOULD NOT be included in the request. The
conferencing server MUST ignore any 'userInfo' parameter that is
received in a 'userRequest' and this 'userInfo' parameter MUST NOT be
included in the userResponse. If the userResponse for the 'retrieve'
operation contains a responseCode of 'success', the 'userInfo'
parameter MUST be included in the response.
In case of of a userRequest with an 'update' operation, the
'confObjID', 'confUserID' and 'userInfo' MUST be included in the
request. The 'userInfo' is of type "user-type" and contains all the
changes to be applied to a specific <user> element in the conference
object identified by the 'confObjId' in the userRequest message. The
'entity' attribute in the 'userInfo' MUST be equal to the
'confUserID' in the userRequest message. In the case of a user
Response with a responseCode of 'success', no additional information
is REQUIRED in the 'confResponse' message. A responseCode of
'success' indicates that the referenced user element has been updated
by the conference server. However, if the specific <user> element
was not updated exactly as indicated by the client a responseCode of
'modified' MUST be included in the 'confResponse' and the 'userInfo'
parameter MUST contain the entire <user> element which to which the
conference server has applied changes. A responseCode of
'changeFailedProtected' indicates that the conferencing client is not
allowed to make the changes reflected in the 'userInfo' in the
initial request. This could be due to policies, roles, specific
privileges, etc., with the reason specific to a conferencing system
and its configuration. Thus, it is RECOMMENDED that the client
continue using the previous version of the 'userInfo'.
In the case of a userRequest with a 'delete' operation, the
'confObjId' representing the XCON-URI of the target conference and
the 'confUserID' associated with the specific <user> element (i.e.,
matching the 'entity' attribute) that the conferencing client is
requesting be deleted MUST be included in the userRequest message.
The 'userInfo' SHOULD NOT be included in the request. The
conferencing server MUST ignore any 'userInfo' parameter that is
received. The userResponse MUST contain the same 'confObjId' that
was included in the userRequest. The userResponse MUST contain a
responseCode of 'success' if the <user> element associated with the
specific 'confUserId' is successfully deleted. If the userResponse
for the 'retrieve' operation contains a responseCode of 'success',
the userResponse SHOULD NOT contain the 'userInfo' parameter.
<!-- userRequest --> <!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type"> <xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="userRequest" /> <xs:element ref="userRequest" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- 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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="userInfo" <xs:element name="userInfo"
type="info:user-type" minOccurs="0" /> type="info:user-type" minOccurs="0" />
</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>
skipping to change at page 33, line 4 skipping to change at page 38, line 47
<!-- 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>
Figure 11: Structure of the userRequest and userResponse messages
Figure 12: Structure of the userRequest and userResponse messages
7.2.3.7. sidebarsByValRequest and sidebarsByValResponse messages 7.2.3.7. sidebarsByValRequest and sidebarsByValResponse messages
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 request MUST include an 'operation' of by the 'confObjId'. The request MUST include an 'operation' of
"retrieve" and a 'confObjId'. A "sidebarsByValResponse" MUST contain "retrieve" and a 'confObjId' parameter. Operations of 'create',
a 'sidebarsByValInfo' parameter reporting the desired <sidebars-by- 'update' and 'delete' MUST NOT be included in a sidebarsByValRequest
val> element. The 'sidebarsByValInfo' parameter contains the message. A "sidebarsByValResponse" with a responseCode of 'success'
identifiers of the sidebars derived from the main conference. For MUST contain a 'sidebarsByValInfo' parameter containing the desired
the creation and manipulation of sidebars, a different message has <sidebars-by-val> element. The 'sidebarsByValInfo' parameter
been envisaged, namely "sidebarByValRequest", which is described in contains the identifiers of the sidebars derived from the main
Section 7.2.3.8 conference in the form of XCON-URIs. The retrieved sidebars can then
be updated or deleted using the "sidebarByValRequest" message, which
is described in Section 7.2.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>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValRequestType --> <!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest" <xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" /> type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType"> <xs:complexType name="sidebarsByValRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByValInfo" <xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/> type="info:sidebars-by-val-type" minOccurs="0"/>
</xs: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">
skipping to change at page 34, line 23 skipping to change at page 41, line 4
<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>
</xs:complexType> </xs:complexType>
Figure 13: Structure of the sidebarsByValRequest and
Figure 12: Structure of the sidebarsByValRequest and
sidebarsByValResponse messages sidebarsByValResponse messages
7.2.3.8. sidebarByValRequest and sidebarByValResponse messages 7.2.3.8. sidebarByValRequest and sidebarByValResponse messages
A "sidebarByValRequest" message MUST contain the 'operation' A sidebarByValRequest message MUST contain the 'operation' parameter
parameter which discriminates among creation, modification and which discriminates among retrieval, creation, modification and
deletion of a specific sidebar. The 'sidebarByValInfo' parameter, in deletion of a specific sidebar. The other required parameters depend
turn, contains the description (in an XCON data model compliant upon the type of operation.
fashion) of the sidebar itself. The 'confObjId' parameter of such
messages MUST contain the XCON-URI of the main conference which the In the case of a 'create' operation, the 'confObjId' parameter MUST
sidebar belongs to. The XCON-URI of the sidebar is contained in the be included in the sidebyValRequest message. In this case, the
'entity' attribute of the above mentioned 'sidebarByValInfo' 'confObjId' parameter contains the XCON-URI of the main conference in
document. In case of creation, the 'sidebarByValInfo' SHOULD NOT be which the sidebar is to be created. The 'sidebarByValInfo' parameter
included in the request, since, as envisaged in the XCON framework SHOULD NOT be included in the request, since, as envisaged in the
([RFC5239]), sidebars are always created by cloning the main XCON framework ([RFC5239]), sidebars are always created by cloning
conference. The 'sidebarByValInfo' parameter MUST be included in a the main conference. Any 'sidebarByValInfo' included in the request
successful response. The 'sidebarByValInfo' represents the created MUST be ignored. The conference server sets the 'active' element to
sidebar, whose URI appears in the 'entity' attribute. 'false' of the cloned conference to reflect that it is a "reserved"
conference. The conference server MUST update the conference object
reflected by the 'confObjID' parameter, in the sidebarbyVal request
message, from which the sidebar was created to reflect the newly
created sidebar. The newly created conference object MUST be
included in the response in the 'sidebarByValInfo' parameter, if the
responseCode is 'success'. The URI for the conference object
associated with the newly created sidebar object MUST appear in the
'entity' attribute in the 'sidebarByValInfo'. The conference server
can notify any conferencing clients that have subscribed to the
conference event package, and are authorized to receive the
notifications, of the addition of the sidebar to the conference.
In the case of a 'sidebarByVal' request with an operation of
'retrieve', the URI for the conference object created for the
sidebar, as reflected by the 'entity' attribute in the
'sidebarByValInfo', received in the response to a 'create' operation
or in a sidebarsByValResponse message, MUST be included in the
'confObjID' parameter in the request. This 'retrieve' operation is
handled by the conference server in the same manner as a 'retrieve'
operation included in a confRequest message as detailed in
Section 7.2.3.4.
In the case of a 'sidebarByVal' request with an operation of
'update', the 'sidebarByValInfo' MUST also be included in the
request. The 'entity' attribute in the 'sidebarByValInfo' identifies
the specific sidebar instance to be updated. The URI for the
conference object containing the specific sidebar-by-value element to
be updated MUST be included in the 'confObjID' parameter in the
request. An 'update' operation on the 'sidebarByValInfo' is handled
by the conference server in the same manner as an 'update' operation
on the confInfo included in a confRequest message as detailed in
Section 7.2.3.4.
If an 'operation' of 'delete' is included in the sidebarByVal
request, the 'sidebarByValInfo' parameter SHOULD NOT be included in
the request. Any 'sidebarByValInfo' included in the request SHOULD
be ignored by the conference server. The URI for the conference
object for the sidebar, as reflected by the 'entity' attribute in the
'sidebarByValInfo', received in the response to a 'create' operation
or in a sidebarsByValResponse message, MUST be included in the
'confObjID' parameter in the request. If the specific conferencing
user as reflected by the 'confUserID' in the request is authorized to
delete the conference, the conference server deletes the conference
object reflected by the 'confObjID' parameter and updates the data in
the conference object from which the sidebar was cloned. The
conference server can notify any conferencing clients that have
subscribed to the conference event package, and are authorized to
receive the notifications, of the deletion of the sidebar to the
conference.
<!-- 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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</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">
skipping to change at page 36, line 4 skipping to change at page 44, line 4
<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>
</xs:complexType> </xs:complexType>
Figure 13: Structure of the sidebarByValRequest and Figure 14: Structure of the sidebarByValRequest and
sidebarByValResponse messages sidebarByValResponse messages
7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse messages 7.2.3.9. sidebarsByRefRequest and sidebarsByRefResponse messages
Similar to the "sidebarsByValRequest", a "sidebarsByRefRequest" can Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be
be invoked to retrieve the <sidebars-by-ref> element of the invoked to retrieve the <sidebars-by-ref> element of the conference
conference object identified by the 'confObjId' parameter. The object identified by the 'confObjId' parameter. The 'confObjID'
'confObjID' parameter MUST be included in the request. An operation parameter MUST be included in the request. An operation of
of 'retrieve' MUST also be included in the request. In the case of a 'retrieve' MUST also be included in the request. Operations of
responseCode of success, the 'sidebarsByRefInfo' parameter, 'create', 'update' and 'delete' MUST NOT be included in a
containing the <sidebars-by-ref> element of the conference object, sidebarsByValRequest message. In the case of a responseCode of
MUST be included in the response. The <sidebars-by-ref> element 'success', the 'sidebarsByRefInfo' parameter, containing the
represents the set of URIs of the sidebars associated with the main <sidebars-by-ref> element of the conference object, MUST be included
conference, whose description (in the form of a standard XCON in the response. The <sidebars-by-ref> element represents the set of
conference document) is external to the main conference itself. URIs of the sidebars associated with the main conference, whose
Through the retrieved URIs, it is then possible to access single description (in the form of a standard XCON conference document) is
sidebars by exploiting the ad-hoc defined "sidebarByRef" request, external to the main conference itself. Through the retrieved URIs,
described in Section 7.2.3.10. it is then possible to access single sidebars using the
"sidebarByRef" request message, described in Section 7.2.3.10.
<!-- 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>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequestType --> <!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest" <xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" /> type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType"> <xs:complexType name="sidebarsByRefRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByRefInfo" <xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/> type="info:uris-type" minOccurs="0"/>
</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>
skipping to change at page 37, line 27 skipping to change at page 46, line 4
<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>
Figure 15: Structure of the sidebarsByRefRequest and
Figure 14: Structure of the sidebarsByRefRequest and
sidebarsByRefResponse messages sidebarsByRefResponse messages
7.2.3.10. sidebarByRefRequest and sidebarByRefResponse messages 7.2.3.10. sidebarByRefRequest and sidebarByRefResponse messages
A "sidebarByRefRequest" message along with the REQUIRED 'operation' A sidebarByRefRequest message MUST contain the 'operation' parameter
parameter, MAY contain a 'sidebarByRefInfo' parameter describing the which discriminates among retrieval, creation, modification and
conference object (compliant with the XCON data model) associated deletion of a specific sidebar. The other required parameters depend
with the sidebar. In case of 'retrieve', 'delete', 'update' and upon the type of operation.
'create' operations, the 'confObjId' parameter representing the XCON-
URI of the target sidebar MUST be included. The 'sidebarByRefInfo' In the case of an 'operation of 'create', the 'confObjId' parameter
parameter is NOT REQUIRED in the first two cases ('retrieve' and representing the XCON-URI of the conference from which the sidebar is
'delete'), whereas in the case of an 'update' the 'sidebarByRefInfo' to be created (cloned) MUST be included in all sidebarByRefRequest
parameter MUST contain the changes to be applied to the referenced messages. The'sidebarByRefInfo' parameter SHOULD NOT be included in
sidebar. The 'sidebarByRefInfo' MUST NOT be included for a 'create' the request, since, as envisaged in the XCON framework ([RFC5239]),
operation since, as already stated, sidebar creation is by default sidebars are always created by cloning the main conference. Any
achieved by cloning the main conference. 'sidebarByRefInfo' included in the request MUST be ignored. If the
creation of the sidebar is successful, the conference server MUST
update the 'sidebars-by-ref' element in the conference object from
which the sidebar was created (i.e., as identified by the 'confObjID'
in the original sidebarByRef request), with the URI for the newly
created sidebar. The newly created conference object MUST be
included in the response in the 'sidebarByRefInfo' parameter with a
responseCode 'success'. The URI for the conference object associated
with the newly created sidebar object MUST appear in the 'entity'
attribute in the 'sidebarByRefInfo'. The conference server can
notify any conferencing clients that have subscribed to the
conference event package, and are authorized to receive the
notifications, of the addition of the sidebar to the conference.
In the case of a 'sidebarByRef' request with an operation of
'retrieve', the URI for the conference object created for the sidebar
MUST be included in the 'confObjID' parameter in the request. The
'sidebarByRefInfo' MUST also be included in the request in the case
of an 'operation' of 'update'. An 'update' operation on the
'sidebarByRefInfo' is handled by the conference server in the same
manner as a 'retrieve' operation on the confInfo included in a
confRequest message as detailed in Section 7.2.3.4.
In the case of a 'sidebarByRef' request with an operation of
'update', the URI for the conference object created for the sidebar
MUST be included in the 'confObjID' parameter in the request. The
'sidebarByRefInfo' MUST also be included in the request in the case
of an 'operation' of 'update'. An 'update' operation on the
'sidebarByRefInfo' is handled by the conference server in the same
manner as an 'update' operation on the confInfo included in a
confRequest message as detailed in Section 7.2.3.4.
If an 'operation' of 'delete' is included in the sidebarByRef
request, the 'sidebarByRefInfo' parameter SHOULD NOT be included in
the request. Any 'sidebarByRefInfo' included in the request SHOULD
be ignored by the conference server. The URI for the conference
object for the sidebar MUST be included in the 'confObjID' parameter
in the request. If the specific conferencing user as reflected by
the 'confUserID' in the request is authorized to delete the
conference, the conference server SHOULD delete the conference object
reflected by the 'confObjID' parameter and SHOULD update the
'sidebars-by-ref' element in the conference object from which the
sidebar was originally cloned. The conference server can notify any
conferencing clients that have subscribed to the conference event
package, and are authorized to receive the notifications, of the
deletion of the sidebar.
<!-- 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>
skipping to change at page 38, line 21 skipping to change at page 48, line 24
</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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" minOccurs="0"/>
</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">
skipping to change at page 39, line 4 skipping to change at page 49, line 4
<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"
type="info:conference-type"/> type="info:conference-type"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
Figure 15: Structure of the sidebarByRefRequest and Figure 16: Structure of the sidebarByRefRequest and
sidebarByRefResponse messages sidebarByRefResponse messages
8. A complete example of the CCMP in action 8. 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 is
"Alice" and appears in all requests. The sequence of operations is "Alice" and appears in all requests. The sequence of operations is
as follows: 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 8.1); (Section 8.1);
skipping to change at page 41, line 30 skipping to change at page 51, line 35
. . . .
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>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintsResponse message form the server: 2. blueprintsResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type"> xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.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@meetecho.com</info:uri> <info:uri>xcon:AudioRoom@meetecho.com</info:uri>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room: <info:purpose>Simple Room:
conference room with public access, conference room with public access,
where only audio is available, more users where only audio is available, more users
can talk at the same time can talk at the same time
skipping to change at page 43, line 7 skipping to change at page 53, line 17
only one user can talk at the same time, only one user can talk at the same time,
and the requests for the AudioFloor MUST and the requests for the AudioFloor MUST
be accepted by a Chair. be accepted by a Chair.
</info:purpose> </info:purpose>
</info:entry> </info:entry>
</blueprintsInfo> </blueprintsInfo>
</ccmp:blueprintsResponse> </ccmp:blueprintsResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 16: Getting blueprints from the server Figure 17: Getting blueprints from the server
8.2. Alice gets detailed information about a specific blueprint 8.2. Alice gets detailed information about a specific blueprint
This section illustrates the second transaction in the overall flow. This section illustrates the second transaction in the overall flow.
In this case, Alice, who now knows the XCON-URIs of the blueprints In this case, Alice, who now knows the XCON-URIs of the blueprints
available at the server, makes a drill-down query, in the form of a available at the server, makes a drill-down query, in the form of a
CCMP "blueprintRequest" message, to get detailed information about CCMP "blueprintRequest" message, to get detailed information about
one of them (the one called with XCON-URI one of them (the one called with XCON-URI
"xcon:AudioRoom@meetecho.com"). The picture shows such transaction. "xcon:AudioRoom@meetecho.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 |
| - responseCode: success | | - responseCode: 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
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type"> xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID> <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:blueprintRequest>
<operation>retrieve</operation> <operation>retrieve</operation>
</ccmp:blueprintRequest> <ccmp:blueprintRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. blueprintResponse message form the server: 2. blueprintResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?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">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID> <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <operation>retrieve</operation>
<confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:blueprintResponse> <ccmp:blueprintResponse>
<blueprintInfo entity="AudioRoom"> <blueprintInfo entity="xcon:AudioRoom@meetecho.com">
<info:conference-description> <info:conference-description>
<info:display-text>AudioRoom</info:display-text> <info:display-text>AudioRoom</info:display-text>
<info:maximum-user-count>2</info:maximum-user-count> <info:maximum-user-count>2</info:maximum-user-count>
<info:available-media> <info:available-media>
<info:entry label="audioLabel"> <info:entry label="audioLabel">
<info:type>audio</info:type> <info:type>audio</info:type>
</info:entry> </info:entry>
</info:available-media> </info:available-media>
</info:conference-description> </info:conference-description>
<info:users> <info:users>
skipping to change at page 45, line 4 skipping to change at page 55, line 14
<xcon:floor-request-handling>confirm <xcon:floor-request-handling>confirm
</xcon:floor-request-handling> </xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="audioLabel"></xcon:floor> <xcon:floor id="audioLabel"></xcon:floor>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</blueprintInfo> </blueprintInfo>
</ccmp:blueprintResponse> </ccmp:blueprintResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 17: Getting info about a specific blueprint
Figure 18: Getting info about a specific blueprint
8.3. Alice creates a new conference through a cloning operation 8.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@meetecho.com", for which she just having XCON-URI "xcon:AudioRoom@meetecho.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
skipping to change at page 45, line 30 skipping to change at page 55, line 41
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@meetecho.com" blueprint: "xcon:AudioRoom@meetecho.com" blueprint:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP confRequest message | | CCMP confRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:AudioRoom@meetecho.com | | - 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 |
| - responseCode: success | | - responseCode: success |
| - confInfo: newConfInfo | | - confInfo: newConfInfo |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confObjID>xcon:AudioRoom@meetecho.com</confObjID> <confObjID>xcon:AudioRoom@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:confRequest>
<operation>create</operation> <operation>create</operation>
</ccmp:confRequest> <ccmp:confRequest/>
</ccmpRequest> </ccmpRequest>
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message from the server: 2. confResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse <ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@meetecho.com"> <confInfo entity="xcon:8977794@meetecho.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
New conference by Alice cloned from AudioRoom New conference by Alice cloned from AudioRoom
</info:display-text> </info:display-text>
<info:conf-uris> <info:conf-uris>
<info:entry> <info:entry>
<info:uri> <info:uri>
skipping to change at page 47, line 25 skipping to change at page 57, line 39
confirm</xcon:floor-request-handling> confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy> <xcon:conference-floor-policy>
<xcon:floor id="11"/> <xcon:floor id="11"/>
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</confInfo> </confInfo>
</ccmp:confResponse> </ccmp:confResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 18: Creating a new conference by cloning a blueprint Figure 19: Creating a new conference by cloning a blueprint
8.4. Alice updates conference information 8.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.
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: xcon:8977794@meetecho.com | | - confObjId: 897779 |
| - Operation: update | | - operation: update |
| - confInfo: conf456Updates | | - confInfo: conf456Updates |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP confResponse message | | CCMP confResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:89.. | | - confObjId: 8977794 |
| - operation: update |
| - responseCode: success | | - responseCode: success |
| - confInfo: (null) | | - confInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. confRequest message: 1. confRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest <ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type"> xsi:type="ccmp:ccmp-conf-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:confRequest>
<operation>update</operation> <operation>update</operation>
<ccmp:confRequest>
<confInfo entity="xcon:8977794@meetecho.com"> <confInfo entity="xcon:8977794@meetecho.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>
skipping to change at page 49, line 7 skipping to change at page 59, line 21
2. confResponse message form the server: 2. confResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 19: Updating conference information Figure 20: Updating conference information
8.5. Alice inserts a list of users in the conference object 8.5. Alice inserts a list of users in the conference object
This section illustrates the fifth transaction in the overall flow. This section illustrates the fifth transaction in the overall flow.
Alice modifies the <allowed-users-list> under the <users> element in Alice modifies the <allowed-users-list> under the <users> element in
the document associated with the conference she created. To the the document associated with the conference she created. To the
purpose, she exploits the "usersRequest" message provided by the purpose, she exploits the "usersRequest" message provided by the
CCMP. The picture below shows the transaction. CCMP. The picture below shows the transaction.
Alice updates information about the list of users to whom access to Alice updates information about the list of users to whom access to
the conference is permitted: the conference is permitted:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP usersRequest message | | CCMP usersRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:8977794@meetecho.com | | - confObjId: 8977794 |
| - Operation: update | | - operation: update |
| - usersInfo: usersUpdates | | - usersInfo: usersUpdates |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP usersResponse message | | CCMP usersResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:89.. | | - confObjId: 8977794 |
| - operation: update |
| - responseCode: success | | - responseCode: success |
| - usersInfo: (null) | | - usersInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. usersRequest message: 1. usersRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type"> xsi:type="ccmp:ccmp-users-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:usersRequest>
<operation>update</operation> <operation>update</operation>
<ccmp:usersRequest>
<usersInfo> <usersInfo>
<xcon:allowed-users-list> <xcon:allowed-users-list>
<xcon:target method="dial out" <xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/> uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer" <xcon:target method="refer"
uri="tel:+390817683823"/> uri="tel:+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>
skipping to change at page 50, line 38 skipping to change at page 61, line 8
2. usersResponse message form the server: 2. usersResponse message form the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<operation>update</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confResponse/> <ccmp:confResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 20: Updating the list of allowed users for the conference Figure 21: Updating the list of allowed users for the conference
'xcon:8977794@meetecho.com' 'xcon:8977794@meetecho.com'
8.6. Alice joins the conference 8.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
skipping to change at page 51, line 25 skipping to change at page 61, line 38
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: xcon:8977794@meetecho.com | | - confObjId: 8977794 |
| - Operation: create | | - operation: create |
| - userInfo: AliceUserInfo | | - userInfo: AliceUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userResponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:89.. | | - confObjId: 8977794 |
| - operation: create |
| - responseCode: success | | - responseCode: success |
| - userInfo: (null) | | - userInfo: (null) |
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
1. userRequest message: 1. userRequest message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-confUser-request-message-type"> xsi:type="ccmp:ccmp-confUser-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:confUserRequest>
<operation>create</operation> <operation>create</operation>
<userInfo entity="Alice"> <ccmp:confUserRequest>
<userInfo entity="xcon-userid:Alice@meetecho.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Alice83@example.com mailto:Alice83@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/> <info:endpoint entity="sip:alice_789@example.com"/>
</userInfo> </userInfo>
skipping to change at page 52, line 31 skipping to change at page 62, line 48
2. userResponse message form 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-confUser-response-message-type"> xsi:type="ccmp:ccmp-confUser-response-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<operation>create</operation>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<ccmp:confUserResponse/> <ccmp:confUserResponse/>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 21: Alice joins the conference through the CCMP Figure 22: Alice joins the conference through the CCMP
8.7. Alice adds a new user to the conference 8.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.
skipping to change at page 53, line 18 skipping to change at page 63, line 34
void <userInfo> element, whose "entity" attribute has been set by the void <userInfo> element, whose "entity" attribute has been set by the
server to the value of the newly created conference user id. server to the value of the newly created conference user id.
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: xcon:8977794@meetecho.com | | - confObjId: 8977794 |
| - Operation: create | | - operation: create |
| - usersInfo: CiccioUserInfo | | - usersInfo: CiccioUserInfo |
|------------------------------------------------------>| |------------------------------------------------------>|
| | | |
| CCMP userresponse message | | CCMP userResponse message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjId: xcon:89.. | | - confObjId: 8977794 |
| - operation: create |
| - responseCode: success | | - responseCode: success |
| - usersInfo: (not null!)| | - usersInfo: (not null!)|
|<------------------------------------------------------| |<------------------------------------------------------|
| | | |
. . . .
. . . .
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 53, line 43 skipping to change at page 64, line 17
1. "third party" userRequest message from Alice: 1. "third party" userRequest message from Alice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-confUser-request-message-type"> xsi:type="ccmp:ccmp-confUser-request-message-type">
<confObjID>xcon:8977794@meetecho.com</confObjID> <confObjID>xcon:8977794@meetecho.com</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:confUserRequest>
<operation>create</operation> <operation>create</operation>
<ccmp:confUserRequest>
<userInfo> <userInfo>
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:ciccio@pernacchio.com mailto:ciccio@pernacchio.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@pernacchio.com"/>
skipping to change at page 54, line 25 skipping to change at page 64, line 45
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-confUser-response-message-type"> xsi:type="ccmp:ccmp-confUser-response-message-type">
<confObjID>8977794</confObjID> <confObjID>8977794</confObjID>
<confUserID>Alice</confUserID> <confUserID>xcon-userid:Alice@meetecho.com</confUserID>
<ccmp:response-code>success</ccmp:response-code> <ccmp:response-code>success</ccmp:response-code>
<operation>create</operation>
<ccmp:confUserResponse> <ccmp:confUserResponse>
<confUserInfo entity="bn90ujbkj"> <confUserInfo entity="xcon-userid:bn90ujbkj@meetecho.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:ciccio@pernacchio.com mailto:ciccio@pernacchio.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@pernacchio.com"/>
</confUserInfo> </confUserInfo>
</ccmp:confUserResponse> </ccmp:confUserResponse>
</ccmpResponse> </ccmpResponse>
</ccmp:ccmpResponse> </ccmp:ccmpResponse>
Figure 22: Alice adds a new user to the conference through the CCMP Figure 23: Alice adds a new user to the conference through the CCMP
9. Locating a Conference Control Server 9. Locating a Conference Control Server
If a conference control client is not pre-configured to use a If a conference control client is not pre-configured to use a
specific conference control server for the requests, the client MUST specific conference control server for the requests, the client MUST
first discover the conference control server before it can send any first discover the conference control server before it can send any
requests. The result of the discovery process, is the address of the requests. The result of the discovery process, is the address of the
server supporting conferencing. In this document, the result is an server supporting conferencing. In this document, the result is an
http: or https: URI, which identifies a conference server. http: or https: URI, which identifies a conference server.
This document proposes the use of DNS to locate the conferencing This document proposes the use of DNS to locate the conferencing
server. U-NAPTR resolution for conferencing takes a domain name as server. U-NAPTR resolution for conferencing takes a domain name as
input and produces a URI that identifies the conferencing server. input and produces a URI that identifies the conferencing server.
This process also requires an Application Service tag and an This process also requires an Application Service tag and an
Application Protocol tag, which differentiate conferencing-related Application Protocol tag, which differentiate conferencing-related
NAPTR records from other records for that domain. NAPTR records from other records for that domain.
Section 12.4.1 defines an Application Service tag of "XCON", which is Section 14.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 12.4.2, is used to identify an XCON server that understands Section 14.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
The NAPTR records in the following example Figure 23 demonstrate the The NAPTR records in the following example Figure 24 demonstrate the
use of the Application Service and Protocol tags. Iterative NAPTR use of the Application Service and Protocol tags. Iterative NAPTR
resolution is used to delegate responsibility for the conferencing resolution is used to delegate responsibility for the conferencing
service from "zonea.example.com." and "zoneb.example.com." to service from "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.com. zonea.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
skipping to change at page 56, line 4 skipping to change at page 67, line 4
IN NAPTR 100 10 "" "XCON:CCMP" ( ; service IN NAPTR 100 10 "" "XCON:CCMP" ( ; service
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service IN NAPTR 100 10 "u" "XCON:CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex "!*.!https://confs.example.com/!" ; regex
. ; replacement . ; replacement
) )
Figure 23: Sample XCON:CCMP Service NAPTR Records Figure 24: Sample XCON:CCMP Service NAPTR Records
Details for the "XCON" Application Service tag and the "CCMP" Details for the "XCON" Application Service tag and the "CCMP"
Application Protocol tag are included in Section 12.4. Application Protocol tag are included in Section 14.4.
10. XML Schema 10. Managing Notifications
In cases where the conference control client uses SIP [RFC3261] as
the signaling protocol to participate in the conference, SIP event
notification can be used. This would REQUIRE the conference control
client to implement the Conference event package for XCON
[I-D.ietf-xcon-event-package]. This is the default mechanism for
conferencing clients as is SIP for signaling per the XCON Framework
[RFC5239].
In the case where the interface to the conference server is entirely
web based, there is a common mechanism for web-based systems that
could be used - a "call back". With this mechanism, the conference
client provides the conference server with an HTTP URL which is
invoked when a change occurs. This is a common implementation
mechanism for e-commerce. This works well in the scenarios whereby
the conferencing client is a web server that provides the graphical
HTML user interface and uses CCMP as the backend interface to the
conference server. And, this model can co-exist with the SIP event
notification model. PC-based clients behind NATs could provide a SIP
event URI, whereas web servers would probably find the HTTP model
much easier to program. The details of this approach are out of
scope for the CCMP per se, thus the expectation is that a future
specification will document this solution.
11. HTTP Transport
This section describes the use of HTTP [RFC2616] and HTTP Over TLS
[RFC2818] as transport mechanisms for the CCMP protocol, which a
conforming conference Server and Conferencing client MUST support.
Although CCMP uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a
conferencing server may not a fully compliant HTTP server. It is
intended that a conference server can easily be built using an HTTP
server with extensibility mechanisms, and that a conferencing client
can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options
the full HTTP protocol offers.
A conferencing client that conforms to this specification SHOULD NOT
be required to support HTTP authentication [RFC2617] or cookies
[RFC2965]. Because the conferencing client and the conference server
may have a prior relationship, the conference server SHOULD NOT
require a conferencing client to authenticate, either using the above
HTTP authentication methods or TLS client authentication.
A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content-
Type and Accept header fields, the conference server SHOULD fail the
request, returning a 406 (not acceptable) response. CCMP responses
SHOULD include a Content-Length header.
Conferencing clients MUST NOT use the "Expect" header or the "Range"
header in CCMP requests. The conference server MAY return 501 (not
implemented) errors if either of these HTTP features are used. In
the case that the conference server receives a request from the
conferencing client containing a If-* (conditional) header, the
conference server SHOULD return a 412 (precondition failed) response.
The POST method is the only method REQUIRED for CCMP. If a
conference server chooses to support GET or HEAD, it SHOULD consider
the kind of application doing the GET. Since a conferencing client
only uses a POST method, the GET or HEAD MUST be either an escaped
URL (e.g., somebody found a URL in protocol traces or log files and
fed it into their browser) or somebody doing testing/ debugging. The
conference server could provide information in the HELD response
indicating that the URL corresponds to a conference server and only
responds to CCMP POST requests or the conference server could instead
try to avoid any leak of information by returning a very generic HTTP
error message such as 404 (not found).
The conference server populates the HTTP headers of responses so that
they are consistent with the contents of the message. In particular,
the "CacheControl" header SHOULD be set to disable caching of any
conference information by HTTP intermediaries. Otherwise, there is
the risk of stale information and/or the unauthorized disclosure of
the information. The HTTP status code MUST indicate a 2xx series
response for all CCMP Response and Error messages.
The conference server MAY redirect a CCMP request. A conferencing
client MUST handle redirects, by using the Location header provided
by the server in a 3xx response. When redirecting, the conferencing
client MUST observe the delay indicated by the Retry-After header.
The conferencing client MUST authenticate the server that returns the
redirect response before following the redirect. A conferencing
client SHOULD authenticate the conference server indicated in a
redirect.
The conference server SHOULD support persistent connections and
request pipelining. If pipelining is not supported, the conference
server MUST NOT allow persistent connections. The conference server
MUST support termination of a response by the closing of a
connection.
Implementations of CCMP that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between the conference control client and the
conference control server. The conferencing client MUST implement
the server authentication method described in HTTPS [RFC2818]. The
device uses the URI obtained during conference server discovery to
authenticate the server. The details of this authentication method
are provided in section 3.1 of HTTPS [RFC2818]. When TLS is used,
the conferencing client SHOULD fail a request if server
authentication fails.
12. Security Considerations
As identified in the XCON framework [RFC5239], there are a wide
variety of potential attacks related to conferencing, due to the
natural involvement of multiple endpoints and the capability to
manipulate the data on the conference server using CCMP. Examples of
attacks include the following: an endpoint attempting to listen to
conferences in which it is not authorized to participate, an endpoint
attempting to disconnect or mute other users, and theft of service by
an endpoint in attempting to create conferences it is not allowed to
create.
The following summarizes the security considerations for CCMP:
1. The client MUST determine the proper conference server. The
conference server discovery is described in .
2. The client MSUT connect to the proper conference server. The
mechanisms for addressing this security consideration are
described in Section 12.1.
3. The protocol MUST support a confidentiality and integrity
mechanism. As described in Section 11, implementations of CCMP
MUST implement the HTTP transport over TLS [RFC2818].
4. There are security issues associated with the authorization to
perform actions on the conferencing system to invoke specific
capabilities. A conference server SHOULD ensure that only
authorized entities can manipulate the conference data. The
mechanisms for addressing this security consideration are
described in Section 12.2.
5. The privacy and security of the identity of a user in the
conference MUST be assured. The mechanisms to ensure the
security and privacy of identity are discussed in Section 12.3.
6. A final issue is related to Denial of Service (DoS) attacks on
the conferencing server itself. In order to minimize the
potential for DoS attacks, it is RECOMMENDED that conferencing
systems require user authentication and authorization for any
client participating in a conference. This can be accomplished
through the use of the mechanisms described in Section 12.2, as
well as by using the security mechanisms associated with the
specific signaling (e.g., SIPS) and media protocols (e.g., SRTP).
12.1. Assuring that the Proper Conferencing Server has been contacted
When the CCMP transaction is conducted using TLS [RFC5246], the
conference server can authenticate its identity, either as a domain
name or as an IP address, to the conference client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). With the use of HTTP as a
transport for CCMP, this is exactly the authentication described by
TLS [RFC2818]. If the client has external information as to the
expected identity or credentials of the proper conference server
(e.g., a certificate fingerprint), these checks MAY be omitted. Any
implementation of CCMP MUST be capable of being transacted over TLS
so that the client can request the above authentication, and a
conference server implementation MUST include this feature. Note
that in order for the presented certificate to be valid at the
client, the client must be able to validate the certificate. In
particular, the validation path of the certificate must end in one of
the client's trust anchors, even if that trust anchor is the
conference server certificate itself.
12.2. User Authentication and Authorization
Many policy authorization decisions are based on the identity of the
user or the role that a user may have. The conferencing server MUST
implement mechanisms for authentication of users to validate their
identity. There are several ways that a user might authenticate its
identity to the system. For users joining a conference using one of
the call signaling protocols, the user authentication mechanisms for
the specific protocol can be used. For the case of users joining the
conference using the CCMP, TLS is RECOMMENDED.
The XCON Framework [RFC5239] provides an overview of other
authorization mechanisms. In the cases where a user is authorized
via multiple mechanisms, it is RECOMMENDED that the conference server
correlate the authorization of the CCMP interface with other
authorization mechanisms - e.g., PSTN users that join with a PIN and
control the conference using CCMP. When a conference server presents
the identity of authorized users, it MAY provide information about
the way the identity was proven or verified by the system. A
conference server can also allow a completely unauthenticated user
into the system - this information SHOULD also be communicated to
interested parties.
Once a user is authenticated and authorized through the various
mechanisms available on the conference server, the conference server
MUST allocate a conference user identifier (XCON-USERID) and SHOULD
associate the XCON-USERID with any signaling specific user
identifiers that were used for authentication and authorization.
This XCON-USERID can be provided to a specific user through the
conference notification interface and MUST be provided to users that
interact with the conferencing system using the CCMP (i.e., in the
appropriate CCMP response messages). This conference user identifier
is REQUIRED for any subsequent operations on the conference object.
12.3. Security and Privacy of Identity
An overview of the REQUIRED privacy and anonymity for users of a
conferencing system are provided in the XCON Framework [RFC5239].
The security of the identity in the form of the XCON-USERID is
provided in the CCMP protocol through the use of TLS.
The conference server SHOULD provide mechanisms to ensure the privacy
of the XCON-USERID. This is accomplished by the conference client
manipulation of the "provide-anonymity" element defined in the XCON
data model ([I-D.ietf-xcon-common-data-model]. The "provide-
anonymity" element controls the degree to which a user reveals their
identity. The conference client MUST set the "provide-anonymity"
element to "hidden" if the user does not want other participants to
even be aware that there is an additional participant in the
conference. The conference client MUST set the "provide-anonymity"
field to "private" the user wants to be entirely "anonymous" (i.e.,
other participants are aware that there is another participant, but
have no information as to their identity). The conference client
MUST set the "provide-anonymity" field to "semi-private" if their
identity is only to be revealed to other participants or users that
have a higher level authorization (e.g., a conferencing system can be
configured such that an administrator can see all users). To provide
the required privacy, the conference client SHOULD include the
"provide-anonymity" element in the "confInfo" parameter in a CCMP
confRequest message with an "update" or "create" operation or in the
"userInfo" parameter in a CCMP userRequest message with an "update"
or "create" operation, to ensure the user is provided the appropriate
level of privacy. If the "provide-anonymity" element is not included
in the conference object, then other users can see the participant's
identity.
13. XML Schema
This section provides the XML schema definition of the "application/ This section provides the XML schema definition of the "application/
ccmp+xml" format. ccmp+xml" format.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp" targetNamespace="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:tns="urn:ietf:params:xml:ns:xcon:ccmp"
skipping to change at page 58, line 8 skipping to change at page 75, line 8
<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" <xs:complexType abstract="true"
name="ccmp-request-message-type"> name="ccmp-request-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="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- blueprintsRequest --> <!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type"> <xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/> <xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 58, line 38 skipping to change at page 75, line 42
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- blueprintRequestType --> <!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" /> <xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType"> <xs:complexType name="blueprintRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="blueprintInfo" <xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" 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:complexContent> </xs:complexContent>
skipping to change at page 59, line 21 skipping to change at page 76, line 23
</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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="confInfo" <xs:element name="confInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" 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>
skipping to change at page 59, line 40 skipping to change at page 76, line 40
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"> <xs:extension base="tns:ccmp-request-message-type">
<xs:sequence> <xs:sequence>
<xs:element ref="usersRequest"/> <xs:element ref="usersRequest"/>
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- usersRequestType --> <!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType"/> <xs:element name="usersRequest" type="usersRequestType"/>
<xs:complexType name="usersRequestType"> <xs:complexType name="usersRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="usersInfo" <xs:element name="usersInfo"
type="info:users-type" minOccurs="0" /> type="info:users-type" minOccurs="0" />
</xs:sequence> </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>
skipping to change at page 60, line 20 skipping to change at page 77, line 20
</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="operation"
type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="userInfo" <xs:element name="userInfo"
type="info:user-type" type="info:user-type" minOccurs="0" />
minOccurs="0" />
</xs:sequence> </xs:sequence>
</xs:complexType> </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:sequence>
<xs:element ref="sidebarsByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
</xs:sequence>
</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:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/>
</xs:sequence>
</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>
skipping to change at page 61, line 43 skipping to change at page 78, line 4
<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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByValInfo" <xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" 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">
skipping to change at page 62, line 30 skipping to change at page 78, line 35
</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="operation" type="operationType"
minOccurs="1" maxOccurs="1" />
<xs:element name="sidebarByRefInfo" <xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/> type="info:conference-type" 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="0" maxOccurs="1" /> minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string" <xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:element name="operation" minOccurs="0"
maxOccurs="1" />
<xs:element ref="response-code" minOccurs="1" <xs:element ref="response-code" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
</xs:sequence> </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" type="blueprintsResponseType" /> <xs:element name="blueprintsResponse"
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">
skipping to change at page 63, line 38 skipping to change at page 79, line 44
<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" type="blueprintResponseType" /> <xs:element name="blueprintResponse"
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>
skipping to change at page 64, line 12 skipping to change at page 80, line 17
<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" minOccurs="0"/> type="info:uris-type" 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">
skipping to change at page 64, line 34 skipping to change at page 80, line 40
<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" <xs:element name="confInfo"
type="info:conference-type"/> 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>
skipping to change at page 67, line 51 skipping to change at page 84, line 7
<xs:simpleType name="response-codeType"> <xs:simpleType name="response-codeType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="success"/> <xs:enumeration value="success"/>
<xs:enumeration value="pending"/> <xs:enumeration value="pending"/>
<xs:enumeration value="modified"/> <xs:enumeration value="modified"/>
<xs:enumeration value="badRequest"/> <xs:enumeration value="badRequest"/>
<xs:enumeration value="unauthorized"/> <xs:enumeration value="unauthorized"/>
<xs:enumeration value="forbidden"/> <xs:enumeration value="forbidden"/>
<xs:enumeration value="objectNotFound"/> <xs:enumeration value="objectNotFound"/>
<xs:enumeration value="userNotFound"/>
<xs:enumeration value="invalidConfUserID"/>
<xs:enumeration value="passwordRequired"/>
<xs:enumeration value="invalidPassword"/>
<xs:enumeration value="forbiddenDeleteParent"/> <xs:enumeration value="forbiddenDeleteParent"/>
<xs:enumeration value="forbiddenChangeProtected"/> <xs:enumeration value="forbiddenChangeProtected"/>
<xs:enumeration value="requestTimeout"/> <xs:enumeration value="requestTimeout"/>
<xs:enumeration value="serverInternalError"/> <xs:enumeration value="serverInternalError"/>
<xs:enumeration value="notImplemented"/> <xs:enumeration value="notImplemented"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- operationType --> <!-- operationType -->
<xs:simpleType name="operationType"> <xs:simpleType name="operationType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/> <xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/> <xs:enumeration value="create"/>
<xs:enumeration value="update"/> <xs:enumeration value="update"/>
<xs:enumeration value="delete"/> <xs:enumeration value="delete"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Figure 24 Figure 25
11. Managing notifications
This section is still "Under Construction" and currently contains
some views on handling notifications.
One proposal is to stick with SIP notification. Another alternative,
which is commonly done in other web-based systems, is a "call back",
i.e., the CCMP client provides the conference server with an HTTP URL
which is invoked when a change occurs. This is apparently how most
credit card shopping cards work, having implemented one. This works
well for our scenario since a CCMP "client" is likely to be a web
server that provides the graphical HTML user interface and uses CCMP
as the backend to talk to the conference server. In that particular
case, there doesn't seem to be a problem of having both models. PC-
based clients behind NATs would provide a SIP event URI, web servers
would probably find the HTTP model much easier to program with.
Another option being considered is BOSH
(http://xmpp.org/extensions/xep-0124.html), which is basically an
extension to XMPP designed with the following aim: "...a transport
protocol that emulates a bidirectional stream between two entities
(such as a client and a server) by efficiently using multiple
synchronous HTTP request/response pairs without requiring the use of
polling or asynchronous chunking."
A final consideration (under discussion only) is basic XMPP.
12. IANA Considerations 14. IANA Considerations
This document registers a new XML namespace, a new XML schema, and This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema. This document also registers the the MIME type for the schema. This document also registers the
"XCON" Application Service tag and the "CCMP" Application Protocol "XCON" Application Service tag and the "CCMP" Application Protocol
tag. This document also defines registries for the CCMP operation tag. This document also defines registries for the CCMP operation
types and response codes. types and response codes.
12.1. URN Sub-Namespace Registration 14.1. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
""urn:ietf:params:xml:ns:xcon:ccmp"". ""urn:ietf:params:xml:ns:xcon:ccmp"".
URI: "urn:ietf:params:xml:ns:xcon:ccmp" URI: "urn:ietf:params:xml:ns:xcon:ccmp"
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Registrant Contact: IETF, XCON working group, (xcon@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
XML: XML:
skipping to change at page 70, line 43 skipping to change at page 85, line 43
<body> <body>
<h1>Namespace for CCMP Messages</h1> <h1>Namespace for CCMP Messages</h1>
<h2>urn:ietf:params:xml:ns:xcon:ccmp</h2> <h2>urn:ietf:params:xml:ns:xcon:ccmp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
12.2. XML Schema Registration 14.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:xcon:ccmp URI: urn:ietf:params:xml:schema:xcon:ccmp
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.barnes@nortel.com). Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 10 of this document. Section 13 of this document.
12.3. MIME Media Type Registration for 'application/ccmp+xml' 14.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type. This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: ccmp+xml MIME subtype name: ccmp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML for which the
UTF-8. default is UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2. 3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related conference control. Some of the data could protocol data related conference control. Some of the data could
be considered private and thus should be protected. be considered private and thus should be protected.
Interoperability considerations: This content type provides a basis Interoperability considerations: None.
for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Centralized Conferencing Applications which use this media type: Centralized Conferencing
control clients and servers. control clients and servers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
skipping to change at page 72, line 15 skipping to change at page 87, line 15
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml. described there also apply to application/ccmp+xml.
12.4. DNS Registrations 14.4. DNS Registrations
Section 12.4.1 defines an Application Service tag of "XCON", which is Section 14.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in particular domain. The Application Protocol tag "CCMP", defined in
Section 12.4.2, is used to identify an XCON server that understands Section 14.4.2, is used to identify an XCON server that understands
the CCMP protocol. the CCMP protocol.
12.4.1. Registration of a Location Server Application Service Tag 14.4.1. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag This section registers a new S-NAPTR/U-NAPTR Application Service tag
for XCON, as mandated by [RFC3958]. for XCON, as mandated by [RFC3958].
Application Service Tag: XCON Application Service Tag: XCON
Intended usage: Identifies a server that supports centralized Intended usage: Identifies a server that supports centralized
conferencing. conferencing.
Defining publication: RFCXXXX Defining publication: RFCXXXX
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
12.4.2. Registration of a Location Server Application Protocol Tag for 14.4.2. Registration of a Location Server Application Protocol Tag for
HELD HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the CCMP protocol, as mandated by [RFC3958]. for the CCMP protocol, as mandated by [RFC3958].
Application Service Tag: CCMP Application Service Tag: CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Intended Usage: Identifies the Centralized Conferencing (XCON)
Manipulation Protocol. Manipulation Protocol.
Applicable Service Tag(s): XCON Applicable Service Tag(s): XCON
Terminal NAPTR Record Type(s): U Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX Defining Publication: RFCXXXX
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
12.5. CCMP Protocol Registry 14.5. CCMP Protocol Registry
This document requests that the IANA create a new registry for the This document requests that the IANA create a new registry for the
CCMP protocol including an initial registry for operation types and CCMP protocol including an initial registry for operation types and
response codes. response codes.
12.5.1. CCMP Message Types 14.5.1. CCMP Message Types
The CCMP messages are described in Section 7 and defined in the XML The CCMP messages are described in Section 7 and defined in the XML
schema in Section 10. The following summarizes the requested schema in Section 13. The following summarizes the requested
registry: registry:
Related Registry: CCMP Message Types Registry Related Registry: CCMP Message Types Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New CCMP message types are Registration/Assignment Procedures: New CCMP message types are
allocated on a specification required basis. allocated on a specification required basis.
skipping to change at page 74, line 33 skipping to change at page 89, line 33
request to manipulate the "users" element in the conference request to manipulate the "users" element in the conference
object. object.
sidebarRequest: This sidebarRequest is used to retrieve the sidebarRequest: This sidebarRequest is used to retrieve the
information related to a sidebar or to create, change or delete a information related to a sidebar or to create, change or delete a
specific sidebar. specific sidebar.
sidebarResponse: This sidebarResponse indicates the result of the sidebarResponse: This sidebarResponse indicates the result of the
sidebarRequest. sidebarRequest.
12.5.2. CCMP Response Codes 14.5.2. CCMP Response Codes
The following summarizes the requested registry for CCMP Response The following summarizes the requested registry for CCMP Response
codes: codes:
Related Registry: CCMP Response Code Registry Related Registry: CCMP Response Code Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: New response codes are allocated Registration/Assignment Procedures: New response codes are allocated
skipping to change at page 75, line 23 skipping to change at page 90, line 23
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/
create' operation, in the case of a third-party invite, when the
'confUserId' (contained in the 'entity' attribute of the
'userInfo' parameter) of the user to be added is unknown.
invalidConfUserID: This code is returned in the case of requests in
which the 'confUserID' of the sender is invalid.
invalidPassword: This code is returned in response to all requests
wishing to access/manipulate a password-protected conference
object, when the 'password' parameter contained in the request is
wrong.
passwordRequired: This code is returned in response to all requests
wishing to access/manipulate a password-protected conference
object, when the 'password' parameter is missing in the request.
operationNotAllowed: This code indicates that the specific operation operationNotAllowed: This code indicates that the specific operation
is not allowed for the target conference object (e.g.., due to is not allowed for the target conference object (e.g.., due to
policies, etc.) policies, etc.)
deleteFailedParent: This code indicates that the conferencing system deleteFailedParent: This code indicates that the conferencing system
cannot delete the specific conference object because it is a cannot delete the specific conference object because it is a
parent for another conference object. parent for another conference object.
changeFailedProtected: This code indicates that the target changeFailedProtected: This code indicates that the target
conference object cannot be changed (e.g., due to policies, roles, conference object cannot be changed (e.g., due to policies, roles,
skipping to change at page 76, line 5 skipping to change at page 92, line 5
requestTimeout: This code indicates that the request could not be requestTimeout: This code indicates that the request could not be
processed within a reasonable time, with the time specific to a processed within a reasonable time, with the time specific to a
conferencing system implementation. conferencing system implementation.
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.
13. Security Considerations 15. Acknowledgments
Access to conference control functionality needs to be tightly
controlled to keep attackers from disrupting conferences, adding
themselves to conferences or engaging in theft of services. In the
case of a RESTful implementation of the CCMP, implementors need to
deploy standard HTTP authentication and authorization mechanisms.
Since conference information may contain secrets such as participant
lists and dial-in codes, all conference control information SHOULD be
carried over TLS (HTTPS).
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 and Tobia Castaldi. Special thanks go to Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean Duddy
Roberta Presta for her invaluable contribution to this document. and Oscar Novo. Special thanks go to Roberta Presta for her
Roberta has worked on the specification of the CCMP protocol at the invaluable contribution to this document. Roberta has worked on the
University of Napoli for the preparation of her Master thesis. She specification of the CCMP protocol at the University of Napoli for
has also implemented the CCMP prototype used for the trials and from the preparation of her Master thesis. She has also implemented the
which the dumps provided in Section 8 have been extracted. CCMP prototype used for the trials and from which the dumps provided
in Section 8 have been extracted.
15. Changes since last Version 16. 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 02 and the 03:
1. Clarified that the confUserID is optional in the generic CCMP
request message for a userRequest with a "create" operation.
2. Added responseCode (error cases) handling - a general section for
each of the operations (as part of CCMP Response Code section),
so we don't need to re-iterate for each of the messages and
message specific cases as appropriate (e.g., deleteParentFailed,
modified)
3. Moved "operation" parameter to be part of general CCMP request
and response messages since it is used for more than one message
type. And, it's necessary to define before describing the
operation specific responseCode handling.
4. Revised normative statements for the various protocol messages
and operations - e.g., messages MUST include parameter x versus
SHOULD, adding text for handling of cases where the SHOULDs don't
happen and the SHOULD NOTs do. Added descriptions for all the
operation types, as appropriate.
5. Added lots more details in the security section.
6. Added section to describe requirements for an HTTP implementation
to support CCMP.
7. Updated section on notifications - XCON SIP event package is
default, with some discussion of an HTTP callback mechanism
(ffs).
8. Misc editorial nits: qualifying message names in the text, etc.,
etc., etc.
The following summarizes the changes between the WG 01 and the 02: The following summarizes the changes between the WG 01 and the 02:
1. Changed the basic approach from REST to HTTP as a transport. 1. Changed the basic approach from REST to HTTP as a transport.
This impacted most of the document - i.e., a major rewrite - 02 This impacted most of the document - i.e., a major rewrite - 02
is closer to 00 than the 01. is closer to 00 than the 01.
2. Added full example based on prototype. 2. Added full example based on prototype.
The following summarizes the changes between the WG 00 and the 01: The following summarizes the changes between the WG 00 and the 01:
skipping to change at page 79, line 5 skipping to change at page 95, line 5
6. Added placeholders for Notifications and Role Based Access 6. Added placeholders for Notifications and Role Based Access
Control. Control.
7. Added some text for discovery using DNS (including IANA 7. Added some text for discovery using DNS (including IANA
registrations) registrations)
8. Updated References: updated XCON FW RFC, SOAP/W3C moved to 8. Updated References: updated XCON FW RFC, SOAP/W3C moved to
informational section. informational section.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., Even, R., and J. Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
Urpalainen, "Conference Information Data Model for "Conference Information Data Model for Centralized
Centralized Conferencing (XCON)", Conferencing (XCON)", draft-ietf-xcon-common-data-model-13
draft-ietf-xcon-common-data-model-12 (work in progress), (work in progress), April 2009.
October 2008.
16.2. Informative References 17.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004.
[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", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[I-D.royer-calsch-xcal]
Royer, D., "iCalendar in XML Format (xCal-Basic)",
draft-royer-calsch-xcal-03 (work in progress),
October 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Hadley, M., Mendelsohn, N., Nielsen, H., and Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and
J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide M. Hadley, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
skipping to change at page 83, line 9 skipping to change at page 99, line 9
Change: Either HTTP PATCH or HTTP POST could be used to change the Change: Either HTTP PATCH or HTTP POST could be used to change the
conference object identified by the XCON-URI. conference object identified by the XCON-URI.
Delete: HTTP DELETE could be used to delete conference objects and Delete: HTTP DELETE could be used to delete conference objects and
parameters within conference objects identified by the XCON-URI. parameters within conference objects identified by the XCON-URI.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd
Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Simon Pietro Romano Simon Pietro Romano
University of Napoli University of Napoli
 End of changes. 201 change blocks. 
565 lines changed or deleted 1188 lines changed or added

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