draft-ietf-xcon-ccmp-11.txt   draft-ietf-xcon-ccmp-12.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: April 29, 2011 NS-Technologies Expires: August 20, 2011 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
October 26, 2010 February 16, 2011
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-11 draft-ietf-xcon-ccmp-12
Abstract Abstract
The Centralized Conferencing Manipulation Protocol (CCMP) allows an The Centralized Conferencing Manipulation Protocol (CCMP) allows an
XCON conferencing system client to create, retrieve, change, and XCON conferencing system client to create, retrieve, change, and
delete objects that describe a centralized conference. CCMP is a delete objects that describe a centralized conference. CCMP is a
means to control basic and advanced conference features such as means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and conference state and capabilities, participants, relative roles, and
details. CCMP is a state-less, XML-based, client server protocol details. CCMP is a state-less, XML-based, client server protocol
that carries, in its request and response messages, conference that carries, in its request and response messages, conference
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2011. This Internet-Draft will expire on August 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. XCON Conference Control System Architecture . . . . . . . . . 5 3. XCON Conference Control System Architecture . . . . . . . . . 5
3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7 3.1. Conference Objects . . . . . . . . . . . . . . . . . . . 7
3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7 3.2. Conference Users . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 4.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
4.2. Implementation Approach . . . . . . . . . . . . . . . . . 11 4.2. Data Management . . . . . . . . . . . . . . . . . . . . . 10
5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Data Model Compliance . . . . . . . . . . . . . . . . . . 11
5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 12 4.4. Implementation Approach . . . . . . . . . . . . . . . . . 12
5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 14 5. CCMP messages . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 16 5.1. CCMP Request Message Type . . . . . . . . . . . . . . . . 13
5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 19 5.2. CCMP Response Message Type . . . . . . . . . . . . . . . 15
5.3.2. confsRequest and confsResponse . . . . . . . . . . . 21 5.3. Detailed messages . . . . . . . . . . . . . . . . . . . . 17
5.3.3. blueprintRequest and blueprintResponse . . . . . . . 22 5.3.1. blueprintsRequest and blueprintsResponse . . . . . . 20
5.3.4. confRequest and confResponse . . . . . . . . . . . . 24 5.3.2. confsRequest and confsResponse . . . . . . . . . . . 22
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 28 5.3.3. blueprintRequest and blueprintResponse . . . . . . . 23
5.3.6. userRequest and userResponse . . . . . . . . . . . . 30 5.3.4. confRequest and confResponse . . . . . . . . . . . . 25
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 35 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 37 5.3.6. userRequest and userResponse . . . . . . . . . . . . 31
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 39 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 41 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38
5.3.11. extendedRequest and extendedResponse . . . . . . . . 44 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 46 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 49 5.3.11. extendedRequest and extendedResponse . . . . . . . . 45
6. A complete example of the CCMP in action . . . . . . . . . . 52 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47
6.1. Alice retrieves the available blueprints . . . . . . . . 53 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50
6. A complete example of the CCMP in action . . . . . . . . . . 53
6.1. Alice retrieves the available blueprints . . . . . . . . 54
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 55 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 57 operation . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4. Alice updates conference information . . . . . . . . . . 60 6.4. Alice updates conference information . . . . . . . . . . 61
6.5. Alice inserts a list of users in the conference object . 62 6.5. Alice inserts a list of users in the conference object . 63
6.6. Alice joins the conference . . . . . . . . . . . . . . . 63 6.6. Alice joins the conference . . . . . . . . . . . . . . . 65
6.7. Alice adds a new user to the conference . . . . . . . . . 65 6.7. Alice adds a new user to the conference . . . . . . . . . 67
6.8. Alice asks for the CCMP server capabilities . . . . . . . 68 6.8. Alice asks for the CCMP server capabilities . . . . . . . 69
6.9. Alice exploits a CCMP server extension . . . . . . . . . 70 6.9. Alice exploits a CCMP server extension . . . . . . . . . 72
7. Locating a Conference Control Server . . . . . . . . . . . . 73 7. Locating a Conference Control Server . . . . . . . . . . . . 74
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 74 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 75 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 78 contacted . . . . . . . . . . . . . . . . . . . . . . . . 80
10.2. User Authentication and Authorization . . . . . . . . . . 79 10.2. User Authentication and Authorization . . . . . . . . . . 80
10.3. Security and Privacy of Identity . . . . . . . . . . . . 80 10.3. Security and Privacy of Identity . . . . . . . . . . . . 81
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 80 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 82
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 98 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 100
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 99 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 101
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 99 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 101
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 100 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 102
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 100 Application Service Tag . . . . . . . . . . . . . . . 103
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 101 Application Protocol Tag for CCMP . . . . . . . . . . 103
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 101 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 103
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 101 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 103
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 102 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 105
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
14. Changes since last Version . . . . . . . . . . . . . . . . . 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 14.1. Normative References . . . . . . . . . . . . . . . . . . 107
15.1. Normative References . . . . . . . . . . . . . . . . . . 105 14.2. Informative References . . . . . . . . . . . . . . . . . 108
15.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . 107 considered for CCMP . . . . . . . . . . . . . . . . 109
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 107 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 109
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 108 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 110
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
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 9, line 12 skipping to change at page 9, line 12
specifically conceived to provide users with the necessary means for specifically conceived to provide users with the necessary means for
the creation, retrieval, modification and deletion of conference the creation, retrieval, modification and deletion of conference
objects. CCMP is also state-less, which means implementations can objects. CCMP is also state-less, which means implementations can
safely handle transactions independently from each other. safely handle transactions independently from each other.
Conference-related information is encapsulated into CCMP messages in Conference-related information is encapsulated into CCMP messages in
the form of XML documents or XML document fragments compliant with the form of XML documents or XML document fragments compliant with
the XCON data model representation. the XCON data model representation.
Section 4.1 specifies the basic operations that can create, retrieve, Section 4.1 specifies the basic operations that can create, retrieve,
modify and delete conference-related information in a centralized modify and delete conference-related information in a centralized
conference. The core set of objects manipulated in the CCMP protocol conference. The core set of objects manipulated in the CCMP includes
includes conference blueprints, the conference object, users, and conference blueprints, the conference object, users, and sidebars.
sidebars.
Each operation in the protocol model, as summarized in Section 4.1 is
atomic and either succeeds or fails as a whole. The conference
server must ensure that the operations are atomic in that the
operation invoked by a specific conference client completes prior to
another client's operation on the same conference object. While the
details for this data locking functionality are out of scope for the
CCMP protocol specification and are implementation specific for a
conference server, some core functionality for ensuring the integrity
of the data is provided by the CCMP as described in Section 4.2.
While the XML documents that are carried in the CCMP need to comply
with the XCON data model, there are situations in which the values
for mandatory elements are unknown by the client. The mechanism for
ensuring compliance with the data model in these cases is described
in Section 4.3.
CCMP has been conceived as completely independent from underlying CCMP has been conceived as completely independent from underlying
protocols, which means that there can be different ways to carry CCMP protocols, which means that there can be different ways to carry CCMP
messages across the network, from a conferencing client to a messages across the network, from a conferencing client to a
conferencing server. The specification recommends the use of HTTP as conferencing server. The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies. Implementation details and CCMP responses in HTTP 200 OK replies. This implementation
are presented in Section 4.2 approach is further described in Section 4.4.
4.1. Protocol Operations 4.1. Protocol Operations
The main operations provided by CCMP belong in four general The main operations provided by CCMP belong in four general
categories: categories:
create: for the creation of a conference, a conference user, a create: for the creation of a conference, a conference user, a
sidebar, or a blueprint. sidebar, or a blueprint.
retrieve: to get information about the current state of either a retrieve: to get information about the current state of either a
conference object (be it an actual conference or a blueprint, or a conference object (be it an actual conference or a blueprint, or a
sidebar) or a conference user. A retrieve operation can also be sidebar) or a conference user. A retrieve operation can also be
used to obtain the XCON-URIs of the current conferences (active or used to obtain the XCON-URIs of the current conferences (active or
registered) handled by the conferencing server and/or the registered) handled by the conferencing server and/or the
available blueprints. available blueprints.
update: to modify the current features of a specified conference or update: to modify the current features of a specified conference or
conference user. conference user.
delete: to remove from the system a conference object or a delete: to remove from the system a conference object or a
conference user. conference user.
Thus, the main targets of CCMP operations are: Thus, the main targets of CCMP operations are:
o conference objects associated with either active or registered o conference objects associated with either active or registered
conferences, conferences,
o conference objects associated with blueprints, o conference objects associated with blueprints,
o conference objects associated with sidebars, both embedded in the o conference objects associated with sidebars, both embedded in the
main conference (i.e. <entry> elements in <sidebars-by-value>) and main conference (i.e. <entry> elements in <sidebars-by-value>) and
external to it (i.e. whose xcon-uris are included in the <entry> external to it (i.e. whose xcon-uris are included in the <entry>
elements of <sidebars-by-ref>), elements of <sidebars-by-ref>),
o <user> elements associated with conference users, o <user> elements associated with conference users,
o the list of XCON-URIs related to conferences and blueprints o the list of XCON-URIs related to conferences and blueprints
available at the server, for which only retrieval operations are available at the server, for which only retrieval operations are
allowed. allowed.
Each operation in the protocol model is atomic and either succeeds or 4.2. Data Management
fails as a whole. The conference server must ensure that the
operations are atomic in that the operation invoked by a specific In order to ensure the integrity of the data, the conference server
conference client completes prior to another client's operation on first checks all the parameters, before making any changes to the
the same conference object. The details for this data locking internal representation of the conference object. For example, it
functionality are out of scope for the CCMP protocol specification would be undesirable to change the <subject> of the conference, but
and are implementation specific for a conference server. Thus, the then detect an invalid URI in one of the <service-uris> and abort the
conference server first checks all the parameters, before making any remaining updates. Also, since multiple clients can modify the same
changes to the internal representation of the conference object. For conference objects, conference clients should first obtain the
example, it would be undesirable to change the <subject> of the current object from the conference server and then update the
conference, but then detect an invalid URI in one of the <service- relevant data elements in the conference object prior to invoking a
uris> and abort the remaining updates. Also, since multiple clients specific operation on the conference server.
can modify the same conference objects, conference clients should
first obtain the current object from the conference server and then In order to effectively manage modifications to conference data, a
update the relevant data elements in the conference object prior to versioning approach is provided by the CCMP. Specifically, each
invoking a specific operation on the conference server. In order to conference object is associated with a version number indicating the
effectively manage modifications to conference data, a versioning most up to date view of the conference at the server's side. The
approach is provided by the CCMP. Specifically, each conference version number is reported to the clients when answering their
object is associated with a version number indicating the most up to requests. A client willing to make modifications to a conference
date view of the conference at the server's side. The version number object has to send an update message to the server. If the
is reported to the clients when answering their requests. A client modifications are all successfully applied, the server sends back to
willing to make modifications to a conference object has to send an the client a "200" response which also carries information about the
update message to the server. If the modifications are all current server-side version of the modified object. With this
successfully applied, the server sends back to the client a "200" approach, a client working on version "X" of a conference object that
response which also carries information about the current server-side finds a "200" response with a version number which is "X+1" can be
version of the modified object. With this approach, a client working sure that the version it was aware of was the most up to date. On
on version "X" of a conference object that finds a "200" response the other hand, if the "200" response contains a version which is at
with a version number which is "X+1" can be sure that the version it least "X+2", the client can detect that the object that has been
was aware of was the most up to date. On the other hand, if the modified at the server's side was more up to date than the one it was
"200" response contains a version which is at least "X+2", the client working upon. This is clearly due to the effect of concurrent
can detect that the object that has been modified at the server's modification requests issued by independent clients. Hence, for the
side was more up to date than the one it was working upon. This is sake of having available the latest version of the modified object,
clearly due to the effect of concurrent modification requests issued the client can send to the conference server a further "retrieve"
by independent clients. Hence, for the sake of having available the request. In the case that a copy of the conference object is not
latest version of the modified object, the client can send to the returned to the client as part of the update response message, the
conference server a further "retrieve" request. In the case that a client can always obtain a copy through an ad-hoc "retrieve" message.
copy of the conference object is not returned to the client as part
of the update response message, the client can always obtain a copy
through an ad-hoc "retrieve" message.
Based on the above considerations, all CCMP response messages Based on the above considerations, all CCMP response messages
containing a conference document (or a fragment of it) MUST contain a containing a conference document (or a fragment of it) MUST contain a
"version" parameter. The "version" parameter is not REQUIRED for "version" parameter. The "version" parameter is not REQUIRED for
requests, since it represents useless information for the server: as requests, since it represents useless information for the server: as
long as the required modifications can be applied to the target long as the required modifications can be applied to the target
conference object with no conflicts, the server does not care whether conference object with no conflicts, the server does not care whether
the client has stored an up to date view of the information. the client has stored an up to date view of the information.
However, a client subscribed to the XCON event package However, a client subscribed to the XCON event package
[I-D.ietf-xcon-event-package] notifications about conference object [I-D.ietf-xcon-event-package] notifications about conference object
modifications, will always have the most up to date version of that modifications, will always have the most up to date version of that
object. object.
A final consideration concerns the relation between the CCMP and the 4.3. Data Model Compliance
main entities it manages, i.e. conference objects. Such objects have
to be compliant with the XCON data-model, which identifies some
elements/attributes as mandatory. From the CCMP standpoint this can
become a problem in cases of client-initiated operations, like the
creation/update of conference objects. In such cases, not all of the
mandatory data can be known in advance to the client issuing a CCMP
request. As an example, a client has no means to know, at the time
it issues a conference creation request, the XCON-URI that the server
will assign to the yet-to-be-created conference and hence it is not
able to appropriately fill with that value the mandatory "entity"
attribute of the conference document contained in the request. To
solve this kind of issues, the CCMP will fill all mandatory data
model fields, for which no value is available at the client at the
time the request is constructed, with fake values in the form of
wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental
index initialized to a value of 1). Upon reception of the mentioned
kinds of requests, the server will: (i) generate the proper
identifier(s); (ii) produce a response in which the received fake
identifier(s) carried in the request has (have) been replaced by the
newly created one(s). With this approach we maintain compatibility
with the data model requirements, at the same time allowing for
client-initiated manipulation of conference objects at the server's
side (which is, by the way, one of the main goals for which the CCMP
protocol has been conceived at the outset).
4.2. Implementation Approach The XCON data model identifies some elements/attributes as mandatory.
Since the XML documents carried in the CCMP need to be compliant with
the XCON data model, there can be a problem in cases of client-
initiated operations, like the creation/update of conference objects.
In such cases, not all of the mandatory data can be known in advance
to the client issuing a CCMP request. As an example, a client has no
means to know, at the time it issues a conference creation request,
the XCON-URI that the server will assign to the yet-to-be-created
conference and hence it is not able to appropriately fill with that
value the mandatory "entity" attribute of the conference document
contained in the request. To solve this issue, the CCMP client fills
all mandatory data model fields, for which no value is available at
the time the request is constructed, with fake values in the form of
a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a
unique numeric index for each data model field for which the value is
unknown. This form of wildcard string is chosen, rather than the use
of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for
X, to simplify processing at the server. The values of
AUTO_GENERATE_X are only unique within the context of the specific
request. The fake AUTO_GENERATE_X values MUST be within the value
part of an attribute/element (e.g., <userinfo entity=
"xcon-userid:AUTO_GENERATE_1@example.com">).
When the server receives requests containing values in the form of
AUTO_GENERATE_X, the server does the following:
(a) Generates the proper identifier for each instance of
AUTO_GENERATE_X in the document. If an instance of
AUTO_GENERATE_X is not within the value part of the attribute/
element, the server MUST respond with an error of 400 Bad
Request. In cases where AUTO_GENERATE_X appears only in the
user part of a URI (i.e., in the case of XCON-USERIDs or XCON-
URIs), the server needs to ensure that the domain name is one
that is within the server's domain of responsibility. If the
domain name is NOT within the server's domain of responsibility,
then the server MUST return a 500 Server Internal Error. The
server MUST replace each instance of a specific wildcard field
(e.g., AUTO_GENERATE_1) with the same identifier. The
identifiers MUST be unique for each instance of AUTO_GENERATE_X
within the same XML document received in the request - e.g., the
value that replaces AUTO_GENERATE_1 MUST NOT be the same as the
value that replaces AUTO_GENERATE_2. Note that the values that
replace the instances of AUTO_GENERATE_X are not the same across
all conference objects - e.g., different values can be used to
replace AUTO_GENERATE_1 in two different documents.
(b) Sends a response in which all values of AUTO_GENERATE_X received
in the request has (have) been replaced by the newly created
one(s).
With this approach compatibility with the data model requirements is
maintained, while allowing for client-initiated manipulation of
conference objects at the server's side which is one of the main
goals of the CCMP protocol.
4.4. Implementation Approach
There have been a number of different proposals as to the most There have been a number of different proposals as to the most
suitable implementation solution for the CCMP. A non-exhaustive suitable implementation solution for the CCMP. A non-exhaustive
summary of the most interesting ones is provided in Appendix A. The summary of the most interesting ones is provided in Appendix A. The
solution for the CCMP defined in this document is viewed as a good solution for the CCMP defined in this document is viewed as a good
compromise amongst the most notable past candidates and is referred compromise amongst the most notable past candidates and is referred
to as "HTTP single-verb transport plus CCMP body". With this to as "HTTP single-verb transport plus CCMP body". With this
approach, CCMP is able to take advantage of existing HTTP approach, CCMP is able to take advantage of existing HTTP
functionality. As with SOAP, the CCMP uses a "single HTTP verb" for functionality. As with SOAP, the CCMP uses a "single HTTP verb" for
transport (i.e. a single transaction type for each request/response transport (i.e. a single transaction type for each request/response
skipping to change at page 12, line 45 skipping to change at page 13, line 47
subject: An optional parameter containing username and password of subject: An optional parameter containing username and password of
the client registered at the conferencing system. Each user who the client registered at the conferencing system. Each user who
subscribes to the conferencing system is assumed to be equipped subscribes to the conferencing system is assumed to be equipped
with those credentials and SHOULD enclose them in each CCMP with those credentials and SHOULD enclose them in each CCMP
request she issues. These fields can be used to control that the request she issues. These fields can be used to control that the
user sending the CCMP request has the authority to perform the user sending the CCMP request has the authority to perform the
entailed operation. The same fields can also be exploited to entailed operation. The same fields can also be exploited to
carry out other Authorization, Authentication and Accounting (AAA) carry out other Authorization, Authentication and Accounting (AAA)
procedures. procedures.
confUserID: An optional parameter containing the XCON-USERID of the confUserID: An optional parameter containing the XCON-USERID of the
client. The XCON-USERID is used to identify any conferencing client. The XCON-USERID is used to identify any conferencing
client within the context of the conferencing system and it is client within the context of the conferencing system and it is
assinged by the conferencing server at each conferencing client assigned by the conferencing server at each conferencing client
who interacts with it. The "confUserID" parameter is REQUIRED in who interacts with it. The "confUserID" parameter is REQUIRED in
the CCMP request and response messages with the exception of the the CCMP request and response messages with the exception of the
case of a user who has no XCON-USERID and who wants to enter, via case of a user who has no XCON-USERID and who wants to enter, via
CCMP, a conference whose identifier is known. In such case, a CCMP, a conference whose identifier is known. In such case, a
side-effect of the request is that the user is provided with an side-effect of the request is that the user is provided with an
appropriate XCON-USERID. An example of the above mentioned case appropriate XCON-USERID. An example of the above mentioned case
will be provided in Section 5.3.6. will be provided in Section 5.3.6.
confObjID: An optional parameter containing the XCON-URI of the confObjID: An optional parameter containing the XCON-URI of the
target conference object. target conference object.
operation: An optional parameter refining the type of specialized operation: An optional parameter refining the type of specialized
request message. The "operation" parameter is REQUIRED in all request message. The "operation" parameter is REQUIRED in all
requests except for the "blueprintsRequest" and "confsRequest" requests except for the "blueprintsRequest" and "confsRequest"
specialized messages. specialized messages.
conference-password: An optional parameter that MUST be inserted in conference-password: An optional parameter that MUST be inserted in
all requests whose target conference object is password-protected all requests whose target conference object is password-protected
(as per the <conference-password> element in (as per the <conference-password> element in
[I-D.ietf-xcon-common-data-model]). [I-D.ietf-xcon-common-data-model]).
specialized request message: This is specialization of the generic specialized request message: This is specialization of the generic
request message (e.g., blueprintsRequest), containing parameters request message (e.g., blueprintsRequest), containing parameters
that are dependent on the specific request sent to the server. A that are dependent on the specific request sent to the server. A
specialized request message MUST be included in the CCMP request specialized request message MUST be included in the CCMP request
message. The details for the specialized messages and associated message. The details for the specialized messages and associated
parameters are provided in Section 5.3. parameters are provided in Section 5.3.
<!-- Definition of CCMP Request --> <!-- Definition of CCMP Request -->
<xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpRequest" type="ccmp-request-type" />
skipping to change at page 31, line 30 skipping to change at page 32, line 32
depending upon the manner in which the user was created: depending upon the manner in which the user was created:
o Conferencing client with an XCON-USERID adds itself to the o Conferencing client with an XCON-USERID adds itself to the
conference: In this case, the "userInfo" parameter MAY be included conference: In this case, the "userInfo" parameter MAY be included
in the userRequest. The "userInfo" parameter MUST contain a in the userRequest. The "userInfo" parameter MUST contain a
<user> element (compliant with the XCON data model) and the <user> element (compliant with the XCON data model) and the
"entity" attribute MUST be set to a value which represents the "entity" attribute MUST be set to a value which represents the
XCON-USERID of the user initiating the request. No additional XCON-USERID of the user initiating the request. No additional
parameters beyond those previously described are required in the parameters beyond those previously described are required in the
userResponse message, in the case of a "response-code" of "200". userResponse message, in the case of a "response-code" of "200".
o Conferencing client acts on behalf of a third user whose XCON- o Conferencing client acts on behalf of a third user whose XCON-
USERID is known: in this case, the "userInfo" parameter MUST be USERID is known: in this case, the "userInfo" parameter MUST be
included in the userRequest. The "userInfo" parameter MUST included in the userRequest. The "userInfo" parameter MUST
contain a <user> element and the "entity" attribute value MUST be contain a <user> element and the "entity" attribute value MUST be
set to the XCON-USERID of the third user in question. No set to the XCON-USERID of the third user in question. No
additional parameters beyond those previously described are additional parameters beyond those previously described are
required in the userResponse message, in the case of a "response- required in the userResponse message, in the case of a "response-
code" of "200". code" of "200".
o A conferencing client who has no XCON-USERID and who wants to o A conferencing client who has no XCON-USERID and who wants to
enter, via CCMP, a conference whose identifier is known. In such enter, via CCMP, a conference whose identifier is known. In this
case, a side-effect of the request is that the user is provided case, a side-effect of the request is that the user is provided
with a new XCON-USERID (created by the server) carried inside the with a new XCON-USERID (created by the server) carried inside the
"confUserID" parameter of the response. This is the only case in "confUserID" parameter of the response. This is the only case in
which a CCMP request can be valid though carrying a void which a CCMP request can be valid though carrying a void
"confUserID" parameter. A "userInfo" parameter MUST be enclosed "confUserID" parameter. A "userInfo" parameter MUST be enclosed
in the request, providing at least a contact URI of the joining in the request, providing at least a contact URI of the joining
client, in order to let the focus instigate the signaling phase client, in order to let the focus instigate the signaling phase
needed to add her to the conference. The mandatory "entity" needed to add her to the conference. The mandatory "entity"
attribute of the "userInfo" parameter in the request is filled attribute of the "userInfo" parameter in the request MUST be
with a dummy value recognizable on the server side, so to conform filled with a fake value with the user part of the XCON-USERID
to the rules contained in the XCON data model XML schema. The containing a value of AUTO_GENERATE_X as described in Section 4.3,
involved messages (userRequest and userResponse) in such case to conform to the rules contained in the XCON data model XML
schema. The messages (userRequest and userResponse) in this case
should look like the following: should look like the following:
Request fields: Request fields:
confUserID=null; confUserID=null;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
userInfo= userInfo=
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<endpoint entity="sip:GHIL345@example.com"> <endpoint entity="sip:GHIL345@example.com">
... ...
Response fields (in case of success): Response fields (in case of success):
confUserID=user345; confUserID=user345;
confObjID=confXYZ; confObjID=confXYZ;
operation=create; operation=create;
response-code=200; response-code=200;
userInfo=null; //or the entire userInfo object userInfo=null; //or the entire userInfo object
Figure 11: userRequest and userResponse in the absence of an xcon- Figure 11: userRequest and userResponse in the absence of an xcon-
userid userid
o Conferencing client is unaware of the XCON-USERID of a third user: o Conferencing client is unaware of the XCON-USERID of a third user:
In this case, the XCON-USERID in the request "confUserID" is the In this case, the XCON-USERID in the request "confUserID" is the
sender's one and the "entity" attribute of the attached userInfo sender's one and the "entity" attribute of the attached userInfo
is filled with the pre-defined fake value is filled with the fake value
"xcon-userid:AUTO_GENERATE@example.com". The XCON-USERID for the "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for
third user MUST be returned to the client issuing the request in the third user MUST be returned to the client issuing the request
the "entity" attribute of the response "userInfo" parameter, if in the "entity" attribute of the response "userInfo" parameter, if
the "response-code" is "200". This scenario is intended to the "response-code" is "200". This scenario is intended to
support both the case where a brand new conferencing system user support both the case where a brand new conferencing system user
is added to a conference by a third party (i.e. a user who is not is added to a conference by a third party (i.e. a user who is not
yet provided with an XCON-USERID) and the case where the CCMP yet provided with an XCON-USERID) and the case where the CCMP
client issuing the request does not know the to-be-added user's client issuing the request does not know the to-be-added user's
XCON-USERID (which means such an identifier could already exist on XCON-USERID (which means such an identifier could already exist on
the server's side for that user). In this last case, the the server's side for that user). In this last case, the
conferencing server is in charge of avoiding XCON-URI duplicates conferencing server is in charge of avoiding XCON-URI duplicates
for the same conferencing client, looking at key fields in the for the same conferencing client, looking at key fields in the
request provided "userInfo" parameter, such as the signalling URI: request provided "userInfo" parameter, such as the signalling URI:
skipping to change at page 46, line 21 skipping to change at page 47, line 23
The "optionsResponse" returns, in the appropriate <options> field, a The "optionsResponse" returns, in the appropriate <options> field, a
list of the supported CCMP messages as defined in this specification. list of the supported CCMP messages as defined in this specification.
These messages are in the form of a list, <standard-message-list> These messages are in the form of a list, <standard-message-list>
including each of the supported messages as reflected by <standard- including each of the supported messages as reflected by <standard-
message> elements. The "optionsResponse" message also allows for an message> elements. The "optionsResponse" message also allows for an
<extended-message-list>, which is a list of additional message types <extended-message-list>, which is a list of additional message types
in the form of <extended-message-list> elements that are currently in the form of <extended-message-list> elements that are currently
undefined, to allow for future extensibility. The following undefined, to allow for future extensibility. The following
information is provided for both types of messages: information is provided for both types of messages:
o <name> (mandatory): in case of standard messages, it can be one of o <name> (mandatory): in case of standard messages, it can be one of
the ten standard message names defined in this document (i.e. the ten standard message names defined in this document (i.e.
"blueprintsRequest", "confsRequest", etc.). In case of "blueprintsRequest", "confsRequest", etc.). In case of
extensions, this element MUST carry the same value of the extensions, this element MUST carry the same value of the
<extension-name> inserted in the corresponding extendedRequest/ <extension-name> inserted in the corresponding extendedRequest/
extendedResponse message pair extendedResponse message pair
o <operations> (optional): this field is a list of <operation> o <operations> (optional): this field is a list of <operation>
entries, each representing the CRUD operation supported by the entries, each representing the CRUD operation supported by the
server for the message. If this optional element is absent, the server for the message. If this optional element is absent, the
client SHOULD assume the server is able to handle the entire set client SHOULD assume the server is able to handle the entire set
of CRUD operations or, in case of standard messages, all the of CRUD operations or, in case of standard messages, all the
operations envisioned for that message in this document. operations envisioned for that message in this document.
o <schema-ref> (optional): since all CCMP messages can potentially o <schema-ref> (optional): since all CCMP messages can potentially
contain XML elements not envisioned in the CCMP schema (due to the contain XML elements not envisioned in the CCMP schema (due to the
presence of <any> elements and attributes), a reference to a presence of <any> elements and attributes), a reference to a
proper schema definition specifying such new elements/attributes proper schema definition specifying such new elements/attributes
can also be sent back to the clients by means of such field. If can also be sent back to the clients by means of such field. If
this element is absent, no new elements are introduced in the this element is absent, no new elements are introduced in the
messages further than those explicitly defined in the CCMP messages further than those explicitly defined in the CCMP
specification. specification.
o <description> (optional): human readable information about the o <description> (optional): human readable information about the
related message related message
The only parameter needed in the optionsRequest is the sender The only parameter needed in the optionsRequest is the sender
confUserID, which is mirrored in the homologous parameter of the confUserID, which is mirrored in the homologous parameter of the
corresponding optionsResponse. corresponding optionsResponse.
The <standard-message-list> MUST appear in the optionsResponse and The CCMP server MUST include the <standard-message-list> containing
MUST NOT be void, since a CCMP server MUST be able to handle at least at least one <operation> element in the optionsResponse, since a CCMP
one of the standard messages in at least one of the envisioned server is required to be able to handle at least one of the standard
operations, i.e. the aforementioned list MUST carry at least one messages for at least one of the operations.
<standard-message> containing at least one <operation> element.
<!-- optionsRequest --> <!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type"> <xs:complexType name="ccmp-options-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>
<!-- optionsResponse --> <!-- optionsResponse -->
skipping to change at page 49, line 13 skipping to change at page 50, line 23
<xs:enumeration value="sidebarByValRequest"/> <xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/> <xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/> <xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- operations-type --> <!-- operations-type -->
<xs:complexType name="operations-type"> <xs:complexType name="operations-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operation-type" <xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/> minOccurs="1" maxOccurs="4"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
Figure 18: Structure of the optionsRequest and optionsResponse Figure 18: Structure of the optionsRequest and optionsResponse
messages messages
5.4. CCMP Response Codes 5.4. CCMP Response Codes
skipping to change at page 66, line 4 skipping to change at page 67, line 18
6.7. Alice adds a new user to the conference 6.7. Alice adds a new user to the conference
This section illustrates the seventh and last transaction in the This section illustrates the seventh and last transaction in the
overall flow. Alice uses the CCMP to add a new conferencing system overall flow. Alice uses the CCMP to add a new conferencing system
user, Ciccio, to the conference. This "third-party" request is user, Ciccio, to the conference. This "third-party" request is
realized through a "userRequest/create" message containing, in the realized through a "userRequest/create" message containing, in the
"userInfo" parameter, a <user> element compliant with the XCON data "userInfo" parameter, a <user> element compliant with the XCON data
model representation. Notice that such element includes information model representation. Notice that such element includes information
about Ciccio's Address of Records, as well as his current end-point, about Ciccio's Address of Records, as well as his current end-point,
but has a fake "entity" attribute, "AUTO_GENERATE@example.com" as but has a fake "entity" attribute, "AUTO_GENERATE_1@example.com" as
discussed in Section 4, since the XCON-USERID is initially unknown to discussed in Section 4.3, since the XCON-USERID is initially unknown
Alice. Thus, the conference server is in charge of generating a new to Alice. Thus, the conference server is in charge of generating a
XCON-USERID for the user Alice indicates (i.e, Ciccio), and returning new XCON-USERID for the user Alice indicates (i.e, Ciccio), and
it in the "entity" attribute of the "userInfo" parameter carried in returning it in the "entity" attribute of the "userInfo" parameter
the response, as well as adding the user to the conference. The carried in the response, as well as adding the user to the
picture below shows the transaction. conference. The picture below shows the transaction.
Alice adds user "Ciccio" to the conference by issuing a third-party Alice adds user "Ciccio" to the conference by issuing a third-party
"userRequest/create" message to the server: "userRequest/create" message to the server:
CCMP Client CCMP Server CCMP Client CCMP Server
| | | |
| CCMP userRequest message | | CCMP userRequest message |
| - confUserID: Alice | | - confUserID: Alice |
| - confObjID: 8977794 | | - confObjID: 8977794 |
| - operation: create | | - operation: create |
skipping to change at page 67, line 5 skipping to change at page 68, line 21
<ccmp:ccmpRequest <ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type"> xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<ccmp:userRequest> <ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE@example.com"> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors> <info:associated-aors>
<info:entry> <info:entry>
<info:uri> <info:uri>
mailto:Ciccio@example.com mailto:Ciccio@example.com
</info:uri> </info:uri>
<info:display-text>email</info:display-text> <info:display-text>email</info:display-text>
</info:entry> </info:entry>
</info:associated-aors> </info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/> <info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo> </userInfo>
skipping to change at page 97, line 40 skipping to change at page 99, line 25
<xs:enumeration value="sidebarByValRequest"/> <xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/> <xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/> <xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- operations-type --> <!-- operations-type -->
<xs:complexType name="operations-type"> <xs:complexType name="operations-type">
<xs:sequence> <xs:sequence>
<xs:element name="operation" type="operation-type" <xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/> minOccurs="1" maxOccurs="4"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<!-- extended-message-list-type --> <!-- extended-message-list-type -->
<xs:complexType name="extended-message-list-type"> <xs:complexType name="extended-message-list-type">
<xs:sequence> <xs:sequence>
<xs:element name="extended-message" <xs:element name="extended-message"
skipping to change at page 101, line 42 skipping to change at page 104, line 7
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 12.5.1. CCMP Message Types
The CCMP messages are described in Section 4.1 and defined in the XML The CCMP messages are described in Section 4.1 and defined in the XML
schema in Section 11. The following summarizes the requested schema in Section 11. 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.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.com).
This section pre-registers the following initial CCMP message types: This section pre-registers the following initial CCMP message types:
optionsRequest: Used by a conference control client to query a optionsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of supported conferencing system for its capabilities, in terms of supported
messages (both standard and non-standard). messages (both standard and non-standard).
optionsResponse: The optionsResponse returns a list of CCMP messages optionsResponse: The optionsResponse returns a list of CCMP messages
(both standard and non-standard) supported by the specific (both standard and non-standard) supported by the specific
conference server. conference server.
blueprintsRequest: Used by a conference control client to query a blueprintsRequest: Used by a conference control client to query a
conferencing system for its capabilities, in terms of available conferencing system for its capabilities, in terms of available
conference blueprints. conference blueprints.
blueprintsResponse: The blueprintsResponse returns a list of blueprintsResponse: The blueprintsResponse returns a list of
blueprints supported by the specific conference server. blueprints supported by the specific conference server.
confsRequest: Used by a conference control client to query a confsRequest: Used by a conference control client to query a
conferencing system for its scheduled/active conferences. conferencing system for its scheduled/active conferences.
confsResponse: The "confsResponse" returns the list of the currently confsResponse: The "confsResponse" returns the list of the currently
activated/scheduled conferences at the server. activated/scheduled conferences at the server.
confRequest: The "confRequest" is used to create a conference object confRequest: The "confRequest" is used to create a conference object
and/or to request an operation on the conference object as a and/or to request an operation on the conference object as a
whole. whole.
confResponse: The "confResponse" indicates the result of the confResponse: The "confResponse" indicates the result of the
operation on the conference object as a whole. operation on the conference object as a whole.
userRequest: The "userRequest" is used to request an operation on userRequest: The "userRequest" is used to request an operation on
the "user" element in the conference object. the "user" element in the conference object.
userResponse: The "userResponse" indicates the result of the userResponse: The "userResponse" indicates the result of the
requested operation on the "user" element in the conference requested operation on the "user" element in the conference
object. object.
usersRequest This "usersRequest" is used to manipulate the "users" usersRequest This "usersRequest" is used to manipulate the "users"
element in the conference object, including parameters such as the element in the conference object, including parameters such as the
"allowed-users-list", "join-handling", etc. "allowed-users-list", "join-handling", etc.
usersResponse: This "usersResponse" indicates the result of the usersResponse: This "usersResponse" indicates the result of the
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 12.5.2. CCMP Response Codes
The following summarizes the requested registry for CCMP Response The following summarizes the requested registry for CCMP Response
codes: codes:
Related Registry: CCMP Response Code Registry Related Registry: CCMP Response Code Registry
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC 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
on a first-come/first-serve basis with specification required. on a first-come/first-serve basis with specification required.
Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary Registrant Contact: IETF, XCON working group, (xcon@ietf.org), Mary
Barnes (mary.ietf.barnes@gmail.com). Barnes (mary.ietf.barnes@gmail.com).
This section pre-registers the following thirteen initial response This section pre-registers the following thirteen initial response
codes as described above in Section 4.1: codes as described above in Section 4.1:
200: This code indicates that the request was successfully 200: This code indicates that the request was successfully
processed. processed.
409: This code indicates that a requested "update" cannot be 409: This code indicates that a requested "update" cannot be
successfully completed by the server. An example of such successfully completed by the server. An example of such
situation is when the modification of an object cannot be applied situation is when the modification of an object cannot be applied
due to conflicts arising at the server's side (e.g. because the due to conflicts arising at the server's side (e.g. because the
client version of the object is an obsolete one and the requested client version of the object is an obsolete one and the requested
modifications collide with the up-to-date state of the object modifications collide with the up-to-date state of the object
stored at the server). stored at the server).
400: This code indicates that the request was badly formed in some 400: This code indicates that the request was badly formed in some
fashion. fashion.
401: This code indicates that the user was not authorized for the 401: This code indicates that the user was not authorized for the
specific operation on the conference object. specific operation on the conference object.
403: This code indicates that the specific operation is not valid 403: This code indicates that the specific operation is not valid
for the target conference object. for the target conference object.
404: This code indicates that the specific conference object was not 404: This code indicates that the specific conference object was not
found. found.
420: This code is returned in answer to a "userRequest/create" 420: This code is returned in answer to a "userRequest/create"
operation, in the case of a third-party invite, when the operation, in the case of a third-party invite, when the
"confUserID" (contained in the "entity" attribute of the "confUserID" (contained in the "entity" attribute of the
"userInfo" parameter) of the user to be added is unknown. "userInfo" parameter) of the user to be added is unknown.
421: This code is returned in the case of requests in which the 421: This code is returned in the case of requests in which the
"confUserID" of the sender is invalid. "confUserID" of the sender is invalid.
422: This code is returned in response to all requests wishing to 422: This code is returned in response to all requests wishing to
access/manipulate a password-protected conference object, when the access/manipulate a password-protected conference object, when the
"conference-password" parameter contained in the request is wrong. "conference-password" parameter contained in the request is wrong.
423: This code is returned in response to all requests wishing to 423: This code is returned in response to all requests wishing to
access/manipulate a password-protected conference object, when the access/manipulate a password-protected conference object, when the
"conference-password" parameter is missing in the request. "conference-password" parameter is missing in the request.
424: This code is returned in response whenever the server wants to 424: This code is returned in response whenever the server wants to
authenticate the requestor through the "subject" parameter and authenticate the requestor through the "subject" parameter and
such a parameter is not provided in the request. such a parameter is not provided in the request.
425: This code indicates that the conferencing system cannot delete 425: This code indicates that the conferencing system cannot delete
the specific conference object because it is a parent for another the specific conference object because it is a parent for another
conference object. conference object.
426: This code indicates that the target conference object cannot be 426: This code indicates that the target conference object cannot be
changed (e.g., due to policies, roles, privileges, etc.). changed (e.g., due to policies, roles, privileges, etc.).
510: This code indicates that the request could not be processed 510: This code indicates that the request could not be processed
within a reasonable time, with the time specific to a conferencing within a reasonable time, with the time specific to a conferencing
system implementation. system implementation.
500: This code indicates that the conferencing system experienced 500: This code indicates that the conferencing system experienced
some sort of internal error. some sort of internal error.
501: This code indicates that the specific operation is not 501: This code indicates that the specific operation is not
implemented on that conferencing system. implemented on that conferencing system.
13. Acknowledgments 13. Acknowledgments
The authors appreciate the feedback provided by Dave Morgan, Pierre The authors appreciate the feedback provided by Dave Morgan, Pierre
Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean
Duddy, Oscar Novo, Richard Barnes and Simo Veikkolainen. Special Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage and
thanks go to Roberta Presta for her invaluable contribution to this Peter Reissner. Special thanks go to Roberta Presta for her
document. Roberta has worked on the specification of the CCMP invaluable contribution to this document. Roberta has worked on the
protocol at the University of Napoli for the preparation of her specification of the CCMP protocol at the University of Napoli for
Master thesis. She has also implemented the CCMP prototype used for the preparation of her Master thesis. She has also implemented the
the trials and from which the dumps provided in Section 6 have been CCMP prototype used for the trials and from which the dumps provided
extracted. in Section 6 have been extracted.
14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
The following summarizes the changes between the WG 03 and the 04:
1. Re-organized document based on feedback from Richard Barnes.
2. Editorial clarifications and nits, including those identified by
Richard and Simo Veikkolainen.
The following summarizes the changes between the WG 07 and the 08:
1. Added a new "optionsRequest" message (and related
"optionsResponse" message) to the list of CCMP messages.
2. Clarified discussion about notifications management, by
clarifying they are out of the scope of the present document, but
at the same time providing some pointers to potential ways for
implementing them.
3. Clarified discussion about policies in XCON, by clarifying they
are out of the scope of the present document, but at the same
time providing some pointers to potential ways for implementing
them.
4. Corrected minor typos in the schema.
5. Corrected schema definitions which brought to Unique Particle
Attribution exceptions.
6. Added the newly defined "optionsRequest" and "optionsResponse"
messages to the schema.
7. Misc editorial nits...
The following summarizes the changes between the WG 08 and the 09:
1. Added a section on the extendedRequest/extendedResponse message
pair.
2. Added a section on the optionsRequest/optionsResponse message
pair.
3. Added an example sub-section about the use of the optionsRequest/
optionsResponse message pair.
4. Added an example sub-section about the use of the
extendedRequest/extendedResponse message pair.
5. Updated the schema in order to reflect the latest modifications
and add-ons.
6. Misc editorial nits...
15. References 14. References
15.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 106, line 11 skipping to change at page 108, line 6
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-20 Conferencing (XCON)", draft-ietf-xcon-common-data-model-23
(work in progress), October 2010. (work in progress), February 2011.
15.2. Informative References 14.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
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,
skipping to change at page 106, line 42 skipping to change at page 108, line 37
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2 Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
Part 1: Messaging Framework", World Wide Web Consortium M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
FirstEdition REC-soap12-part1-20030624, June 2003, World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Popescu, V., Smith, V., and B. Pandit, "SOAP Version 1.2 Mendelsohn, N., Hadley, M., Gudgin, M., Moreau, J., and H.
Part 2: Adjuncts", World Wide Web Consortium Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
FirstEdition REC-soap12-part2-20030624, June 2003, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
Appendix A. Appendix A: Other protocol models and transports considered Appendix A. Appendix A: Other protocol models and transports considered
for CCMP for CCMP
The operations on the objects can be implemented in at least two The operations on the objects can be implemented in at least two
different ways, namely as remote procedure calls - using SOAP as different ways, namely as remote procedure calls - using SOAP as
described in Appendix A.1 and by defining resources following a described in Appendix A.1 and by defining resources following a
RESTful architecture Appendix A.2. RESTful architecture Appendix A.2.
 End of changes. 83 change blocks. 
219 lines changed or deleted 269 lines changed or added

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