tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6503

 
 
 

Centralized Conferencing Manipulation Protocol

Part 4 of 4, p. 82 to 119
Prev RFC Part

 


prevText      Top      Up      ToC       Page 82 
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.

Top      Up      ToC       Page 83 
   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

Top      Up      ToC       Page 84 
   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/

Top      Up      ToC       Page 85 
   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:

Top      Up      ToC       Page 86 
      "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

Top      Up      ToC       Page 87 
   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>

Top      Up      ToC       Page 88 
   <!-- 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" />

Top      Up      ToC       Page 89 
           <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>

Top      Up      ToC       Page 90 
   <!-- 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>

Top      Up      ToC       Page 91 
       </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">

Top      Up      ToC       Page 92 
               <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>

Top      Up      ToC       Page 93 
    <!-- 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"/>

Top      Up      ToC       Page 94 
           <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>

Top      Up      ToC       Page 95 
   <!-- 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>

Top      Up      ToC       Page 96 
       <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"

Top      Up      ToC       Page 97 
                        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>

Top      Up      ToC       Page 98 
    <!-- 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>

Top      Up      ToC       Page 99 
            </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>

Top      Up      ToC       Page 100 
    <!-- 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"/>

Top      Up      ToC       Page 101 
            <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" />

Top      Up      ToC       Page 102 
    <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>

Top      Up      ToC       Page 103 
   <!-- 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>

Top      Up      ToC       Page 104 
    <!-- 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"/>

Top      Up      ToC       Page 105 
        <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 Schema

12.  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).

Top      Up      ToC       Page 106 
      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)

Top      Up      ToC       Page 107 
   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.

Top      Up      ToC       Page 108 
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 IESG

12.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 IESG

12.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.

Top      Up      ToC       Page 109 
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.

Top      Up      ToC       Page 110 
  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.

Top      Up      ToC       Page 111 
  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.

Top      Up      ToC       Page 112 
   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.

Top      Up      ToC       Page 113 
   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.

Top      Up      ToC       Page 114 
   [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.

Top      Up      ToC       Page 115 
   [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>.

Top      Up      ToC       Page 116 
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

Top      Up      ToC       Page 117 
   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.

Top      Up      ToC       Page 118 
   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.

Top      Up      ToC       Page 119 
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