RFC 6503
Centralized Conferencing Manipulation Protocol
10. Security Considerations
As identified in the XCON framework [RFC5239], there are a wide variety of potential attacks related to conferencing, due to the natural involvement of multiple endpoints and the capability to manipulate the data on the conference server using CCMP. Examples of attacks include the following: an endpoint attempting to listen to conferences in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and an endpoint theft of service in attempting to create conferences it is not allowed to create.
The following summarizes the security considerations for CCMP:
1. The client MUST determine the proper conference server. The
conference server discovery is described in Section 7.
2. The client MUST connect to the proper conference server. The
mechanisms for addressing this security consideration are
described in Section 10.1.
3. The protocol MUST support a confidentiality and integrity
mechanism. As described in Section 9, implementations of CCMP
MUST implement the HTTP transport over TLS [RFC2818].
4. There are security issues associated with the authorization to
perform actions on the conferencing system to invoke specific
capabilities. A conference server SHOULD ensure that only
authorized entities can manipulate the conference data. The
mechanisms for addressing this security consideration are
described in Section 10.2.
5. The privacy and security of the identity of a user in the
conference MUST be assured. The mechanisms to ensure the
security and privacy of identity are discussed in Section 10.3.
6. A final issue is related to Denial-of-Service (DoS) attacks on
the conference server itself. The recommendations to minimize
the potential and impact of DoS attacks are discussed in
Section 10.4.
Of the considerations listed above, items 1 and 3 are addressed
within the referenced sections earlier in this document. The
remaining security considerations are addressed in detail in the
following sections.
10.1. Assuring That the Proper Conference Server Has Been Contacted
Section 7 describes a mechanism using DNS by which a conferencing
client discovers a conference server. A primary concern is spoofed
DNS replies; thus, the use of DNS Security (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
conference server can authenticate its identity, either as a domain
name or as an IP address, to the conferencing client by presenting a
certificate containing that identifier as a subjectAltName (i.e., as
an iPAddress or dNSName, respectively). Any implementation of CCMP
MUST be capable of being transacted over TLS so that the client can
request the above authentication. Note that, in order for the presented certificate to be valid at the client, the client MUST be able to validate the certificate following the procedures in [RFC2818] in the case of HTTP as a transport. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the conference server certificate itself. If the client has external information as to the expected identity or credentials of the proper conference server, the authentication checks described above MAY be omitted.10.2. User Authentication and Authorization
Many policy authorization decisions are based on the identity of the user or the role that a user may have. The conference server MUST implement mechanisms for authentication of users to validate their identity. There are several ways that a user might authenticate its identity to the system. For users joining a conference using one of the call signaling protocols, the user authentication mechanisms for the specific protocol can be used. For example, in the case of a 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 CCMP, the CCMP Request messages provide a subject field that 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 authorization mechanisms. In the cases where a user is authorized via multiple mechanisms, it is RECOMMENDED that the conference server associate the authorization of the CCMP interface with other authorization mechanisms; for example, Public Switched Telephone Network (PSTN) users that join with a PIN and control the conference using CCMP. When a conference server presents the identity of authorized users, it MAY provide information about the way the identity was proven or verified by the system. A conference server can also allow a completely unauthenticated user into the system -- this information SHOULD also be communicated to interested parties. Once a user is authenticated and authorized through the various mechanisms available on the conference server, the conference server MUST allocate a conference user identifier (XCON-USERID) and SHOULD associate the XCON-USERID with any signaling specific user identifiers that were used for authentication and authorization. This XCON-USERID can be provided to a specific user through the conference notification interface and MUST be provided to users that interact with the conferencing system using CCMP (i.e., in the appropriate CCMP response messages). The XCON-USERIDs for each user/
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. Note that the policy management of an XCON-compliant conferencing system is out of the scope of this document, as well as of the XCON working group (WG). However, the specification of a policy management framework is realizable with the overall XCON architecture, in particular with regard to a Role-Based Access Control (RBAC) approach. In RBAC, the following elements are identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; (v) Permissions. For all of the above elements, a direct mapping exists onto the main XCON entities. As an example, RBAC objects map onto XCON data model objects and RBAC operations map onto CCMP operations. Future documents can define an RBAC framework for XCON, by first focusing on the definition of roles and then specifying the needed permission policy sets and role policy sets (used to associate policy permission sets with specific roles). With these policies in place, access to a conference object compliant with the XCON data model can be appropriately controlled. As far as assigning users to roles, the Users in the RBAC model relate directly to the <users> element in the conference object. The <users> element is comprised of <user> elements representing a specific user in the conferencing system. 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
An overview of the required privacy and anonymity for users of a conferencing system are provided in the XCON framework [RFC5239]. The security of the identity in the form of the XCON-USERID is provided in CCMP through the use of TLS. The conference server SHOULD support the mechanism to ensure the privacy of the XCON-USERID. The conferencing client indicates the desired level of privacy by manipulation of the <provide-anonymity> element defined in the XCON data model [RFC6501]. The <provide- anonymity> element controls the degree to which a user reveals their identity. The following summarizes the values for the <provide- anonymity> element that the client includes in their requests:
"hidden": Ensures that other participants are not aware that there
is an additional participant (i.e., the user issuing the request)
in the conference. This could be used in cases of users that are
authorized with a special role in a conference (e.g., a supervisor
in a call center environment).
"anonymous": Ensures that other participants are aware that there
is another participant (i.e., the user issuing the request);
however, the other participants are not provided information as to
the identity of the user.
"semi-private": Ensures that the user's identity is only to be
revealed to other participants or users that have a higher-level
authorization (e.g., a conferencing system can be configured such
that a human administrator can see all users).
If the client desires privacy, the conferencing client SHOULD include
the <provide-anonymity> element in the <confInfo> parameter in a CCMP
confRequest message with an <operation> parameter of "update" or
"create" or in the <userInfo> parameter in a CCMP userRequest message
with an <operation> parameter of "update" or "create". 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
[RFC4732] provides an overview of possible 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., Session Initiation Protocol Secure
(SIPS)) and media protocols (e.g., Secure Realtime Transport Protocol
(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
This section gives the XML schema definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/ccmp+xml" format. This is presented as a formal definition of the "application/ccmp+xml" format. A new XML namespace, a new XML schema, and the MIME type for this schema are registered with IANA as described in Section 12. Note that this XML Schema Definition is not intended to be used with on-the-fly validation of the presence XML document. Whitespaces are included in the schema to conform to the line length restrictions of the RFC format without having a negative impact on the readability of the document. Any conforming processor should remove leading and trailing white spaces. <?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:tns="urn:ietf:params:xml:ns:xcon-ccmp" xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info" schemaLocation="DataModel.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="rfc4575.xsd"/> <xs:element name="ccmpRequest" type="ccmp-request-type" /> <xs:element name="ccmpResponse" type="ccmp-response-type" /> <!-- CCMP request definition --> <xs:complexType name="ccmp-request-type"> <xs:sequence> <xs:element name="ccmpRequest" type="ccmp-request-message-type" /> </xs:sequence> </xs:complexType>
<!-- ccmp-request-message-type -->
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<!-- ccmp-response-message-type -->
<xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0"
maxOccurs="1" />
<xs:element name="response-code"
type="response-codeType"
minOccurs="1" maxOccurs="1" />
<xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP REQUESTS -->
<!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType">
<xs:sequence>
<xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="usersRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- CCMP RESPONSES -->
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType">
<xs:sequence>
<xs:element name="blueprintsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType"/>
<xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsResponseType">
<xs:sequence>
<xs:element name="confsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="userResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType">
<xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence>
<xs:element name="sidebarsByRefInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP ELEMENT TYPES -->
<!-- response-codeType-->
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
</xs:simpleType>
<!-- operationType -->
<xs:simpleType name="operationType">
<xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<!-- subject-type -->
<xs:complexType name="subject-type">
<xs:sequence>
<xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message"
type="standard-message-type"
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name"
type="standard-message-name-type"
minOccurs="1"/>
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<!-- operations-type -->
<xs:complexType name="operations-type">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extended-message-list-type -->
<xs:complexType name="extended-message-list-type">
<xs:sequence>
<xs:element name="extended-message"
type="extended-message-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extended-message-type -->
<xs:complexType name="extended-message-type">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" /> <xs:element name="description" type="xs:string" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:schema> Figure 30: CCMP XML Schema12. IANA Considerations
This document registers a new XML namespace, a new XML schema, and the MIME type for the schema. This document also registers the "XCON" Application Service tag and the "CCMP" Application Protocol tag and defines registries for the CCMP operation types and response codes.12.1. URN Sub-Namespace Registration
This section registers a new XML namespace, "urn:ietf:params:xml:ns:xcon-ccmp". URI: urn:ietf:params:xml:ns:xcon-ccmp Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>CCMP Messages</title>
</head>
<body>
<h1>Namespace for CCMP Messages</h1>
<h2>urn:ietf:params:xml:ns:xcon-ccmp</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6503.txt">
RFC 6503</a>.</p>
</body>
</html>
END
12.2. XML Schema Registration
This section registers an XML schema per the guidelines in [RFC3688].
URI: urn:ietf:params:xml:schema:xcon-ccmp
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary
Barnes (mary.ietf.barnes@gmail.com).
Schema: The XML for this schema can be found as the entirety of
Section 11 of this document.
12.3. MIME Media Type Registration for 'application/ccmp+xml'
This section registers the "application/ccmp+xml" MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application
MIME subtype name: ccmp+xml
Required parameters: (none)
Optional parameters: charset
Same as the charset parameter of "application/xml" as specified in
[RFC3023], Section 3.2.
Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry
protocol data related to conference control. Some of the data
could be considered private. This media type does not provide any
protection and thus other mechanisms such as those described in
Section 10 are required to protect the data. This media type does
not contain executable content.
Interoperability considerations: None.
Published specification: RFC 6503.
Applications that use this media type: Centralized Conferencing
control clients and servers.
Additional Information: Magic Number(s): (none)
File extension(s): .ccmp
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: Mary
Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations
described there also apply to application/ccmp+xml.
12.4. DNS Registrations
Section 12.4.1 defines an Application Service tag of "XCON", which is
used to identify the centralized conferencing (XCON) server for a
particular domain. The Application Protocol tag "CCMP", defined in
Section 12.4.2, is used to identify an XCON server that understands
CCMP.
12.4.1. Registration of a Conference Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag for XCON, as mandated by [RFC3958]. Application Service Tag: XCON Intended usage: Identifies a server that supports centralized conferencing. Defining publication: RFC 6503 Contact information: The authors of this document Author/Change controller: The IESG12.4.2. Registration of a Conference Server Application Protocol Tag for CCMP
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for CCMP, as mandated by [RFC3958]. Application Service Tag: CCMP Intended Usage: Identifies the Centralized Conferencing (XCON) Manipulation Protocol. Applicable Service Tag(s): XCON Terminal NAPTR Record Type(s): U Defining Publication: RFC 6503 Contact Information: The authors of this document Author/Change Controller: The IESG12.5. CCMP Protocol Registry
The IANA has created a new registry for CCMP: http://www.iana.org/assignments/ccmp-parameters. The document creates initial sub-registries for CCMP operation types and response codes.
12.5.1. CCMP Message Types
The following summarizes the registry for CCMP messages: Related Registry: CCMP Message Types Registry Defining RFC: RFC 6503. Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the CCMP message types for CCMP is Specification Required. Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com). 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. Message Description Reference ------- ----------- --------- optionsRequest Used by a conferencing client [RFC6503] to query a conference server for its capabilities, in terms of supported messages. optionsResponse Returns a list of CCMP messages [RFC6503] supported by the specific conference server. blueprintsRequest Used by a conferencing client [RFC6503] to query a conference server for its capabilities, in terms of available conference blueprints. blueprintsResponse Returns a list of blueprints supported [RFC6503] by the specific conference server. blueprintRequest Sent to retrieve the conference object [RFC6503] associated with a specific blueprint. blueprintResponse Returns the conference object [RFC6503] associated with a specific blueprint. confsRequest Used by a conferencing client [RFC6503] to query a conference server for its scheduled/active conferences.
confsResponse Returns the list of the currently [RFC6503]
activated/scheduled conferences
at the server.
confRequest Used to create a conference object [RFC6503]
and/or to request an operation on
the conference object as a whole.
confResponse Indicates the result of the operation [RFC6503]
on the conference object as a whole.
userRequest Used to request an operation on the [RFC6503]
<user> element in the conference object.
userResponse Indicates the result of the requested [RFC6503]
operation on the <user> element in
the conference object.
usersRequest Used to manipulate the <users> element [RFC6503]
in the conference object, including
parameters such as the <allowed-users-list>,
<join-handling>, etc.
usersResponse Indicates the result of the request [RFC6503]
to manipulate the <users> element in
the conference object.
sidebarsByValRequest Used to retrieve the <sidebars-by-val> [RFC6503]
element of the target conference object.
sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503]
conferences within the target
conference object.
sidebarsByRefRequest Used to retrieve the <sidebars-by-ref> [RFC6503]
element of the target conference
object.
sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503]
conferences associated with the target
conference object.
sidebarByValRequest Used to request an operation on a [RFC6503]
sidebar-by-val conference.
sidebarByValResponse Indicates the result of the request to [RFC6503]
manipulate a sidebar-by-val conference.
sidebarByRefRequest Used to request an operation on a [RFC6503]
sideber-by-ref conference.
sidebarByRefResponse Indicates the result of the request to [RFC6503]
manipulate a sidebar-by-ref conference.
12.5.2. CCMP Response Codes
The following summarizes the requested registry for CCMP response
codes:
Related Registry: CCMP Response Code Registry
Defining RFC: RFC 6503.
Registration/Assignment Procedures: Following the policies outlined
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
Barnes (mary.ietf.barnes@gmail.com).
This specification establishes the Response-code sub-registry under
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:
Default
Response
Number String Description Reference
------ ------------- ------------ ---------
200 Success The request was successfully [RFC6503]
processed.
400 Bad Request The request was badly formed in [RFC6503]
some fashion.
401 Unauthorized The user was not authorized for [RFC6503]
the specific operation on the
conference object.
403 Forbidden The specific operation is not [RFC6503]
valid for the target conference
object.
404 Object Not Found The specific conference object [RFC6503]
was not found.
409 Conflict A requested operation cannot be [RFC6503]
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 User Not Found The user who is the target of the [RFC6503]
requested operation is unknown.
421 Invalid confUserID The <confUserID> parameter of the [RFC6503]
sender in the request is invalid.
422 Invalid Conference A request to access/manipulate [RFC6503]
Password a password-protected conference
object contained an invalid
<conference-password> parameter.
423 Conference Password A request to access/manipulate [RFC6503]
Required a password-protected conference
object did not contain a
<conference-password> parameter.
424 Authentication The server wants to authenticate [RFC6503]
Required the request through the <subject>
parameter but the parameter is
not provided in the request.
425 Forbidden Delete The conferencing system cannot [RFC6503]
Parent delete the specific conference
object because it is a
parent for another conference object.
426 Forbidden Change The target conference object [RFC6503]
Protected cannot be changed (e.g., due to
policies, roles or privileges).
427 Invalid Domain Name The domain name in an [RFC6503]
AUTO_GENERATE_X
instance in the conference object
is not within the conference
server's domain of responsibility.
500 Server Internal The conference server experienced [RFC6503]
Error some sort of internal error.
501 Not Implemented The specific operation is not [RFC6503]
implemented on the conferencing
system.
510 Request Timeout The request could not be [RFC6503]
processed within a reasonable
time (as specified by the
conferencing system).
511 Resources Not The conference server cannot [RFC6503]
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
The authors appreciate the feedback provided by Dave Morgan, Pierre
Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean
Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage,
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
specification of CCMP at the University of Napoli for the preparation
of her Master thesis. She has also implemented the CCMP prototype
used for the trials and from which the dumps provided in Section 6
have been extracted.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012. [W3C.REC-xmlschema-1-20041028] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.14.2. Informative References
[REST] Fielding, "Architectural Styles and the Design of Network- based Software Architectures", 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012. [W3C.REC-soap12-part1-20070427] Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M., Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>. [W3C.REC-soap12-part2-20070427] Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N., Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
Appendix A. Evaluation of Other Protocol Models and Transports Considered for CCMP
This section provides some background as to the selection of HTTP as the transport for the CCMP requests/responses. In addition to HTTP, the operations on the objects can be implemented in at least two different ways, namely as remote procedure calls -- using SOAP as described in Appendix A.1 and by defining resources following a RESTful architecture Appendix A.2. In both the SOAP and RESTFUL approaches, servers will have to recreate their internal state representation of the object with each update request, checking parameters and triggering function invocations. In the SOAP approach, it would be possible to describe a separate operation for each atomic element, but that would greatly increase the complexity of the protocol. A coarser-grained approach to CCMP does require that the server process XML elements in updates that have not changed and that there can be multiple changes in one update. For CCMP, the resource (REST) model might appear more attractive, since the conference operations fit the CRUD approach. However, neither of these approaches were considered ideal. SOAP was considered to bring additional overhead. It is quite awkward to apply a RESTful approach since CCMP requires a more complex request/ response protocol in order to maintain the data both in the server and at the client. This doesn't map very elegantly to the basic request/response model, whereby a response typically indicates whether the request was successful or not, rather than providing additional data to maintain the synchronization between the client and server data. In addition, the CCMP clients may also receive the data in notifications. While the notification method or protocol used by some conferencing clients can be independent of CCMP, the same data in the server is used for both CCMP and notifications - this requires a server application above the transport layer (e.g., HTTP) for maintaining the data, which in the CCMP model is transparent to the transport protocol. Thus, the solution for CCMP defined in this document is viewed as a good compromise amongst the most notable past candidates and is referred to as "HTTP single-verb transport plus CCMP body". With this approach, CCMP is able to take advantage of existing HTTP functionality. As with SOAP, CCMP uses a "single HTTP verb" for transport (i.e., a single transaction type for each request/response pair); this allows decoupling CCMP messages from HTTP messages. Similarly, as with any RESTful approach, CCMP messages are inserted directly in the body of HTTP messages, thus avoiding any unnecessary processing and communication burden associated with further intermediaries. With this approach, no modification to the CCMP
messages/operations is required to use a different transport protocol.A.1. Using SOAP for CCMP
A remote procedure call (RPC) mechanism for CCMP could use SOAP (Simple Object Access Protocol [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]), where conferences and the other objects are modeled as services with associated operations. Conferences and other objects are selected by their own local identifiers, such as email-like names for users. This approach has the advantage that it can easily define atomic operations that have well-defined error conditions. All SOAP operations would use a single HTTP verb. While the RESTful approach requires the use of a URI for each object, SOAP can use any token.A.2. A RESTful Approach for CCMP
Conference objects can also be modeled as resources identified by URIs, with the basic CRUD operations mapped to the HTTP methods POST/ PUT for creating objects, GET for reading objects, PATCH/POST/PUT for changing objects, and DELETE for deleting them. Many of the objects, such as conferences, already have natural URIs. CCMP can be mapped into the CRUD (Create, Read, Update, Delete) design pattern. The basic CRUD operations are used to manipulate conference objects, which are XML documents containing the information characterizing a specified conference instance, be it an active conference or a conference blueprint used by the conference server to create new conference instances through a simple clone operation. Following the CRUD approach, CCMP could use a general-purpose protocol such as HTTP [RFC2616] to transfer domain-specific XML- encoded data objects defined in the "Conference Information Data Model for Centralized Conferencing" [RFC6501]. Following on the CRUD approach, CCMP could follow the well-known REST (REpresentational State Transfer) architectural style [REST]. CCMP could map onto the REST philosophy, by specifying resource URIs, resource formats, methods supported at each URI and status codes that have to be returned when a certain method is invoked on a specific URI. A REST-style approach must ensure sure that all operations can be mapped to HTTP operations.
The following summarizes the specific HTTP method that could be used for each of the CCMP Requests: Retrieve: HTTP GET could be used on XCON-URIs, so that clients can obtain data about conference objects in the form of XML data model documents. Create: HTTP PUT could be used to create a new object as identified by the XCON-URI or XCON-USERID. Change: Either HTTP PATCH or HTTP POST could be used to change the conference object identified by the XCON-URI. Delete: HTTP DELETE could be used to delete conference objects and parameters within conference objects identified by the XCON-URI.
Authors' Addresses
Mary Barnes Polycom TX USA EMail: mary.ietf.barnes@gmail.com Chris Boulton NS-Technologies EMail: chris@ns-technologies.com Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 EMail: hgs+xcon@cs.columbia.edu