draft-ietf-xcon-ccmp-12.txt   draft-ietf-xcon-ccmp-13.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: August 20, 2011 NS-Technologies Expires: November 10, 2011 NS-Technologies
S P. Romano S P. Romano
University of Napoli University of Napoli
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
February 16, 2011 May 9, 2011
Centralized Conferencing Manipulation Protocol Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-12 draft-ietf-xcon-ccmp-13
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 August 20, 2011. This Internet-Draft will expire on November 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.3.4. confRequest and confResponse . . . . . . . . . . . . 25 5.3.4. confRequest and confResponse . . . . . . . . . . . . 25
5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29 5.3.5. usersRequest and usersResponse . . . . . . . . . . . 29
5.3.6. userRequest and userResponse . . . . . . . . . . . . 31 5.3.6. userRequest and userResponse . . . . . . . . . . . . 31
5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36 5.3.7. sidebarsByValRequest and sidebarsByValResponse . . . 36
5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38 5.3.8. sidebarByValRequest and sidebarByValResponse . . . . 38
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40 5.3.9. sidebarsByRefRequest and sidebarsByRefResponse . . . 40
5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42 5.3.10. sidebarByRefRequest and sidebarByRefResponse . . . . 42
5.3.11. extendedRequest and extendedResponse . . . . . . . . 45 5.3.11. extendedRequest and extendedResponse . . . . . . . . 45
5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47 5.3.12. optionsRequest and optionsResponse . . . . . . . . . 47
5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50 5.4. CCMP Response Codes . . . . . . . . . . . . . . . . . . . 50
6. A complete example of the CCMP in action . . . . . . . . . . 53 6. A complete example of the CCMP in action . . . . . . . . . . 54
6.1. Alice retrieves the available blueprints . . . . . . . . 54 6.1. Alice retrieves the available blueprints . . . . . . . . 55
6.2. Alice gets detailed information about a specific 6.2. Alice gets detailed information about a specific
blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57 blueprint . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3. Alice creates a new conference through a cloning 6.3. Alice creates a new conference through a cloning
operation . . . . . . . . . . . . . . . . . . . . . . . . 59 operation . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4. Alice updates conference information . . . . . . . . . . 61 6.4. Alice updates conference information . . . . . . . . . . 62
6.5. Alice inserts a list of users in the conference object . 63 6.5. Alice inserts a list of users in the conference object . 63
6.6. Alice joins the conference . . . . . . . . . . . . . . . 65 6.6. Alice joins the conference . . . . . . . . . . . . . . . 65
6.7. Alice adds a new user to the conference . . . . . . . . . 67 6.7. Alice adds a new user to the conference . . . . . . . . . 67
6.8. Alice asks for the CCMP server capabilities . . . . . . . 69 6.8. Alice asks for the CCMP server capabilities . . . . . . . 69
6.9. Alice exploits a CCMP server extension . . . . . . . . . 72 6.9. Alice exploits a CCMP server extension . . . . . . . . . 72
7. Locating a Conference Control Server . . . . . . . . . . . . 74 7. Locating a Conference Control Server . . . . . . . . . . . . 75
8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76 8. Managing Notifications . . . . . . . . . . . . . . . . . . . 76
9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77 9. HTTP Transport . . . . . . . . . . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
10.1. Assuring that the Proper Conferencing Server has been 10.1. Assuring that the Proper Conferencing Server has been
contacted . . . . . . . . . . . . . . . . . . . . . . . . 80 contacted . . . . . . . . . . . . . . . . . . . . . . . . 80
10.2. User Authentication and Authorization . . . . . . . . . . 80 10.2. User Authentication and Authorization . . . . . . . . . . 81
10.3. Security and Privacy of Identity . . . . . . . . . . . . 81 10.3. Security and Privacy of Identity . . . . . . . . . . . . 82
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 82 10.4. Mitigating DoS Attacks . . . . . . . . . . . . . . . . . 83
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 100 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 101 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 101
12.3. MIME Media Type Registration for 'application/ccmp+xml' . 101 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 102
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 102 12.3. MIME Media Type Registration for 'application/ccmp+xml' . 102
12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 103
12.4.1. Registration of a Conference Control Server 12.4.1. Registration of a Conference Control Server
Application Service Tag . . . . . . . . . . . . . . . 103 Application Service Tag . . . . . . . . . . . . . . . 104
12.4.2. Registration of a Conference Control Server 12.4.2. Registration of a Conference Control Server
Application Protocol Tag for CCMP . . . . . . . . . . 103 Application Protocol Tag for CCMP . . . . . . . . . . 104
12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 103 12.5. CCMP Protocol Registry . . . . . . . . . . . . . . . . . 104
12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 103 12.5.1. CCMP Message Types . . . . . . . . . . . . . . . . . 105
12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 105 12.5.2. CCMP Response Codes . . . . . . . . . . . . . . . . . 107
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 109
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 109
14.1. Normative References . . . . . . . . . . . . . . . . . . 107 14.1. Normative References . . . . . . . . . . . . . . . . . . 109
14.2. Informative References . . . . . . . . . . . . . . . . . 108 14.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. Appendix A: Other protocol models and transports Appendix A. Appendix A: Other protocol models and transports
considered for CCMP . . . . . . . . . . . . . . . . 109 considered for CCMP . . . . . . . . . . . . . . . . 111
A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 109 A.1. Using SOAP for the CCMP . . . . . . . . . . . . . . . . . 112
A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 110 A.2. A RESTful approach for the CCMP . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113
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 48 skipping to change at page 4, line 48
survey of the methods that can be used to locate a Conference Control survey of the methods that can be used to locate a Conference Control
Server is provided in Section 7, whereas Section 8 discusses Server is provided in Section 7, whereas Section 8 discusses
potential approaches to notifications management. CCMP transport potential approaches to notifications management. CCMP transport
over HTTP is highlighted in Section 9. Security considerations are over HTTP is highlighted in Section 9. Security considerations are
presented in Section 10. Finally, Section 11 provides the XML presented in Section 10. Finally, Section 11 provides the XML
schema. schema.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
In additon to the terms defined in the Framework for Centralized In additon to the terms defined in the Framework for Centralized
Conferencing [RFC5239], this document uses the following terms and Conferencing [RFC5239], this document uses the following terms and
acronyms: acronyms:
XCON aware client: An XCON conferencing system client which is able XCON aware client: An XCON conferencing system client which is able
to issue CCMP requests. to issue CCMP requests.
First-Party: A request issued by the client to manipulate their own First-Party: A request issued by the client to manipulate their own
conferencing data. conferencing data.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
AUTO_GENERATE_X, the server does the following: AUTO_GENERATE_X, the server does the following:
(a) Generates the proper identifier for each instance of (a) Generates the proper identifier for each instance of
AUTO_GENERATE_X in the document. If an instance of AUTO_GENERATE_X in the document. If an instance of
AUTO_GENERATE_X is not within the value part of the attribute/ AUTO_GENERATE_X is not within the value part of the attribute/
element, the server MUST respond with an error of 400 Bad element, the server MUST respond with an error of 400 Bad
Request. In cases where AUTO_GENERATE_X appears only in the Request. In cases where AUTO_GENERATE_X appears only in the
user part of a URI (i.e., in the case of XCON-USERIDs or XCON- 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 URIs), the server needs to ensure that the domain name is one
that is within the server's domain of responsibility. If the that is within the server's domain of responsibility. If the
domain name is NOT within the server's domain of responsibility, domain name is not within the server's domain of responsibility,
then the server MUST return a 500 Server Internal Error. The then the server MUST return a 427 Invalid Domain Name. The
server MUST replace each instance of a specific wildcard field server MUST replace each instance of a specific wildcard field
(e.g., AUTO_GENERATE_1) with the same identifier. The (e.g., AUTO_GENERATE_1) with the same identifier. The
identifiers MUST be unique for each instance of AUTO_GENERATE_X identifiers MUST be unique for each instance of AUTO_GENERATE_X
within the same XML document received in the request - e.g., the within the same XML document received in the request - e.g., the
value that replaces AUTO_GENERATE_1 MUST NOT be the same as the value that replaces AUTO_GENERATE_1 MUST NOT be the same as the
value that replaces AUTO_GENERATE_2. Note that the values that value that replaces AUTO_GENERATE_2. Note that the values that
replace the instances of AUTO_GENERATE_X are not the same across replace the instances of AUTO_GENERATE_X are not the same across
all conference objects - e.g., different values can be used to all conference objects - e.g., different values can be used to
replace AUTO_GENERATE_1 in two different documents. replace AUTO_GENERATE_1 in two different documents.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
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
pair); this allows decoupling CCMP messages from HTTP messages. pair); this allows decoupling CCMP messages from HTTP messages.
Similarly, as with any RESTful approach, CCMP messages are inserted Similarly, as with any RESTful approach, CCMP messages are inserted
directly in the body of HTTP messages, thus avoiding any unnecessary directly in the body of HTTP messages, thus avoiding any unnecessary
processing and communication burden associated with further processing and communication burden associated with further
intermediaries. With this approach, no modification to the CCMP intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport messages/operations is required to use a different transport
protocol. protocol. The remainder of this document focuses on the selected
approach.
The remainder of this document focuses on the selected approach. The The CCMP protocol inserts XML-based CCMP requests into the body of
CCMP protocol inserts XML-based CCMP requests into the body of HTTP HTTP POST operations and retrieves responses from the body of HTTP
POST operations and retrieves responses from the body of HTTP "200 "200 OK" messages. Most CCMP commands can pend indefinitely, thus
OK" messages. CCMP messages have a MIME-type of "application/ increasing the potential that pending requests can continue to
ccmp+xml", which appears inside the "Content-Type" and "Accept" increase when a server is receiving more requests than it can process
fields of HTTP requests and responses. The XML documents in the CCMP within a specific time period. In this case a server SHOULD return a
messages MUST be encoded in UTF-8. This specification follows the 510 response code to the pending requests. In addition, to mitigate
recommendations and conventions described in [RFC3023], including the the situation clients MUST NOT wait indefinitely for a response and
naming convention of the type ('+xml' suffix) and the usage of the MUST implement a timer (in the range of seconds) such that when it
'charset' parameter. The 'charset' parameter MUST be included with expires, the client MUST close the connection. Note, that there may
the XML document. Section 9 provides the complete requirements for be cases where a response message is lost and a request has been
an HTTP implementation to support the CCMP. successful (e.g., user added to a conference), yet the client will be
unaware. However, as described in Section 4.2, there is a versioning
mechanism for the conference objects, thus there is a mechanism for
the conference object stored by the client to be brought up to date.
CCMP messages have a MIME-type of "application/ccmp+xml", which
appears inside the "Content-Type" and "Accept" fields of HTTP
requests and responses. The XML documents in the CCMP messages MUST
be encoded in UTF-8. This specification follows the recommendations
and conventions described in [RFC3023], including the naming
convention of the type ('+xml' suffix) and the usage of the 'charset'
parameter. The 'charset' parameter MUST be included with the XML
document. Section 9 provides the complete requirements for an HTTP
implementation to support the CCMP.
5. CCMP messages 5. CCMP messages
CCMP messages are either requests or responses. The general CCMP CCMP messages are either requests or responses. The general CCMP
request message is defined in Section 5.1. The general CCMP response request message is defined in Section 5.1. The general CCMP response
message is defined in Section 5.2. The details of the specific message is defined in Section 5.2. The details of the specific
message type which is carried in the CCMP request and response message type which is carried in the CCMP request and response
messages are described in Section 5.3. CCMP response codes are messages are described in Section 5.3. CCMP response codes are
listed in Section 5.4 listed in Section 5.4
skipping to change at page 51, line 43 skipping to change at page 51, line 43
425 Forbidden Delete Parent: Cancel operation failed since the 425 Forbidden Delete Parent: Cancel operation failed since the
target object is a parent of child objects which depend on it, or target object is a parent of child objects which depend on it, or
because it effects, based on the "parent-enforceable" mechanism, because it effects, based on the "parent-enforceable" mechanism,
the corresponding element in a child object. the corresponding element in a child object.
426 Forbidden Change Protected: Update refused by the server because 426 Forbidden Change Protected: Update refused by the server because
the target element cannot be modified due to its implicit the target element cannot be modified due to its implicit
dependence on the value of a parent object ("parent-enforceable" dependence on the value of a parent object ("parent-enforceable"
mechanism). mechanism).
427 Invalid Domain Name: The domain name in an AUTO_GENERATE_X
instance in the conference object is not within the CCMP server's
domain of responsibility.
500 Server Internal Error: The server cannot complete the required 500 Server Internal Error: The server cannot complete the required
service due to a system internal error. service due to a system internal error.
501 Not Implemented: Operation envisaged in the protocol, but not 501 Not Implemented: Operation envisaged in the protocol, but not
implemented in the contacted server. implemented in the contacted server.
510 Request Timeout: The time required to serve the request has 510 Request Timeout: The time required to serve the request has
exceeded the envisaged service threshold. exceeded the envisaged service threshold.
511 Resources Not Available: This code is used when the CCMP server 511 Resources Not Available: This code is used when the CCMP server
cannot execute a command because of resource issues, e.g. it cannot execute a command because of resource issues, e.g. it
cannot create a sub conference because the system has reached its cannot create a sub conference because the system has reached its
limits on the number of sub conferences, or if a request for limits on the number of sub conferences, or if a request for
adding a new user fails because the max number of users has been adding a new user fails because the max number of users has been
reached for the conference or the max number of users has been reached for the conference or the max number of users has been
reached for the conferencing system. reached for the conferencing system.
The handling of a "response-code" of "404", "409", "420", "421", The handling of a "response-code" of "404", "409", "420", "421",
"425" and "426" are only applicable to specific operations for "425", "426" and "427" are only applicable to specific operations for
specialized message responses and the details are provided in specialized message responses and the details are provided in
Section 5.3. The following table summarizes these response codes and Section 5.3. The following table summarizes these response codes and
the specialized message and operation to which they are applicable: the specialized message and operation to which they are applicable:
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| Response code | Create | Retrieve | Update | Delete | | Response code | Create | Retrieve | Update | Delete |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
| 404 | userReques | All | All update | All delete | | 404 | userReques | All | All update | All delete |
| | t, | retrieve | requests | requests | | | t, | retrieve | requests | requests |
| | sidebarBy | requests, | | | | | sidebarBy | requests, | | |
skipping to change at page 53, line 6 skipping to change at page 53, line 17
| | userReques | | | | | | userReques | | | |
| | twith no | | | | | | twith no | | | |
| | confUserI | | | | | | confUserI | | | |
| | D(**) | | | | | | D(**) | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| 425 | N/A | N/A | N/A | All delete | | 425 | N/A | N/A | N/A | All delete |
| | | | | request | | | | | | request |
| ------------- | ---------- | ---------- | ---------- | ---------- | | ------------- | ---------- | ---------- | ---------- | ---------- |
| 426 | N/A | N/A | All update | N/A | | 426 | N/A | N/A | All update | N/A |
| | | | requests | | | | | | requests | |
| 427 | ConfReques | N/A | All update | N/A |
| | t, | | requests | |
| | UserReque | | | |
| | st | | | |
+---------------+------------+------------+------------+------------+ +---------------+------------+------------+------------+------------+
Table 2: Response codes and associated operations Table 2: Response codes and associated operations
(*) "420" in answer to a "userRequest/create" operation: in the case (*) "420" in answer to a "userRequest/create" operation: in the case
of a third-party invite, this code can be returned if the of a third-party invite, this code can be returned if the
"confUserID" (contained in the "entity" attribute of the "userInfo" "confUserID" (contained in the "entity" attribute of the "userInfo"
parameter) of the user to be added is unknown. In the case above, if parameter) of the user to be added is unknown. In the case above, if
instead it is the "confUserID" of the sender of the request that is instead it is the "confUserID" of the sender of the request that is
invalid, a "421" error code is returned to the client. invalid, a "421" error code is returned to the client.
skipping to change at page 60, line 40 skipping to change at page 61, line 9
</ccmp:ccmpRequest> </ccmp:ccmpRequest>
2. confResponse message from the server: 2. confResponse message from the server:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse <ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type"> xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID> <confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID> <confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation> <operation>create</operation>
<response-code>200</response-code> <response-code>200</response-code>
<response-string>Success</response-string> <response-string>Success</response-string>
<version>1</version> <version>1</version>
<ccmp:confResponse> <ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com"> <confInfo entity="xcon:8977794@example.com">
<info:conference-description> <info:conference-description>
<info:display-text> <info:display-text>
skipping to change at page 77, line 40 skipping to change at page 78, line 14
HTTP features, and due to the restrictions of some features, a HTTP features, and due to the restrictions of some features, a
conferencing server may not be a fully compliant HTTP server. It is conferencing server may not be a fully compliant HTTP server. It is
intended that a conference server can easily be built using an HTTP intended that a conference server can easily be built using an HTTP
server with extensibility mechanisms, and that a conferencing client server with extensibility mechanisms, and that a conferencing client
can trivially use existing HTTP libraries. This subset of can trivially use existing HTTP libraries. This subset of
requirements helps implementors avoid ambiguity with the many options requirements helps implementors avoid ambiguity with the many options
the full HTTP protocol offers. the full HTTP protocol offers.
A conferencing client that conforms to this specification is not A conferencing client that conforms to this specification is not
required to support HTTP authentication [RFC2617] or cookies required to support HTTP authentication [RFC2617] or cookies
[RFC2965]. These mechanism are unnecessary because CCMP requests [RFC6265]. These mechanism are unnecessary because CCMP requests
carry their own authentication information (in the "subject" field; carry their own authentication information (in the "subject" field;
see Section 5.1). see Section 5.1).
A CCMP request is carried in the body of an HTTP POST request. The A CCMP request is carried in the body of an HTTP POST request. The
conferencing client MUST include a Host header in the request. conferencing client MUST include a Host header in the request.
The MIME type of CCMP request and response bodies is "application/ The MIME type of CCMP request and response bodies is "application/
ccmp+xml". The conference server and conferencing client MUST ccmp+xml". The conference server and conferencing client MUST
provide this value in the HTTP Content-Type and Accept header fields. provide this value in the HTTP Content-Type and Accept header fields.
If the conference server does not receive the appropriate Content- If the conference server does not receive the appropriate Content-
skipping to change at page 79, line 49 skipping to change at page 80, line 25
capabilities. A conference server SHOULD ensure that only capabilities. A conference server SHOULD ensure that only
authorized entities can manipulate the conference data. The authorized entities can manipulate the conference data. The
mechanisms for addressing this security consideration are mechanisms for addressing this security consideration are
described in Section 10.2. described in Section 10.2.
5. The privacy and security of the identity of a user in the 5. The privacy and security of the identity of a user in the
conference MUST be assured. The mechanisms to ensure the conference MUST be assured. The mechanisms to ensure the
security and privacy of identity are discussed in Section 10.3. security and privacy of identity are discussed in Section 10.3.
6. A final issue is related to Denial of Service (DoS) attacks on 6. A final issue is related to Denial of Service (DoS) attacks on
the conferencing server itself. In order to minimize the the conferencing server itself. The recommendations to minimize
potential for DoS attacks, it is RECOMMENDED that conferencing the potential and impact of DoS attacks are discussed in
systems require user authentication and authorization for any Section 10.4.
client participating in a conference. This can be accomplished
through the use of the mechanisms described in Section 10.2, as Of the considerations listed above, items 1 and 3 are addressed
well as by using the security mechanisms associated with the within the referenced sections earlier in this document. The
specific signaling (e.g., SIPS) and media protocols (e.g., SRTP). remaining security considerations are addressed in detail in the
Most CCMP commands can pend indefinitely, thus increasing the following sections.
potential that pending requests can continue to increase when a
server is receiving more requests than it can process within a
specific time period. In this case a server SHOULD return a 510
response code to the pending requests. In addition, to mitigate
the situation clients MUST NOT wait indefinitely for a response
and MUST implement a timer (in the range of seconds) such that
when it expires, the client MUST close the connection.
10.1. Assuring that the Proper Conferencing Server has been contacted 10.1. Assuring that the Proper Conferencing Server has been contacted
Section 7 describes a mechanism using DNS by which a conference
client discovers a conference server. A primary concern is spoofed
DNS replies, thus the use of DNSSEC is RECOMMENDED to ensure that the
client receives a valid response from the DNS server in cases where
this is a concern.
When the CCMP transaction is conducted using TLS [RFC5246], the When the CCMP transaction is conducted using TLS [RFC5246], the
conference server can authenticate its identity, either as a domain conference server can authenticate its identity, either as a domain
name or as an IP address, to the conference client by presenting a name or as an IP address, to the conference client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). With the use of HTTP as a an iPAddress or dNSName, respectively). Any implementation of CCMP
transport for CCMP, this is exactly the authentication described by MUST be capable of being transacted over TLS so that the client can
TLS [RFC2818]. If the client has external information as to the request the above authentication. Note that in order for the
expected identity or credentials of the proper conference server presented certificate to be valid at the client, the client must be
(e.g., a certificate fingerprint), these checks MAY be omitted. Any able to validate the certificate. In particular, the validation path
implementation of CCMP MUST be capable of being transacted over TLS of the certificate must end in one of the client's trust anchors,
so that the client can request the above authentication, and a even if that trust anchor is the conference server certificate
conference server implementation MUST include this feature. Note itself. If the client has external information as to the expected
that in order for the presented certificate to be valid at the identity or credentials of the proper conference server, the
client, the client must be able to validate the certificate. In authentication checks described above MAY be omitted.
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.
10.2. User Authentication and Authorization 10.2. User Authentication and Authorization
Many policy authorization decisions are based on the identity of the Many policy authorization decisions are based on the identity of the
user or the role that a user may have. The conferencing server MUST user or the role that a user may have. The conferencing server MUST
implement mechanisms for authentication of users to validate their implement mechanisms for authentication of users to validate their
identity. There are several ways that a user might authenticate its identity. There are several ways that a user might authenticate its
identity to the system. For users joining a conference using one of identity to the system. For users joining a conference using one of
the call signaling protocols, the user authentication mechanisms for the call signaling protocols, the user authentication mechanisms for
the specific protocol can be used. For the case of users joining the the specific protocol can be used. For example, in the case of a
conference using the CCMP, TLS is RECOMMENDED. user joining the conference using SIP signaling, the user
authentication as defined in [RFC3261] MUST be used. For the case of
users joining the conference using the CCMP, the CCMP Request
messages provide a subject field which contains a username and
password, which can be used for authentication. Since the CCMP
messages are RECOMMENDED to be carried over TLS, this information can
be sent securely.
The XCON Framework [RFC5239] provides an overview of other The XCON Framework [RFC5239] provides an overview of other
authorization mechanisms. In the cases where a user is authorized authorization mechanisms. In the cases where a user is authorized
via multiple mechanisms, it is RECOMMENDED that the conference server via multiple mechanisms, it is RECOMMENDED that the conference server
correlate the authorization of the CCMP interface with other associate the authorization of the CCMP interface with other
authorization mechanisms - e.g., PSTN users that join with a PIN and authorization mechanisms - e.g., PSTN users that join with a PIN and
control the conference using CCMP. When a conference server presents control the conference using CCMP. When a conference server presents
the identity of authorized users, it MAY provide information about the identity of authorized users, it MAY provide information about
the way the identity was proven or verified by the system. A the way the identity was proven or verified by the system. A
conference server can also allow a completely unauthenticated user conference server can also allow a completely unauthenticated user
into the system - this information SHOULD also be communicated to into the system - this information SHOULD also be communicated to
interested parties. interested parties.
Once a user is authenticated and authorized through the various Once a user is authenticated and authorized through the various
mechanisms available on the conference server, the conference server mechanisms available on the conference server, the conference server
MUST allocate a conference user identifier (XCON-USERID) and SHOULD MUST allocate a conference user identifier (XCON-USERID) and SHOULD
associate the XCON-USERID with any signaling specific user associate the XCON-USERID with any signaling specific user
identifiers that were used for authentication and authorization. identifiers that were used for authentication and authorization.
This XCON-USERID can be provided to a specific user through the This XCON-USERID can be provided to a specific user through the
conference notification interface and MUST be provided to users that conference notification interface and MUST be provided to users that
interact with the conferencing system using the CCMP (i.e., in the interact with the conferencing system using the CCMP (i.e., in the
appropriate CCMP response messages). This conference user identifier appropriate CCMP response messages). The XCON-USERIDs for each user/
is REQUIRED for any subsequent operations on the conference object. participant in the conference are contained in the "entity" attribute
in the "user" element in the conference object. The XCON-USERID is
REQUIRED for any subsequent operations by the user on the conference
object and is carried in the confUserID parameter in the CCMP
requests and responses.
We herein remark that the definition of a complete solution for Note that the policy management of an XCON-compliant conference
policy-based management of an XCON-compliant conference system is out system is out of the scope of this document, as well as of the XCON
of the scope of this document, as well as of the XCON WG. We believe WG. However, the specification of a policy management framework is
that the specification of such a framework is orthogonal to the realizable with the overall XCON architecture, in particular with
overall XCON architecture, especially if a Role Based Access Control regards to a Role Based Access Control (RBAC) approach. In RBAC, the
(RBAC) approach is embraced. In RBAC, the following elements are following elements are identified: (i) Users; (ii) Roles; (iii)
identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; Objects; (iv) Operations; (v) Permissions. For all of the above
(v) Permissions. For all of the above elements a direct mapping elements a direct mapping exists onto the main XCON entities. As an
exists onto the main XCON entities. As an example, RBAC objects map example, RBAC objects map onto XCON data model objects and RBAC
onto XCON data model objects and RBAC operations map onto CCMP operations map onto CCMP operations.
operations.
Future documents might work on the definition of an RBAC framework Future documents can define an RBAC framework for XCON, by first
for XCON, by first focusing on the definition of roles and eventually focusing on the definition of roles and then specifying the needed
arriving at the specification of the needed permission policy sets permission policy sets and role policy sets (used to associate policy
and role policy sets (used to associate policy permission sets with permission sets with specific roles). With these policies in place,
specific roles). With these policies in place, access to a access to a conference object compliant with the XCON data model can
conference object compliant with the XCON data model can be be appropriately controlled. As far as assigning users to roles, the
appropriately controlled. Finally, coming to the issue of assigning Users in the RBAC model relate directly to the "users" element in the
users to roles, this can be done through so-called role-assignment conference object. The "users" element is comprised of "user"
policies. Such assignment should be under the responsibility of an elements representing a specific user in the conferencing system.
ad-hoc dedicated Role Assignment entity. Each "user" element contains an "entity" attribute with the XCON-
USERID and a "role" element. Thus, each authorized user (as
represented by an XCON-USERID) can be associated with a "role"
element.
10.3. Security and Privacy of Identity 10.3. Security and Privacy of Identity
An overview of the required privacy and anonymity for users of a An overview of the required privacy and anonymity for users of a
conferencing system are provided in the XCON Framework [RFC5239]. conferencing system are provided in the XCON Framework [RFC5239].
The security of the identity in the form of the XCON-USERID is The security of the identity in the form of the XCON-USERID is
provided in the CCMP protocol through the use of TLS. provided in the CCMP protocol through the use of TLS.
The conference server SHOULD provide mechanisms to ensure the privacy The conference server SHOULD support the mechanism to ensure the
of the XCON-USERID. This is accomplished by the conference client privacy of the XCON-USERID. The conference client indicates the
manipulation of the "provide-anonymity" element defined in the XCON desired level of privacy by manipulation of the "provide-anonymity"
data model ([I-D.ietf-xcon-common-data-model]. The "provide- element defined in the XCON data model
anonymity" element controls the degree to which a user reveals their ([I-D.ietf-xcon-common-data-model]. The "provide-anonymity" element
identity. The conference client MUST set the "provide-anonymity" controls the degree to which a user reveals their identity. The
element to "hidden" if the user does not want other participants to following summarizes the values for the "provide-anonymity" element
even be aware that there is an additional participant in the that the client includes in their requests:
conference. The conference client MUST set the "provide-anonymity"
field to "private" if the user wants to be entirely "anonymous" "hidden": Ensures that other participants are not aware that there
(i.e., other participants are aware that there is another is an additional participant (i.e., the user issuing the request)
participant, but have no information as to their identity). The in the conference. This could be used in cases of users that are
conference client MUST set the "provide-anonymity" field to "semi- authorized with a special role in a conference (e.g., a supervisor
private" if their identity is only to be revealed to other in a call center environment).
participants or users that have a higher level authorization (e.g., a
conferencing system can be configured such that an administrator can "anonymous": Ensures that other participants are aware that there
see all users). To provide the required privacy, the conference is another participant (i.e., the user issuing the request),
client SHOULD include the "provide-anonymity" element in the however, the other participants are not provided information as to
"confInfo" parameter in a CCMP confRequest message with an "update" the identity of the user.
or "create" operation or in the "userInfo" parameter in a CCMP
userRequest message with an "update" or "create" operation, to ensure "semi-private": Ensures that the user's identity is only to be
the user is provided the appropriate level of privacy. If the revealed to other participants or users that have a higher level
"provide-anonymity" element is not included in the conference object, authorization (e.g., a conferencing system can be configured such
then other users can see the participant's identity. that a human administrator can see all users).
If the client desires 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. If the "provide-anonymity" element is not
included in the conference object, then other users can see the
participant's identity. Participants are made aware of other
participants that are "anonymous" or "semi-private" when they perform
subsequent operations on the conference object or retrieve the
conference object or when they receive subsequent notifications.
Note, that independent of the level of anonymity requested by the
user, the identity of the user is always known by the conferencing
system as that is required to perform the necessary authorization as
described in Section 10.2. The degree to which human administrators
can see the information can be controlled using policies (e.g., some
information in the data model can be hidden from human
administrators).
10.4. Mitigating DoS Attacks
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 10.2, as well as by using the security mechanisms associated
with the specific signaling (e.g., SIPS) and media protocols (e.g.,
SRTP). In addition, Section 4.4 describes the use of a timer
mechanism to alleviate the situation whereby CCMP messages pend
indefinitely, thus increasing the potential that pending requests
continue to increase when is a server is receiving more requests than
it can process.
11. XML Schema 11. 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"
skipping to change at page 103, line 46 skipping to change at page 104, line 48
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 12.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: http://www.iana.org/assignments/ccmp-parameters. The
response codes. document creates initial sub-registries for CCMP operation types and
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 following summarizes the requested registry for CCMP Messages:
schema in Section 11. The following summarizes the requested
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: Following the policies outlined
allocated on a specification required basis. in [RFC5226], the IANA policy for assigning new values for the
CCMP message types for CCMP shall be 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 initial CCMP message types: This specification establishes the Message sub-registry under
http://www.iana.org/assignments/ccmp-messages. The initial Message
table is populated using the CCMP messages described in Section 4.1
and defined in the XML schema in Section 11.
optionsRequest: Used by a conference control client to query a Message Description Reference
conferencing system for its capabilities, in terms of supported ------- ----------- ---------
messages (both standard and non-standard). optionsRequest Used by a conference control client [RFCxxxx]
to query a conference server for
its capabilities, in terms of
supported messages.
optionsResponse: The optionsResponse returns a list of CCMP messages optionsResponse Returns a list of CCMP messages [RFCxxxx]
(both standard and non-standard) supported by the specific 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 [RFCxxxx]
conferencing system for its capabilities, in terms of available to query a conferencing system for
conference blueprints. its capabilities, in terms of
available conference blueprints.
blueprintsResponse: The blueprintsResponse returns a list of blueprintsResponse The blueprintsResponse returns a [RFCxxxx]
blueprints supported by the specific conference server. list of blueprints supported
by the specific conference server.
confsRequest: Used by a conference control client to query a confsRequest Used by a conference control client [RFCxxxx]
conferencing system for its scheduled/active conferences. to query a conference server for
its scheduled/active conferences.
confsResponse: The "confsResponse" returns the list of the currently confsResponse Returns the list of the currently [RFCxxxx]
activated/scheduled conferences at the server. activated/scheduled conferences
at the server.
confRequest: The "confRequest" is used to create a conference object confRequest Used to create a conference object [RFCxxxx]
and/or to request an operation on the conference object as a and/or to request an operation on
whole. the conference object as a whole.
confResponse: The "confResponse" indicates the result of the confResponse Indicates the result of the operation [RFCxxxx]
operation on the conference object as a whole. on the conference object as a whole.
userRequest: The "userRequest" is used to request an operation on userRequest Used to request an operation on the [RFCxxxx]
the "user" element in the conference object. "user" element in the conference object.
userResponse: The "userResponse" indicates the result of the userResponse Indicates the result of the requested [RFCxxxx]
requested operation on the "user" element in the conference operation on the "user" element in
object. the conference object.
usersRequest This "usersRequest" is used to manipulate the "users" usersRequest Used to manipulate the "users" element [RFCxxxx]
element in the conference object, including parameters such as the in the conference object, including
"allowed-users-list", "join-handling", etc. parameters such as the "allowed-users-list",
"join-handling", etc.
usersResponse: This "usersResponse" indicates the result of the usersResponse Indicates the result of the request to [RFCxxxx]
request to manipulate the "users" element in the conference manipulate the "users" element in the
object. conference object.
sidebarRequest: This "sidebarRequest" is used to retrieve the sidebarsByValRequest Used to retrieve the "sidebars-by-val" [RFCxxxx]
information related to a sidebar or to create, change or delete a element of the target conference object.
specific sidebar.
sidebarResponse: This "sidebarResponse" indicates the result of the sidebarsByValResponse Returns the list of the sidebar-by-val [RFCxxxx]
sidebarRequest. conferences within the target conference
object.
sidebarsByRefRequest Used to retrieve the "sidebars-by-ref" [RFCxxxx]
element of the target conference object.
sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFCxxxx]
conferences associated with the target
conference object.
sidebarByValRequest Used to request an operation on a [RFCxxxx]
sideber-by-val conference.
sidebarByValResponse Indicates the result of the request to [RFCxxxx]
manipulate a sidebar-by-val conference.
sidebarByRefRequest Used to request an operation on a [RFCxxxx]
sideber-by-ref conference.
sidebarByRefResponse Indicates the result of the request to [RFCxxxx]
manipulate a sidebar-by-ref conference.
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: Following the policies outlined
on a first-come/first-serve basis with specification required. in [RFC5226], the IANA policy for assigning new values for the
Response codes for CCMP shall be 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 specification establishes the Response-code sub-registry under
codes as described above in Section 4.1: http://www.iana.org/assignments/ccmp-parameters. The initial
Response-code table is populated using the Response codes defined in
Section 5.4 as follows:
200: This code indicates that the request was successfully Default
processed. Response
Number String Description Reference
------ ------------- ------------ ---------
200 Success The request was successfully [RFCxxxx]
processed.
409: This code indicates that a requested "update" cannot be 400 Bad Request The request was badly formed in [RFCxxxx]
successfully completed by the server. An example of such some fashion.
situation is when the modification of an object cannot be applied
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
modifications collide with the up-to-date state of the object
stored at the server).
400: This code indicates that the request was badly formed in some 401 Unauthorized The user was not authorized for [RFCxxxx]
fashion. the specific operation on the
conference object.
401: This code indicates that the user was not authorized for the 403 Forbidden The specific operation is not [RFCxxxx]
specific operation on the conference object. valid for the target conference
object.
403: This code indicates that the specific operation is not valid 404 Object Not Found The specific conference object [RFCxxxx]
for the target conference object. was not found.
404: This code indicates that the specific conference object was not 409 Conflict A requested operation cannot be [RFCxxxx]
found. successfully completed by the
server. For example, the
modification of an object
cannot be applied because
the client version of the object
is obsolete and the requested
modifications collide with the
up-to-date state of the object
stored at the server.
420: This code is returned in answer to a "userRequest/create" 420 User Not Found The user who is the target of the [RFCxxxx]
operation, in the case of a third-party invite, when the requested operation is unknown.
"confUserID" (contained in the "entity" attribute of the
"userInfo" parameter) of the user to be added is unknown.
421: This code is returned in the case of requests in which the 421 Invalid confUserID The "confUserID" of the sender [RFCxxxx]
"confUserID" of the sender is invalid. in the request is invalid.
422: This code is returned in response to all requests wishing to 422 Invalid Conference A request to access/manipulate [RFCxxxx]
access/manipulate a password-protected conference object, when the Password a password-protected conference
"conference-password" parameter contained in the request is wrong. object contained an invalid
"conference-password" parameter.
423: This code is returned in response to all requests wishing to 423 Conference Password A request to access/manipulate [RFCxxxx]
access/manipulate a password-protected conference object, when the Required a password-protected conference
"conference-password" parameter is missing in the request. object did not contain a
"conference-password" parameter.
424: This code is returned in response whenever the server wants to 424 Authentication The server wants to authenticate [RFCxxxx]
authenticate the requestor through the "subject" parameter and Required the request through the "subject"
such a parameter is not provided in the request. parameter but the parameter is
not provided in the request.
425: This code indicates that the conferencing system cannot delete 425 Forbidden Delete The conferencing system cannot [RFCxxxx]
the specific conference object because it is a parent for another Parent system cannot delete the specific
conference object. conference object because it is a
parent for another conference object.
426: This code indicates that the target conference object cannot be 426 Forbidden Change The target conference object [RFCxxxx]
changed (e.g., due to policies, roles, privileges, etc.). Protected cannot be changed (e.g., due to
policies, roles or privileges).
510: This code indicates that the request could not be processed 427 Invalid Domain Name The domain name in an [RFCxxxx]
within a reasonable time, with the time specific to a conferencing AUTO_GENERATE_X
system implementation. instance in the conference object
is not within the conference
server's domain of responsibility.
500: This code indicates that the conferencing system experienced 500 Server Internal The conference server experienced [RFCxxxx]
some sort of internal error. Error some sort of internal error.
501: This code indicates that the specific operation is not 501 Not Implemented The specific operation is not [RFCxxxx]
implemented on that conferencing system. implemented on the conferencing
system.
510 Request Timeout The request could not be [RFCxxxx]
processed within a reasonable
time (as specified by the
conferencing system).
511 Resources Not The conference server cannot [RFCxxxx]
Available execute a command because of
resource issues, e.g. it cannot
create a conference because
the system has reached its limits
on the number of conferences.
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, Simo Veikkolainen, Keith Drage and Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage,
Peter Reissner. Special thanks go to Roberta Presta for her Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian
Carpenter (genart review) and Mykyta Yevstifeyev (IANA
considerations). Special thanks go to Roberta Presta for her
invaluable contribution to this document. Roberta has worked on the invaluable contribution to this document. Roberta has worked on the
specification of the CCMP protocol at the University of Napoli for specification of the CCMP protocol at the University of Napoli for
the preparation of her Master thesis. She has also implemented the the preparation of her Master thesis. She has also implemented the
CCMP prototype used for the trials and from which the dumps provided CCMP prototype used for the trials and from which the dumps provided
in Section 6 have been extracted. in Section 6 have been extracted.
14. References 14. References
14.1. Normative References 14.1. Normative References
skipping to change at page 107, line 38 skipping to change at page 110, line 9
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
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
Mechanism", RFC 2965, October 2000. April 2011.
[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 [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-23 Conferencing (XCON)", draft-ietf-xcon-common-data-model-27
(work in progress), February 2011. (work in progress), April 2011.
14.2. Informative References 14.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, "Architectural Styles and the Design of Network-
based Software Architectures", 2000. based Software Architectures", 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 108, line 29 skipping to change at page 110, line 47
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[I-D.ietf-xcon-event-package] [I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J. Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)", Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress), draft-ietf-xcon-event-package-01 (work in progress),
September 2008. September 2008.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and
M. Hadley, "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., Hadley, M., Gudgin, M., Moreau, J., and H. Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
Nielsen, "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 109, line 25 skipping to change at page 111, line 44
parameters and triggering function invocations. In the SOAP parameters and triggering function invocations. In the SOAP
approach, it would be possible to describe a separate operation for approach, it would be possible to describe a separate operation for
each atomic element, but that would greatly increase the complexity each atomic element, but that would greatly increase the complexity
of the protocol. A coarser-grained approach to the CCMP does require of the protocol. A coarser-grained approach to the CCMP does require
that the server process XML elements in updates that have not changed that the server process XML elements in updates that have not changed
and that there can be multiple changes in one update. and that there can be multiple changes in one update.
For CCMP, the resource (REST) model might appear more attractive, For CCMP, the resource (REST) model might appear more attractive,
since the conference operations fit the CRUD approach. since the conference operations fit the CRUD approach.
Neither of these approaches were considered ideal as SOAP was not Neither of these approaches were considered ideal. SOAP was
considered to be general purpose enough for use in a broad range of considered to bring additional overhead. It is quite awkward to
operational environments. It is quite awkward to apply a RESTful apply a RESTful approach since the CCMP requires a more complex
approach since the CCMP requires a more complex request/response request/response protocol in order to maintain the data both in the
protocol in order to maintain the data both in the server and at the server and at the client. This doesn't map very elegantly to the
client. This doesn't map very elegantly to the basic request/ basic request/response model, whereby a response typically indicates
response model, whereby a response typically indicates whether the whether the request was successful or not, rather than providing
request was successful or not, rather than providing additional data additional data to maintain the synchronization between the client
to maintain the synchronization between the client and server data. and server data. In addition, the CCMP clients may also receive the
In addition, the CCMP clients may also receive the data in data in Notifications. While the notification method or protocol
Notifications. While the notification method or protocol used by used by some conferencing clients can be independent of the CCMP, the
some conferencing clients can be independent of the CCMP, the same same data in the server is used for both the CCMP and Notifications -
data in the server is used for both the CCMP and Notifications - this this requires a server application above the transport layer (e.g.,
requires a server application above the transport layer (e.g., HTTP) HTTP) for maintaining the data, which in the CCMP model is
for maintaining the data, which in the CCMP model is transparent to transparent to the transport protocol.
the transport protocol.
A.1. Using SOAP for the CCMP A.1. Using SOAP for the CCMP
A remote procedure call (RPC) mechanism for the CCMP could use SOAP A remote procedure call (RPC) mechanism for the CCMP could use SOAP
(Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC (Simple Object Access Protocol[W3C.REC-soap12-part1-20030624][W3C.REC
-soap12-part2-20030624]), where conferences and the other objects are -soap12-part2-20030624]), where conferences and the other objects are
modeled as services with associated operations. Conferences and modeled as services with associated operations. Conferences and
other objects are selected by their own local identifiers, such as other objects are selected by their own local identifiers, such as
email-like names for users. This approach has the advantage that it email-like names for users. This approach has the advantage that it
can easily define atomic operations that have well-defined error can easily define atomic operations that have well-defined error
 End of changes. 72 change blocks. 
244 lines changed or deleted 374 lines changed or added

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