Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 6503 Polycom
Category: Standards Track C. Boulton
ISSN: 2070-1721 NS-Technologies
S. Romano
University of Napoli
H. Schulzrinne
Columbia University
March 2012
Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 6503 Polycom
Category: Standards Track C. Boulton
ISSN: 2070-1721 NS-Technologies
S. Romano
University of Napoli
H. Schulzrinne
Columbia University
March 2012
Centralized Conferencing Manipulation Protocol
集中式会议操作协议
Abstract
摘要
The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema.
集中式会议操作协议（CCMP）允许集中式会议（XCON）系统客户端创建、检索、更改和删除描述集中式会议的对象。CCMP是一种控制基本和高级会议功能的方法，如会议状态和功能、参与者、相关角色和细节。CCMP是一种无状态、基于XML的客户机-服务器协议，在其请求和响应消息中以符合集中式会议数据模型模式的XML文档和片段的形式承载会议信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6503.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6503.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions and Terminology .....................................5
3. XCON Conference Control System Architecture .....................5
3.1. Conference Objects .........................................7
3.2. Conference Users ...........................................7
4. Protocol Overview ...............................................8
4.1. Protocol Operations ........................................9
4.2. Data Management ...........................................10
4.3. Data Model Compliance .....................................11
4.4. Implementation Approach ...................................12
5. CCMP Messages ..................................................13
5.1. CCMP Request Message Type .................................13
5.2. CCMP Response Message Type ................................15
5.3. Detailed Messages .........................................17
5.3.1. blueprintsRequest and blueprintsResponse ...........20
5.3.2. confsRequest and confsResponse .....................22
5.3.3. blueprintRequest and blueprintResponse .............24
5.3.4. confRequest and confResponse .......................26
5.3.5. usersRequest and usersResponse .....................30
5.3.6. userRequest and userResponse .......................32
5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37
5.3.8. sidebarByValRequest and sidebarByValResponse .......39
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42
5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44
5.3.11. extendedRequest and extendedResponse ..............47
5.3.12. optionsRequest and optionsResponse ................49
5.4. CCMP Response Codes .......................................53
6. A Complete Example of CCMP in Action ...........................57
6.1. Alice Retrieves the Available Blueprints ..................58
6.2. Alice Gets Detailed Information about a Specific
Blueprint .................................................60
1. Introduction ....................................................4
2. Conventions and Terminology .....................................5
3. XCON Conference Control System Architecture .....................5
3.1. Conference Objects .........................................7
3.2. Conference Users ...........................................7
4. Protocol Overview ...............................................8
4.1. Protocol Operations ........................................9
4.2. Data Management ...........................................10
4.3. Data Model Compliance .....................................11
4.4. Implementation Approach ...................................12
5. CCMP Messages ..................................................13
5.1. CCMP Request Message Type .................................13
5.2. CCMP Response Message Type ................................15
5.3. Detailed Messages .........................................17
5.3.1. blueprintsRequest and blueprintsResponse ...........20
5.3.2. confsRequest and confsResponse .....................22
5.3.3. blueprintRequest and blueprintResponse .............24
5.3.4. confRequest and confResponse .......................26
5.3.5. usersRequest and usersResponse .....................30
5.3.6. userRequest and userResponse .......................32
5.3.7. sidebarsByValRequest and sidebarsByValResponse .....37
5.3.8. sidebarByValRequest and sidebarByValResponse .......39
5.3.9. sidebarsByRefRequest and sidebarsByRefResponse .....42
5.3.10. sidebarByRefRequest and sidebarByRefResponse ......44
5.3.11. extendedRequest and extendedResponse ..............47
5.3.12. optionsRequest and optionsResponse ................49
5.4. CCMP Response Codes .......................................53
6. A Complete Example of CCMP in Action ...........................57
6.1. Alice Retrieves the Available Blueprints ..................58
6.2. Alice Gets Detailed Information about a Specific
Blueprint .................................................60
6.3. Alice Creates a New Conference through a Cloning
Operation .................................................62
6.4. Alice Updates Conference Information ......................65
6.5. Alice Inserts a List of Users into the Conference Object ..66
6.6. Alice Joins the Conference ................................68
6.7. Alice Adds a New User to the Conference ...................70
6.8. Alice Asks for the CCMP Server Capabilities ...............72
6.9. Alice Makes Use of a CCMP Server Extension ................75
7. Locating a Conference Server ...................................78
8. Managing Notifications .........................................79
9. HTTP Transport .................................................80
10. Security Considerations .......................................82
10.1. Assuring That the Proper Conference Server Has
Been Contacted ...........................................83
10.2. User Authentication and Authorization ....................84
10.3. Security and Privacy of Identity .........................85
10.4. Mitigating DoS Attacks ...................................86
11. XML Schema ....................................................87
12. IANA Considerations ..........................................105
12.1. URN Sub-Namespace Registration ..........................105
12.2. XML Schema Registration .................................106
12.3. MIME Media Type Registration for
'application/ccmp+xml' ..................................106
12.4. DNS Registrations .......................................107
12.4.1. Registration of a Conference Server
Application Service Tag ..........................108
12.4.2. Registration of a Conference Server
Application Protocol Tag for CCMP ................108
12.5. CCMP Protocol Registry ..................................108
12.5.1. CCMP Message Types ...............................109
12.5.2. CCMP Response Codes ..............................111
13. Acknowledgments ..............................................113
14. References ...................................................113
14.1. Normative References ....................................113
14.2. Informative References ..................................114
Appendix A. Evaluation of Other Protocol Models and
Transports Considered for CCMP ......................116
A.1. Using SOAP for CCMP ......................................117
A.2. A RESTful Approach for CCMP ..............................117
6.3. Alice Creates a New Conference through a Cloning
Operation .................................................62
6.4. Alice Updates Conference Information ......................65
6.5. Alice Inserts a List of Users into the Conference Object ..66
6.6. Alice Joins the Conference ................................68
6.7. Alice Adds a New User to the Conference ...................70
6.8. Alice Asks for the CCMP Server Capabilities ...............72
6.9. Alice Makes Use of a CCMP Server Extension ................75
7. Locating a Conference Server ...................................78
8. Managing Notifications .........................................79
9. HTTP Transport .................................................80
10. Security Considerations .......................................82
10.1. Assuring That the Proper Conference Server Has
Been Contacted ...........................................83
10.2. User Authentication and Authorization ....................84
10.3. Security and Privacy of Identity .........................85
10.4. Mitigating DoS Attacks ...................................86
11. XML Schema ....................................................87
12. IANA Considerations ..........................................105
12.1. URN Sub-Namespace Registration ..........................105
12.2. XML Schema Registration .................................106
12.3. MIME Media Type Registration for
'application/ccmp+xml' ..................................106
12.4. DNS Registrations .......................................107
12.4.1. Registration of a Conference Server
Application Service Tag ..........................108
12.4.2. Registration of a Conference Server
Application Protocol Tag for CCMP ................108
12.5. CCMP Protocol Registry ..................................108
12.5.1. CCMP Message Types ...............................109
12.5.2. CCMP Response Codes ..............................111
13. Acknowledgments ..............................................113
14. References ...................................................113
14.1. Normative References ....................................113
14.2. Informative References ..................................114
Appendix A. Evaluation of Other Protocol Models and
Transports Considered for CCMP ......................116
A.1. Using SOAP for CCMP ......................................117
A.2. A RESTful Approach for CCMP ..............................117
"A Framework for Centralized Conferencing" [RFC5239] (XCON framework) defines a signaling-agnostic framework, naming conventions, and logical entities required for building advanced conferencing systems. The XCON framework introduces the conference object as a logical representation of a conference instance, representing the current state and capabilities of a conference.
“集中式会议框架”[RFC5239]（XCON框架）定义了构建高级会议系统所需的信令无关框架、命名约定和逻辑实体。XCON框架将会议对象作为会议实例的逻辑表示引入，表示会议的当前状态和功能。
The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document allows authenticated and authorized users to create, manipulate, and delete conference objects. Operations on conferences include adding and removing participants, changing their roles, as well as adding and removing media streams and associated endpoints.
本文档中定义的集中式会议操作协议（CCMP）允许经过身份验证和授权的用户创建、操作和删除会议对象。会议上的操作包括添加和删除参与者、更改他们的角色，以及添加和删除媒体流和关联端点。
CCMP implements the client-server model within the XCON framework, with the conferencing client and conference server acting as client and server, respectively. CCMP uses HTTP [RFC2616] as the protocol to transfer requests and responses, which contain the domain-specific XML-encoded data objects defined in [RFC6501] "Conference Information Data Model for Centralized Conferencing (XCON)".
CCMP在XCON框架内实现客户机-服务器模型，会议客户机和会议服务器分别充当客户机和服务器。CCMP使用HTTP[RFC2616]作为传输请求和响应的协议，其中包含[RFC6501]“集中式会议的会议信息数据模型（XCON）”中定义的特定于域的XML编码数据对象。
Section 2 clarifies the conventions and terminology used in the document. Section 3 provides an overview of the conference control functionality of the XCON framework, together with a description of the main targets CCMP deals with, namely conference objects and conference users. A general description of the operations associated with protocol messages is given in Section 4 together with implementation details. Section 5 delves into the details of specific CCMP messages. A complete, non-normative, example of the operation of CCMP, describing a typical call flow associated with conference creation and manipulation, is provided in Section 6. A survey of the methods that can be used to locate a conference server is provided in Section 7, and Section 8 discusses potential approaches to notifications management. CCMP transport over HTTP is highlighted in Section 9. Security considerations are presented in Section 10. Finally, Section 11 provides the XML schema.
第2节澄清了文件中使用的惯例和术语。第3节概述了XCON框架的会议控制功能，并描述了CCMP处理的主要目标，即会议对象和会议用户。第4节给出了与协议消息相关的操作的一般描述以及实现细节。第5节深入探讨了特定CCMP消息的细节。第6节提供了CCMP操作的完整、非规范性示例，描述了与会议创建和操纵相关的典型呼叫流。第7节介绍了可用于定位会议服务器的方法，第8节讨论了通知管理的潜在方法。HTTP上的CCMP传输在第9节中突出显示。第10节介绍了安全注意事项。最后，第11节提供了XML模式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
In addition to the terms defined in "A Framework for Centralized Conferencing" [RFC5239], this document uses the following terms and acronyms:
除了“集中式会议框架”[RFC5239]中定义的术语外，本文件还使用以下术语和首字母缩略词：
XCON-aware client: An XCON conferencing system client that is able to issue CCMP requests.
XCON感知客户端：能够发出CCMP请求的XCON会议系统客户端。
First-Party Request: A request issued by the client to manipulate its own conferencing data.
第一方请求：客户端发出的一个请求，用于处理其自己的会议数据。
Third-Party Request: A request issued by a client to manipulate the conference data of another client.
第三方请求：一个客户端发出的请求，用于处理另一个客户端的会议数据。
CCMP supports the XCON framework. Figure 1 depicts a subset of the "Conferencing System Logical Decomposition" architecture from the XCON framework document. It illustrates the role that CCMP assumes within the overall centralized architecture.
CCMP支持XCON框架。图1描述了XCON框架文档中“会议系统逻辑分解”体系结构的子集。它说明了CCMP在整个集中式体系结构中所扮演的角色。
........................................................
. Conferencing System .
. .
. +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | .
. | C O N F E R E N C E O B J E C T | | .
. +-+-------------------------------------+ | | .
. | C O N F E R E N C E O B J E C T | | | .
. | | |-+ .
. | |-+ .
. +---------------------------------------+ .
. ^ .
. | .
. v .
. +-------------------+ .
. | Conference Control| .
. | Server | .
. +-------------------+ .
. ^ .
.........................|..............................
|
|Centralized
|Conferencing
|Manipulation
|Protocol
|
.........................|..............................
. V .
. +----------------+ .
. | Conference | .
. | Control | .
. | Client | .
. +----------------+ .
. .
. Conferencing Client .
........................................................
........................................................
. Conferencing System .
. .
. +---------------------------------------+ .
. | C O N F E R E N C E O B J E C T | .
. +-+-------------------------------------+ | .
. | C O N F E R E N C E O B J E C T | | .
. +-+-------------------------------------+ | | .
. | C O N F E R E N C E O B J E C T | | | .
. | | |-+ .
. | |-+ .
. +---------------------------------------+ .
. ^ .
. | .
. v .
. +-------------------+ .
. | Conference Control| .
. | Server | .
. +-------------------+ .
. ^ .
.........................|..............................
|
|Centralized
|Conferencing
|Manipulation
|Protocol
|
.........................|..............................
. V .
. +----------------+ .
. | Conference | .
. | Control | .
. | Client | .
. +----------------+ .
. .
. Conferencing Client .
........................................................
Figure 1: Conferencing Client Interaction
图1：会议客户端交互
The Centralized Conferencing Manipulation Protocol (CCMP) allows the conference control client (conferencing client) to interface with the conference object maintained by the conferencing system, as depicted in Figure 1. Note that additional functionality of the conferencing client and conferencing system is discussed in the XCON framework and related documents.
集中式会议操作协议（CCMP）允许会议控制客户端（会议客户端）与会议系统维护的会议对象进行交互，如图1所示。请注意，XCON框架和相关文档中讨论了会议客户端和会议系统的其他功能。
This section provides details of the identifiers REQUIRED to address and manage the clients associated with a conferencing system using CCMP.
本节提供了使用CCMP寻址和管理与会议系统关联的客户端所需的标识符的详细信息。
Conference objects feature a simple dynamic inheritance-and-override mechanism. Conference objects are linked into a tree known as a "cloning tree" (see Section 7.1 of [RFC5239]). Each cloning tree node inherits attributes from its parent node. The roots of these inheritance trees are conference templates also known as "blueprints". Nodes in the inheritance tree can be active conferences or simply descriptions that do not currently have any resources associated with them (i.e., conference reservations). An object can mark certain of its properties as unalterable, so that they cannot be overridden. Per the framework, a client may specify a parent object (a conference or blueprint) from which to inherit values when a conference is created using the conference control protocol.
会议对象具有简单的动态继承和覆盖机制。会议对象链接到称为“克隆树”的树中（见[RFC5239]第7.1节）。每个克隆树节点都从其父节点继承属性。这些继承树的根是会议模板，也称为“蓝图”。继承树中的节点可以是活动的会议，也可以是当前没有任何相关资源的描述（即会议预订）。对象可以将其某些属性标记为不可更改，以便它们不能被重写。根据该框架，当使用会议控制协议创建会议时，客户端可以指定父对象（会议或蓝图），从中继承值。
Conference objects are uniquely identified by the XCON-URI within the scope of the conferencing system. The XCON-URI is introduced in the XCON framework and defined in the XCON common data model.
会议对象由会议系统范围内的XCON-URI唯一标识。XCON-URI在XCON框架中引入，并在XCON公共数据模型中定义。
Conference objects are comprehensively represented through XML documents compliant with the XML schema defined in the XCON data model [RFC6501]. The root element of such documents, called <conference-info>, is of type "conference-type". It encompasses other XML elements describing different conference features and users as well. Using CCMP, conferencing clients can use these XML structures to express their preferences in creating or updating a conference. A conference server can convey conference information back to the clients using the XML elements.
会议对象通过符合XCON数据模型[RFC6501]中定义的XML模式的XML文档进行全面表示。此类文档的根元素称为<conference info>，其类型为“conference type”。它包含描述不同会议功能和用户的其他XML元素。通过使用CCMP，会议客户端可以使用这些XML结构来表示他们在创建或更新会议时的首选项。会议服务器可以使用XML元素将会议信息传送回客户端。
Each conference can have zero or more users. All conference participants are users, but some users may have only administrative functions and do not contribute or receive media. Users are added one user at a time to simplify error reporting. When a conference is cloned from a parent object, users are inherited as well, so that it is easy to set up a conference that has the same set of participants or a common administrator. The conference server creates individual users, assigning them a unique conference user identifier (XCON-USERID). The XCON-USERID as identifier of each conferencing system client is introduced in the XCON framework and defined in the XCON
每个会议可以有零个或多个用户。所有会议参与者都是用户，但有些用户可能只具有管理功能，不提供或接收媒体。用户一次添加一个用户以简化错误报告。从父对象克隆会议时，也会继承用户，因此很容易设置具有相同参与者集或公共管理员的会议。会议服务器创建单个用户，为他们分配唯一的会议用户标识符（XCON-USERID）。XCON-USERID作为每个会议系统客户端的标识符在XCON框架中引入，并在XCON中定义
common data model. Each CCMP request, with an exception pointed out in Section 5.3.6 representing the case of a user at his first entrance in the system as a conference participant, must carry the XCON-USERID of the requestor in the proper <confUserID> parameter.
公共数据模型。除第5.3.6节中指出的例外情况外，每个CCMP请求都必须在适当的<confUserID>参数中包含请求者的XCON-USERID，该情况代表用户作为会议参与者首次进入系统的情况。
The XCON-USERID acts as a pointer to the user's profile as a conference actor, e.g., her signaling URI and other XCON protocol URIs in general, her role (moderator, participant, observer, etc.), her display text, her joining information, and so on. A variety of elements defined in the common <conference-info> element as specified in the XCON data model are used to describe the users related to a conference including the <users> element, as well as each <user> element included within it. For example, it is possible to determine how a specific user expects and is allowed to join a conference by looking at the <allowed-users-list> in <users>: each <target> element involved in such a list represents a user and shows a 'method' attribute defining how the user is expected to join the conference, i.e., "dial-in" for users that are allowed to dial, "dial-out" for users that the conference focus will be trying to reach (with "dial-in" being the default mode). If the conference is currently active, dial-out users are contacted immediately; otherwise, they are contacted at the start of the conference. CCMP, acting as the conference control protocol, provides a means to manipulate these and other kinds of user-related features.
XCON-USERID充当指向作为会议参与者的用户配置文件的指针，例如，她的信令URI和其他XCON协议URI、她的角色（主持人、参与者、观察者等）、她的显示文本、她的加入信息等。XCON数据模型中指定的公共<conference info>元素中定义的各种元素用于描述与会议相关的用户，包括<users>元素以及其中包含的每个<user>元素。例如，可以通过查看<users>中的<allowed users list>来确定特定用户期望并允许其加入会议的方式：此类列表中涉及的每个<target>元素表示一个用户，并显示一个“method”属性，定义用户期望如何加入会议，即“拨入”对于允许拨号的用户，会议焦点将尝试访问的用户的“拨出”（默认模式为“拨入”）。如果会议当前处于活动状态，则会立即联系拨出用户；否则，将在会议开始时联系他们。CCMP作为会议控制协议，提供了一种操作这些和其他类型的用户相关功能的方法。
As a consequence of an explicit user registration to a specific XCON conferencing system, conferencing clients are usually provided (besides the XCON-USERID) with log-in credentials (i.e., username and password). Such credentials can be used to authenticate the XCON-aware client issuing CCMP requests. Thus, both username and password should be carried in a CCMP request as part of the "subject" parameter whenever a registered conferencing client wishes to contact a CCMP server. CCMP does not maintain a user's subscriptions at the conference server; hence, it does not provide any specific mechanism allowing clients to register their conferencing accounts. The "subject" parameter is just used for carrying authentication data associated with pre-registered clients, with the specific registration modality outside the scope of this document.
作为向特定XCON会议系统明确注册用户的结果，会议客户端通常（除了XCON-USERID之外）提供登录凭据（即用户名和密码）。此类凭证可用于验证发出CCMP请求的XCON感知客户端。因此，每当注册的会议客户端希望联系CCMP服务器时，用户名和密码都应作为“主题”参数的一部分包含在CCMP请求中。CCMP不在会议服务器上维护用户的订阅；因此，它没有提供任何特定机制，允许客户端注册其会议帐户。“subject”参数仅用于携带与预注册客户机关联的身份验证数据，具体注册模式不在本文档范围内。
CCMP is a client-server, XML-based protocol for user creation, retrieval, modification, and deletion of conference objects. CCMP is a stateless protocol, such that implementations can safely handle transactions independently from each other. CCMP messages are XML documents or XML document fragments compliant with the XCON data model representation [RFC6501].
CCMP是一种客户机-服务器、基于XML的协议，用于用户创建、检索、修改和删除会议对象。CCMP是一种无状态协议，因此实现可以彼此独立地安全地处理事务。CCMP消息是符合XCON数据模型表示[RFC6501]的XML文档或XML文档片段。
Section 4.1 specifies the basic operations that can create, retrieve, modify, and delete conference-related information in a centralized conference. The core set of objects manipulated by CCMP includes conference blueprints, the conference object, users, and sidebars.
第4.1节规定了可以在集中会议中创建、检索、修改和删除会议相关信息的基本操作。CCMP操纵的核心对象集包括会议蓝图、会议对象、用户和侧栏。
Each operation in the protocol model, as summarized in Section 4.1, is atomic and either succeeds or fails as a whole. The conference server MUST ensure that the operations are atomic in that the operation invoked by a specific conferencing client completes prior to another client's operation on the same conference object. While the details for this data locking functionality are out of scope for the CCMP specification and are implementation specific for a conference server, some core functionality for ensuring the integrity of the data is provided by CCMP as described in Section 4.2.
如第4.1节所总结的，协议模型中的每个操作都是原子操作，并且作为一个整体成功或失败。会议服务器必须确保操作是原子操作，因为特定会议客户端调用的操作在另一客户端对同一会议对象进行操作之前完成。虽然此数据锁定功能的详细信息不在CCMP规范的范围内，并且是特定于会议服务器的实现，但CCMP提供了一些确保数据完整性的核心功能，如第4.2节所述。
While the XML documents that are carried in CCMP need to comply with the XCON data model, there are situations in which the values for mandatory elements are unknown by the client. The mechanism for ensuring compliance with the data model in these cases is described in Section 4.3.
虽然CCMP中携带的XML文档需要符合XCON数据模型，但在某些情况下，客户端不知道强制元素的值。第4.3节描述了在这些情况下确保符合数据模型的机制。
CCMP is completely independent from underlying protocols, which means that there can be different ways to carry CCMP messages from a conferencing client to a conference server. The specification describes the use of HTTP as a transport solution, including CCMP requests in HTTP POST messages and CCMP responses in HTTP 200 OK replies. This implementation approach is further described in Section 4.4.
CCMP完全独立于底层协议，这意味着可以有不同的方式将CCMP消息从会议客户端传送到会议服务器。该规范描述了HTTP作为传输解决方案的使用，包括HTTP POST消息中的CCMP请求和HTTP 200 OK应答中的CCMP响应。第4.4节进一步描述了该实施方法。
The main operations provided by CCMP belong in four general categories:
CCMP提供的主要操作分为四大类：
create: for the creation of a conference object, a conference user, a sidebar, or a blueprint.
创建：用于创建会议对象、会议用户、侧栏或蓝图。
retrieve: to get information about the current state of either a conference object (be it an actual conference, a blueprint, or a sidebar) or a conference user. A retrieve operation can also be used to obtain the XCON-URIs of the current conferences (active or registered) handled by the conferencing server and/or the available blueprints.
检索：获取有关会议对象（实际会议、蓝图或侧栏）或会议用户的当前状态的信息。检索操作还可用于获取会议服务器处理的当前会议（活动或注册）的XCON URI和/或可用蓝图。
update: to modify the current features of a specified conference or conference user.
更新：修改指定会议或会议用户的当前功能。
delete: to remove from the system a conference object or a conference user.
删除：从系统中删除会议对象或会议用户。
Thus, the main targets of CCMP operations are as follows:
因此，CCMP操作的主要目标如下：
o conference objects associated with either active or registered conferences,
o 与活动会议或已注册会议关联的会议对象，
o conference objects associated with blueprints,
o 与蓝图相关的会议对象，
o conference objects associated with sidebars, both embedded in the main conference (i.e., <entry> elements in <sidebars-by-value>) and external to it (i.e., whose XCON-URIs are included in the <entry> elements of <sidebars-by-ref>),
o 与侧栏关联的会议对象，既嵌入在主会议中（即<侧栏by value>中的<entry>元素），也在其外部（即其XCON URI包含在<侧栏by ref>的<entry>元素中），
o <user> elements associated with conference users, and
o 与会议用户关联的<user>元素，以及
o the list of XCON-URIs related to conferences and blueprints available at the server, for which only retrieval operations are allowed.
o 与服务器上可用的会议和蓝图相关的XCON URI列表，仅允许检索操作。
The XCON framework defines a model whereby the conference server centralizes and maintains the conference information. Since multiple clients can modify the same conference objects, a conferencing client might not have the latest version of a specific conference object when it initiates operations. To determine whether the client has the most up-to-date conference information, CCMP defines a versioning approach. Each conference object is associated with a version number. All CCMP response messages containing a conference document (or a fragment thereof) MUST contain a <version> parameter. When a client sends an update message to the server, which includes modifications to a conference object, if the modifications are all successfully applied, the server MUST return a response, with a <response-code> of "200", containing the version number of the modified object. With this approach, a client working on version "X" of a conference object that receives a response, with a <response-code> of "200", with a version number that is "X+1" can be certain that the version it manipulated was the most up to date. However, if the response contains a version that is at least "X+2", the client knows that the object modified by the server was more up to date than the object the client was manipulating. In order to ensure that the client always has the latest version of the modified object, the client can send a request to the conference server to retrieve the conference object. The client can then update the relevant data elements in the conference object prior to invoking a specific operation. Note that a client subscribed to the XCON event package
XCON框架定义了一个模型，会议服务器据此集中并维护会议信息。由于多个客户端可以修改相同的会议对象，因此会议客户端在启动操作时可能没有特定会议对象的最新版本。为了确定客户端是否拥有最新的会议信息，CCMP定义了一种版本控制方法。每个会议对象都与一个版本号相关联。包含会议文档（或其片段）的所有CCMP响应消息必须包含<version>参数。当客户端向服务器发送更新消息（包括对会议对象的修改）时，如果所有修改都成功应用，服务器必须返回一个响应，响应的<response code>为“200”，其中包含修改对象的版本号。通过这种方法，处理会议对象的版本“X”的客户机可以确定其操作的版本是最新的，该版本的<response code>为“200”，版本号为“X+1”。但是，如果响应包含的版本至少为“X+2”，则客户端知道服务器修改的对象比客户端正在操作的对象更为最新。为了确保客户端始终具有修改对象的最新版本，客户端可以向会议服务器发送请求以检索会议对象。然后，客户端可以在调用特定操作之前更新会议对象中的相关数据元素。请注意，客户端订阅了XCON事件包
[RFC6502] notifications about conference object modifications, will receive the most up-to-date version of that object upon receipt of a notification.
[RFC6502]关于会议对象修改的通知将在收到通知后收到该对象的最新版本。
The "version" parameter is OPTIONAL for requests, since it is not needed by the server: as long as the required modifications can be applied to the target conference object without conflicts, the server does not care whether the client has stored an up-to-date view of the information. In addition, to ensure the integrity of the data, the conference server first checks all the parameters, before making any changes to the internal representation of the conference object. For example, it would be undesirable to change the <subject> of the conference, but then detect an invalid URI in one of the <service-uris> and abort the remaining updates.
“version”参数对于请求是可选的，因为服务器不需要它：只要所需的修改可以应用于目标会议对象而不会发生冲突，服务器就不关心客户端是否存储了信息的最新视图。此外，为了确保数据的完整性，会议服务器首先检查所有参数，然后再对会议对象的内部表示进行任何更改。例如，不希望更改会议的<subject>，但随后在其中一个<service URI>中检测到无效的URI并中止其余更新。
The XCON data model [RFC6501] identifies some elements and attributes as mandatory. Since the XML documents carried in the body of the CCMP requests and responses need to be compliant with the XCON data model, there can be a problem in cases of client-initiated operations, such as the initial creation of conference objects and cases whereby a client updates a conference object adding new elements, such as a new user. In such cases, not all of the mandatory data can be known in advance by the client issuing a CCMP request. As an example, a client cannot know, at the time it issues a conference creation request, the XCON-URI that the server will assign to the yet-to-be-created conference; hence, it is not able to populate the mandatory 'entity' attribute of the conference document contained in the request with the correct value. To solve this issue, the CCMP client fills all mandatory data model fields, for which no value is available at the time the request is constructed, with placeholder values in the form of a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a unique numeric index for each data model field for which the value is unknown. This form of wildcard string is chosen, rather than the use of random unique strings (e.g., FOO_BAR_LA) or non-numeric values for X, to simplify processing at the server. The values of AUTO_GENERATE_X are only unique within the context of the specific request. The placeholder AUTO_GENERATE_X values MUST be within the value part of an attribute or element (e.g., <userinfo entity="xcon-userid:AUTO_GENERATE_1@example.com">).
XCON数据模型[RFC6501]将某些元素和属性标识为必需的。由于CCMP请求和响应主体中携带的XML文档需要符合XCON数据模型，因此在客户端启动操作的情况下可能会出现问题，例如初始创建会议对象，以及客户端通过添加新元素（例如新用户）来更新会议对象的情况。在这种情况下，发出CCMP请求的客户机不能预先知道所有强制数据。例如，客户端在发出会议创建请求时无法知道服务器将分配给尚未创建的会议的XCON-URI；因此，它无法使用正确的值填充请求中包含的会议文档的强制“实体”属性。为解决此问题，CCMP客户端使用通配符字符串形式的占位符值AUTO_GENERATE_X（全大写）填充所有强制数据模型字段（在构造请求时没有可用值），其中X是值未知的每个数据模型字段的唯一数字索引。选择这种形式的通配符字符串，而不是使用随机唯一字符串（例如FOO_BAR_LA）或X的非数值，以简化服务器上的处理。AUTO_GENERATE_X的值仅在特定请求的上下文中是唯一的。占位符AUTO_GENERATE_X值必须位于属性或元素的值部分（例如，<userinfo entity=“xcon userid:AUTO_GENERATE_1@example.com">).
When the server receives requests containing values in the form of AUTO_GENERATE_X, the server does the following:
当服务器接收到包含AUTO_GENERATE_X形式的值的请求时，服务器将执行以下操作：
(a) Generates the proper identifier for each instance of AUTO_GENERATE_X in the document. If an instance of AUTO_GENERATE_X is not within the value part of the attribute/ element, the server MUST send a <response-code> of "400 Bad Request". In cases where AUTO_GENERATE_X appears only in the user part of a URI (i.e., in the case of XCON-USERIDs or XCON-URIs), the server needs to ensure that the domain name is one that is within the server's domain of responsibility. If the domain name is not within the server's domain of responsibility, then the server MUST send a <response-code> of "427 Invalid Domain Name". The server MUST replace each instance of a specific wildcard field (e.g., AUTO_GENERATE_1) with the same identifier. The identifiers MUST be unique for each instance of AUTO_GENERATE_X within the same XML document received in the request; for example, the value that replaces AUTO_GENERATE_1 MUST NOT be the same as the value that replaces AUTO_GENERATE_2. Note that the values that replace the instances of AUTO_GENERATE_X are not the same across all conference objects; for example, different values can be used to replace AUTO_GENERATE_1 in two different documents.
(a) 为文档中的每个AUTO_GENERATE_X实例生成正确的标识符。如果AUTO_GENERATE_X的实例不在属性/元素的值部分，则服务器必须发送<response code>“400 Bad Request”。如果AUTO_GENERATE_X仅出现在URI的用户部分（即，在XCON用户ID或XCON URI的情况下），服务器需要确保域名在服务器的责任域内。如果域名不在服务器的责任域内，则服务器必须发送“427无效域名”的<response code>。服务器必须用相同的标识符替换特定通配符字段（例如，AUTO_GENERATE_1）的每个实例。在请求中接收的同一XML文档中，AUTO_GENERATE_X的每个实例的标识符必须是唯一的；例如，替换自动生成的值不得与替换自动生成的值相同。请注意，在所有会议对象中，替换AUTO_GENERATE_X实例的值并不相同；例如，可以使用不同的值替换两个不同文档中的自动生成1。
(b) Sends a response in which all values of AUTO_GENERATE_X received in the request have been replaced by the newly created one(s).
(b) 发送一个响应，其中请求中接收到的AUTO_GENERATE_X的所有值都已替换为新创建的值。
With this approach, compatibility with the data model requirements is maintained, while allowing for client-initiated manipulation of conference objects at the server's side. Note that the use of this mechanism could be avoided in come cases by using multiple operations, such as creating a new user and then adding the new user to an existing conference. However, the AUTO_GENERATE_X mechanism allows a single operation to be used to effect the same change on the conference object.
使用这种方法，可以保持与数据模型要求的兼容性，同时允许在服务器端由客户端发起对会议对象的操作。请注意，在某些情况下，可以通过使用多个操作来避免使用此机制，例如创建新用户，然后将新用户添加到现有会议。但是，自动生成机制允许使用单个操作对会议对象进行相同的更改。
CCMP is implemented using HTTP, placing the CCMP request messages into the body of an HTTP POST operation and placing the CCMP responses into the body of the HTTP response messages. A non-exhaustive summary of the other approaches that were considered and the perceived advantages of the HTTP solution described in this document are provided in Appendix A.
CCMP使用HTTP实现，将CCMP请求消息放入HTTP POST操作的主体中，并将CCMP响应放入HTTP响应消息的主体中。附录A中提供了考虑的其他方法的非详尽摘要以及本文档中描述的HTTP解决方案的感知优势。
Most CCMP commands can pend indefinitely, thus increasing the potential that pending requests can continue to increase when a server is receiving more requests than it can process within a
大多数CCMP命令都可以无限期挂起，因此，当服务器接收的请求超过其在同一时间内可以处理的数量时，挂起的请求可能会继续增加
specific time period. In this case, a server SHOULD return a <response-code> of "510" to the pending requests. In addition, to mitigate the situation, clients MUST NOT wait indefinitely for a response and MUST implement a timer such that when it expires, the client MUST close the connection. Thirty seconds is RECOMMENDED as the default value for this timer. Sixty seconds is considered a reasonable upper range. Note that there may be cases where a response message is lost and a request has been successful (e.g., user added to a conference); yet, the client will be unaware and close the connection. However, as described in Section 4.2, there is a versioning mechanism for the conference objects; thus, there is a mechanism for the conference object stored by the client to be brought up to date.
具体时间段。在这种情况下，服务器应该向挂起的请求返回<response code>“510”。此外，为了缓解这种情况，客户端不能无限期地等待响应，并且必须实现计时器，以便在响应过期时，客户端必须关闭连接。建议将30秒作为此计时器的默认值。60秒被认为是合理的上限。注意，可能存在响应消息丢失且请求成功的情况（例如，用户添加到会议）；然而，客户端将不知道并关闭连接。但是，如第4.2节所述，会议对象有一个版本控制机制；因此，存在使客户机存储的会议对象更新的机制。
CCMP messages have a MIME-type of "application/ccmp+xml", which appears inside the Content-Type and Accept header fields of HTTP requests and responses. The XML documents in the CCMP messages MUST be encoded in UTF-8. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. The 'charset' parameter MUST be included with the XML document. Section 9 provides the complete requirements for an HTTP implementation to support CCMP.
CCMP消息有一个MIME类型“application/CCMP+xml”，它出现在HTTP请求和响应的内容类型和接受头字段中。CCMP消息中的XML文档必须用UTF-8编码。本规范遵循[RFC3023]中描述的建议和约定，包括类型（“+xml”后缀）的命名约定和“charset”参数的使用。XML文档中必须包含“charset”参数。第9节提供了支持CCMP的HTTP实现的完整要求。
CCMP messages are either requests or responses. The general CCMP request message is defined in Section 5.1. The general CCMP response message is defined in Section 5.2. The details of the specific message type that is carried in the CCMP request and response messages are described in Section 5.3. CCMP response codes are listed in Section 5.4.
CCMP消息是请求或响应。第5.1节定义了通用CCMP请求消息。第5.2节定义了通用CCMP响应消息。第5.3节描述了CCMP请求和响应消息中包含的特定消息类型的详细信息。第5.4节列出了CCMP响应代码。
A CCMP request message is comprised of the following parameters:
CCMP请求消息由以下参数组成：
subject: An OPTIONAL parameter containing the username and password of the client registered at the conferencing system. Each user who subscribes to the conferencing system is assumed to be equipped with those credentials and SHOULD enclose them in each CCMP request she issues. These fields can be used to control that the user sending the CCMP request has the authority to perform the requested operation. The same fields can also be used for other authorization and authentication procedures.
主题：可选参数，包含在会议系统中注册的客户端的用户名和密码。假设订阅会议系统的每个用户都配备了这些凭证，并应将其包含在她发出的每个CCMP请求中。这些字段可用于控制发送CCMP请求的用户是否有权执行请求的操作。同样的字段也可用于其他授权和身份验证过程。
confUserID: An OPTIONAL parameter containing the XCON-USERID of the client. The XCON-USERID is used to identify any conferencing client within the context of the conferencing system and it is assigned by the conference server for each conferencing client who interacts with it. The <confUserID> parameter is REQUIRED in the CCMP request and response messages with the exception of the case of a user who has no XCON-USERID and who wants to enter, via CCMP, a conference whose identifier is known. In such case, a side effect of the request is that the user is provided with an appropriate XCON-USERID. An example of the aforementioned case will be provided in Section 5.3.6.
confUserID：一个可选参数，包含客户端的XCON-USERID。XCON-USERID用于识别会议系统上下文中的任何会议客户端，并由会议服务器为与其交互的每个会议客户端分配。CCMP请求和响应消息中需要<confUserID>参数，但没有XCON-USERID且希望通过CCMP进入标识符已知的会议的用户除外。在这种情况下，请求的一个副作用是向用户提供适当的XCON-USERID。上述情况的示例将在第5.3.6节中提供。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confObjID：包含目标会议对象的XCON-URI的可选参数。
operation: An OPTIONAL parameter refining the type of specialized request message. The <operation> parameter is REQUIRED in all requests except for the blueprintsRequest and confsRequest specialized messages.
操作：优化专用请求消息类型的可选参数。除了blueprintsRequest和confsRequest专用消息之外，所有请求都需要<operation>参数。
conference-password: The parameter is OPTIONAL except that it MUST be inserted in all requests whose target conference object is password-protected i.e., contains the <conference-password> element in [RFC6501]). A CCMP <response-code> of "423" MUST be returned if a conference-password is not included in the request when required.
会议密码：该参数是可选的，但必须插入到目标会议对象受密码保护的所有请求中，即包含[RFC6501]中的<conference password>元素。如果需要时请求中未包含会议密码，则必须返回CCMP<response code>“423”。
specialized request message: This is a specialization of the generic request message (e.g., blueprintsRequest), containing parameters that are dependent on the specific request sent to the server. A specialized request message MUST be included in the CCMP request message. The details for the specialized messages and associated parameters are provided in Section 5.3.
专用请求消息：这是通用请求消息（例如blueprintsRequest）的专用化，包含依赖于发送到服务器的特定请求的参数。CCMP请求消息中必须包含专用请求消息。第5.3节提供了专用消息和相关参数的详细信息。
<!-- Definition of CCMP Request -->
<!-- Definition of CCMP Request -->
<xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpRequest" type="ccmp-request-type" />
<!-- Definition of ccmp-request-type-->
<!-- Definition of ccmp-request-type-->
<xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
<!-- Definition of ccmp-request-message-type -->
<!-- Definition of 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>
<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>
Figure 2: Structure of CCMP Request Messages
图2:CCMP请求消息的结构
A CCMP response message is comprised of the following parameters:
CCMP响应消息由以下参数组成：
confUserID: A REQUIRED parameter in CCMP response messages containing the XCON-USERID of the conferencing client that issued the CCMP request message.
confUserID：CCMP响应消息中的必需参数，包含发出CCMP请求消息的会议客户端的XCON-USERID。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confObjID：包含目标会议对象的XCON-URI的可选参数。
operation: An OPTIONAL parameter for CCMP response messages. This parameter is REQUIRED in all responses except for the "blueprintsResponse" and "confsResponse" specialized messages.
操作：CCMP响应消息的可选参数。除“blueprintsResponse”和“confsResponse”专用消息外，所有响应都需要此参数。
response-code: A REQUIRED parameter containing the response code associated with the request. The response code MUST be chosen from the codes listed in Section 5.4.
响应代码：包含与请求关联的响应代码的必需参数。响应代码必须从第5.4节中列出的代码中选择。
response-string: An OPTIONAL reason string associated with the response. In case of an error, in particular, this string can be used to provide the client with detailed information about the error itself.
响应字符串：与响应关联的可选原因字符串。特别是在发生错误的情况下，可以使用此字符串向客户端提供有关错误本身的详细信息。
version: An OPTIONAL parameter reflecting the current version number of the conference object referred by the confObjID. This number is contained in the 'version' attribute of the <conference-info> element related to that conference. This parameter is REQUIRED in CCMP response messages and SHOULD NOT be included in CCMP request messages.
版本：一个可选参数，反映confObjID引用的会议对象的当前版本号。此编号包含在与该会议相关的<conference info>元素的“version”属性中。此参数在CCMP响应消息中是必需的，不应包含在CCMP请求消息中。
specialized response message: This is specialization of the generic response message, containing parameters that are dependent on the specific request sent to the server (e.g., "blueprintsResponse"). A specialized response message SHOULD be included in the CCMP response message, except in an error situation where the CCMP request message did not contain a valid specialized message. In this case, the conference server MUST return a <response-code> of "400". The details for the specialized messages and associated parameters are provided in Section 5.3.
专用响应消息：这是通用响应消息的专用化，包含依赖于发送到服务器的特定请求的参数（例如，“blueprintsResponse”）。CCMP响应消息中应包含专用响应消息，但CCMP请求消息不包含有效专用消息的错误情况除外。在这种情况下，会议服务器必须返回<response code>“400”。第5.3节提供了专用消息和相关参数的详细信息。
<!-- Definition of CCMP Response -->
<!-- Definition of CCMP Response -->
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- Definition of ccmp-response-type -->
<!-- Definition of ccmp-response-type -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<!-- Definition of ccmp-response-message-type -->
<!-- Definition of 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" 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>
<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" 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>
Figure 3: Structure of CCMP Response Message
图3:CCMP响应消息的结构
Based on the request and response message structures described in Sections 5.1 and 5.2, the following summarizes the specialized CCMP request and response types described in this document:
根据第5.1节和第5.2节中描述的请求和响应消息结构，以下总结了本文件中描述的专用CCMP请求和响应类型：
1. blueprintsRequest/blueprintsResponse
1. 蓝图请求/蓝图响应
2. confsRequest/confsResponse
2. 会议请求/会议响应
3. blueprintRequest/blueprintResponse
3. 蓝图请求/蓝图响应
4. confRequest/confResponse
4. 确认请求/确认响应
5. usersRequest/usersResponse
5. 用户请求/用户响应
6. userRequest/userResponse
6. 用户请求/用户响应
7. sidebarsByValRequest/sidebarsByValResponse
7. sidebarsByValRequest/sidebarsByValResponse
8. sidebarsByRefRequest/sidebarsByRefResponse
8. sidebarsByRefRequest/sidebarsByRefResponse
9. sidebarByValRequest/sidebarByValResponse
9. sidebarByValRequest/sidebarByValResponse
10. sidebarByRefRequest/sidebarByRefResponse
10. sidebarByRefRequest/sidebarByRefResponse
11. extendedRequest/extendedResponse
11. extendedRequest/extendedResponse
12. optionsRequest/optionsResponse
12. 选项请求/选项响应
These CCMP request/response pairs use the fundamental CCMP operations as defined in Section 4.1 to manipulate the conference data. These request/response pairs are included in an IANA registry as defined in Section 12.5. Table 1 summarizes the remaining CCMP operations and corresponding actions that are valid for a specific CCMP request type, noting that neither the blueprintsRequest/blueprintsResponse nor confsRequest/confsResponse require an <operation> parameter. An entity MUST support the response message for each of the request messages that is supported. The corresponding response message MUST contain the same <operation> parameter. Note that some entries are labeled "N/A", indicating that the operation is invalid for that request type. In the case of an "N/A*" label, the operation MAY be allowed for specific privileged users or system administrators but is not part of the functionality included in this document.
这些CCMP请求/响应对使用第4.1节中定义的基本CCMP操作来操纵会议数据。这些请求/响应对包含在第12.5节定义的IANA注册表中。表1总结了对特定CCMP请求类型有效的剩余CCMP操作和相应操作，注意blueprintsRequest/blueprintsResponse和confsRequest/confsResponse都不需要<operation>参数。实体必须支持每个受支持的请求消息的响应消息。相应的响应消息必须包含相同的<operation>参数。请注意，有些条目标记为“N/A”，表示该操作对于该请求类型无效。对于“N/A*”标签，可能允许特定特权用户或系统管理员执行该操作，但该操作不属于本文档中包含的功能的一部分。
+---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | |
| Request Type | | | | |
+---------------+------------+------------+------------+------------+
| blueprints | Get list | N/A | N/A | N/A |
| Request | of | | | |
| | blueprints | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprint | Get | N/A* | N/A* | N/A* |
| Request | blueprint | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest | Get list | N/A | N/A | N/A |
| | of confs | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confRequest | Get | Create | Change | Delete |
| | conference | conference | conference | conference |
| | object | object | object | object |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Get | N/A(**) | Change | N/A(**) |
| | <users> | | <users> | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Get | Add a | Change | Delete |
| | specified | <user> to | specified | specified |
| | <user> | a conf | <user> | <user> |
| | | (***) | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByVal | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-val> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByRef | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-ref> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByValR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-val | by-val | by-val | by-val |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByRefR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-ref | by-ref | by-ref | by-ref |
+---------------+------------+------------+------------+------------+
+---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | |
| Request Type | | | | |
+---------------+------------+------------+------------+------------+
| blueprints | Get list | N/A | N/A | N/A |
| Request | of | | | |
| | blueprints | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprint | Get | N/A* | N/A* | N/A* |
| Request | blueprint | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest | Get list | N/A | N/A | N/A |
| | of confs | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confRequest | Get | Create | Change | Delete |
| | conference | conference | conference | conference |
| | object | object | object | object |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Get | N/A(**) | Change | N/A(**) |
| | <users> | | <users> | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Get | Add a | Change | Delete |
| | specified | <user> to | specified | specified |
| | <user> | a conf | <user> | <user> |
| | | (***) | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByVal | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-val> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByRef | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-ref> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByValR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-val | by-val | by-val | by-val |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByRefR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-ref | by-ref | by-ref | by-ref |
+---------------+------------+------------+------------+------------+
Table 1: Request Type Operation-Specific Processing
表1：请求类型操作特定处理
(**): These operations are not allowed for a usersRequest message, since the <users> section, which is the target element of such a request, is created and removed in conjunction with the creation and deletion, respectively, of the associated conference document. Thus, "update" and "retrieve" are the only semantically correct operations for such message.
（**）：不允许对usersRequest消息执行这些操作，因为作为此类请求的目标元素的<users>部分分别与相关会议文档的创建和删除一起创建和删除。因此，“更新”和“检索”是此类消息的唯一语义正确的操作。
(***): This operation can involve the creation of an XCON-USERID, if
the sender does not add it in the <confUserID> parameter and/or if
the entity field of the <userInfo> parameter is void.
(***): This operation can involve the creation of an XCON-USERID, if
the sender does not add it in the <confUserID> parameter and/or if
the entity field of the <userInfo> parameter is void.
Additional parameters included in the specialized CCMP request and response messages are detailed in the subsequent sections. If a required parameter is not included in a request, the conference server MUST return a <response-code> of "400" per Section 5.4.
专用CCMP请求和响应消息中包含的其他参数将在后续章节中详细说明。如果请求中未包含所需参数，则会议服务器必须根据第5.4节返回“400”的<response code>。
A blueprintsRequest (Figure 4) message is sent to request the list of XCON-URIs associated with the available blueprints from the conference server. These XCON-URIs can be subsequently used by the client to access detailed information about a specified blueprint with a specific blueprintRequest message per Section 5.3.3.
发送一条blueprintsRequest（图4）消息，从会议服务器请求与可用蓝图关联的XCON URI列表。根据第5.3.3节的规定，这些XCON URI随后可由客户机使用，通过特定的blueprintRequest消息访问有关指定蓝图的详细信息。
The <confUserID> parameter MUST be included in every blueprintsRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. Since a blueprintsRequest message is not targeted to a specific conference instance and is a "retrieve-only" request, the <confObjID> and <operation> parameters MUST NOT be included in the blueprintsRequest/Response messages.
<confUserID>参数必须包含在每个blueprintsRequest/Response消息中，并反映发出请求的会议客户端的XCON-USERID。由于blueprintsRequest消息不是针对特定会议实例的，而是“仅检索”请求，因此blueprintsRequest/Response消息中不得包含<confObjID>和<operation>参数。
In order to obtain a specific subset of the available blueprints, a client may specify a selection filter providing an appropriate xpath query in the OPTIONAL "xpathFilter" parameter of the request. The information in the blueprints typically represents general capabilities and characteristics. For example, to select blueprints having both audio and video stream support, a possible xpathFilter value could be: "/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']". A conference server SHOULD NOT provide any sensitive information (e.g., passwords) in the blueprints.
为了获得可用蓝图的特定子集，客户机可以在请求的可选“xpathFilter”参数中指定一个选择过滤器，提供适当的xpath查询。蓝图中的信息通常代表一般能力和特征。例如，要选择同时支持音频和视频流的蓝图，xpathFilter可能的值可以是：“/conference info[conference description/available media/entry/type='audio'和conference description/available media/entry/type='video']”。会议服务器不应在蓝图中提供任何敏感信息（如密码）。
The associated blueprintsResponse message SHOULD contain, as shown in Figure 4, a "blueprintsInfo" parameter containing the above mentioned XCON-URI list.
如图4所示，关联的blueprintsResponse消息应该包含一个“blueprintsInfo”参数，其中包含上述XCON-URI列表。
<!-- 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>
<!-- 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 -->
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="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>
<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>
<!-- blueprintsResponse -->
<!-- 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>
<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 -->
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="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>
<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>
Figure 4: Structure of the blueprintsRequest and blueprintsResponse Messages
图4:blueprintsRequest和blueprintsResponse消息的结构
A confsRequest message is used to retrieve, from the server, the list of XCON-URIs associated with active and registered conferences currently handled by the conferencing system. The <confUserID> parameter MUST be included in every confsRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. The <confObjID> parameter MUST NOT be included in the confsRequest message. The confsRequest message is of a retrieve-only type, since the sole purpose is to collect information available at the conference server. Thus, an <operation> parameter MUST NOT be included in a confsRequest message. In order to retrieve a specific subset of the available conferences, a client may specify a selection filter providing an appropriate xpath query in the OPTIONAL "xpathFilter" parameter of the request. For example, to select only the registered conferences, a possible xpathFilter value could be "/ conference-info[conference-description/conference-state/ active='false']". The associated confsResponse message SHOULD contain the list of XCON-URIs in the "confsInfo" parameter. A user, upon receipt of the response message, can interact with the available conference objects through further CCMP messages.
confsRequest消息用于从服务器检索与会议系统当前处理的活动和已注册会议相关联的XCON URI列表。<confUserID>参数必须包含在每个confsRequest/Response消息中，并反映发出请求的会议客户端的XCON-USERID。confsRequest消息中不得包含<confObjID>参数。confsRequest消息属于仅检索类型，因为其唯一目的是收集会议服务器上可用的信息。因此，<operation>参数不能包含在confsRequest消息中。为了检索可用会议的特定子集，客户机可以在请求的可选“xpathFilter”参数中指定一个选择过滤器，提供适当的xpath查询。例如，要仅选择已注册的会议，xpathFilter可能的值可以是“/conference info[conference description/conference state/active='false']”。关联的confsResponse消息应包含“confsInfo”参数中的XCON URI列表。用户在收到响应消息后，可以通过进一步的CCMP消息与可用的会议对象交互。
<!-- confsRequest -->
<!-- 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>
<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 -->
<!-- confsRequestType -->
<xs:element name="confsRequest" type="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>
<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>
<!-- confsResponse -->
<!-- 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>
<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 -->
<!-- confsResponseType -->
<xs:element name="confsResponse" type="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>
<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>
Figure 5: Structure of the confsRequest and confsResponse Messages
图5:confsRequest和confsResponse消息的结构
Through a blueprintRequest, a client can manipulate the conference object associated with a specified blueprint. Along with the <confUserID> parameter, the request MUST include the <confObjID> and the <operation> parameters. Again, the <confUserID> parameter MUST be included in every blueprintRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. The <confObjID> parameter MUST contain the XCON-URI of the blueprint, which might have been previously retrieved through a blueprintsRequest message.
通过blueprintRequest，客户机可以操纵与指定蓝图关联的会议对象。除了<confUserID>参数外，请求还必须包括<confObjID>和<operation>参数。同样，每个blueprintRequest/Response消息中必须包含<confUserID>参数，并反映发出请求的会议客户端的XCON-USERID。<confObjID>参数必须包含blueprint的XCON-URI，这可能是以前通过blueprintsRequest消息检索到的。
The blueprintRequest message SHOULD NOT contain an <operation> parameter with a value other than "retrieve". An <operation> parameter with a value of "create", "update", or "delete" SHOULD NOT be included in a blueprintRequest message except in the case of privileged users (e.g., the conference server administration staff), who might authenticate themselves by the mean of the "subject" request parameter.
blueprintRequest消息不应包含值不是“retrieve”的<operation>参数。blueprintRequest消息中不应包含值为“创建”、“更新”或“删除”的<operation>参数，特权用户（如会议服务器管理人员）除外，他们可能通过“subject”请求参数对自己进行身份验证。
A blueprintRequest/retrieve carrying a <confObjID> parameter whose value is not associated with one of the available system's blueprints, will generate, on the server's side, a blueprintResponse message containing a <response-code> of "404". This also holds for the case in which the mentioned <confObjID> parameter value is related to an existing conference document stored at the server, but associated with an actual conference (be it active or registered) or with a sidebar rather than a blueprint.
blueprintRequest/retrieve包含一个<confObjID>参数，该参数的值与一个可用的系统蓝图无关，它将在服务器端生成一个blueprintResponse消息，其中包含一个<response code>为“404”。这也适用于以下情况：所提及的<confObjID>参数值与存储在服务器上的现有会议文档相关，但与实际会议（无论是活动的还是注册的）或与侧栏而不是蓝图相关。
For a <response-code> of "200" in a "retrieve" operation, the <blueprintInfo> parameter MUST be included in the blueprintResponse message. The <blueprintInfo> parameter contains the conference document associated with the blueprint as identified by the <confObjID> parameter specified in the blueprintRequest.
对于“检索”操作中的<response code>为“200”，blueprintInfo>参数必须包含在blueprintResponse消息中。<blueprintInfo>参数包含与blueprintRequest中指定的<confObjID>参数标识的蓝图相关联的会议文档。
<!-- blueprintRequest -->
<!-- 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>
<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 -->
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="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>
<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>
<!-- blueprintResponse -->
<!-- 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>
<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 -->
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="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>
<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>
Figure 6: Structure of the blueprintRequest and blueprintResponse Messages
图6:blueprintRequest和blueprintResponse消息的结构
With a confRequest message, CCMP clients can manipulate conference objects associated with either active or registered conferences. The <confUserID> parameter MUST be included in every confRequest/Response message and reflect the XCON-USERID of the conferencing client issuing the request. confRequest and confResponse messages MUST also include an <operation> parameter. ConfResponse messages MUST return to the requestor a <response-code> and MAY contain a <response-string> explaining it. Depending upon the type of operation, a <confObjID> and <confInfo> parameter MAY be included in the confRequest and response. For each type of operation, the text below describes whether the <confObjID> and <confInfo> parameters need to be included in the confRequest and confResponse messages.
通过confRequest消息，CCMP客户端可以操纵与活动会议或已注册会议关联的会议对象。<Confserid>参数必须包含在每个confRequest/Response消息中，并反映发出请求的会议客户端的XCON-USERID。confRequest和confResponse消息还必须包含<operation>参数。ConfResponse消息必须向请求者返回<response code>，并且可能包含解释它的<response string>。根据操作类型，confRequest和response中可能包含<ConfBjid>和<confInfo>参数。对于每种类型的操作，下面的文本描述了confRequest和confResponse消息中是否需要包含<confObjID>和<confInfo>参数。
The creation case deserves care. To create a new conference through a confRequest message, two approaches can be considered:
创作案例值得关注。要通过confRequest消息创建新会议，可以考虑两种方法：
1. Creation through explicit cloning: the <confObjID> parameter MUST contain the XCON-URI of the blueprint or of the conference to be cloned, while the <confInfo> parameter MUST NOT be included in the confRequest. Note that cloning of an active conference is only done in the case of a sidebar operation per the XCON framework and as described in Section 5.3.8.
1. 通过显式克隆创建：<confObjID>参数必须包含要克隆的蓝图或会议的XCON-URI，而<confInfo>参数不得包含在confRequest中。请注意，活动会议的克隆仅在根据XCON框架进行侧栏操作的情况下进行，如第5.3.8节所述。
2. Creation through implicit cloning (also known as "direct creation"): the <confObjID> parameter MUST NOT be included in the request and the CCMP client can describe the desired conference to be created using the <confInfo> parameter. If no <confInfo> parameter is provided in the request, the new conference will be created as a clone of the system default blueprint.
2. 通过隐式克隆创建（也称为“直接创建”）：请求中不得包含<confObjID>参数，CCMP客户端可以使用<confInfo>参数描述要创建的所需会议。如果请求中未提供<confInfo>参数，则新会议将作为系统默认蓝图的克隆创建。
In both creation cases, the confResponse, for a successful completion of a "create" operation, contains a <response-code> of "200" and MUST contain the XCON-URI of the newly created conference in the <confObjID> parameter, in order to allow the conferencing client to manipulate that conference through following CCMP requests. In addition, the <confInfo> parameter containing the conference document created MAY be included, at the discretion of the conferencing system implementation, along with the REQUIRED <version> parameter initialized at "1", since, at creation time, the conference object is at its first version.
在这两种创建情况下，为了成功完成“创建”操作，confResponse包含<response code>为“200”，并且必须在<ConfBjId>参数中包含新创建会议的XCON-URI，以便允许会议客户端通过以下CCMP请求操纵该会议。此外，包含创建的会议文档的<confInfo>参数可以包括在“1”处初始化的所需<version>参数中，这取决于会议系统实现，因为在创建时，会议对象处于其第一个版本。
In the case of a confRequest with an <operation> parameter of "retrieve", the <confObjID> parameter representing the XCON-URI of the target conference MUST be included and the <confInfo> parameter MUST NOT be included in the request. The conference server MUST ignore any <confInfo> parameter that is received in a confRequest "retrieve" operation. If the confResponse for the retrieve operation contains a <response-code> of "200", the <confInfo> parameter MUST be included in the response. The <confInfo> parameter MUST contain the entire conference document describing the target conference object in its current state. The current state of the retrieved conference object MUST also be reported in the proper "version" response parameter.
如果confRequest的<operation>参数为“retrieve”，则表示目标会议的XCON-URI的<ConfBjid>参数必须包含在请求中，而<confInfo>参数不得包含在请求中。会议服务器必须忽略confRequest“retrieve”操作中接收到的任何<confInfo>参数。如果检索操作的confResponse包含<response code>为“200”，则响应中必须包含<confInfo>参数。<confInfo>参数必须包含描述目标会议对象当前状态的整个会议文档。还必须在适当的“版本”响应参数中报告检索到的会议对象的当前状态。
In case of a confRequest with an <operation> parameter of "update", the <confInfo> and <confObjID> parameters MUST be included in the request. The <confInfo> represents an object of type "conference-type" containing all the changes to be applied to the conference whose identifier has the same value as the <confObjID> parameter. Note that, in such a case, though the <confInfo> parameter indeed has to follow the rules indicated in the XCON data model, it does not represent the entire updated version of the target conference, since it conveys just the modifications to apply to that conference. For example, in order to change the conference title, the <confInfo> parameter will be of the form:
如果confRequest的<operation>参数为“update”，则请求中必须包含<confInfo>和<ConfBjid>参数。<confInfo>表示类型为“conference type”的对象，其中包含要应用于会议的所有更改，其标识符的值与<confObjID>参数的值相同。请注意，在这种情况下，尽管<confInfo>参数确实必须遵循XCON数据模型中指示的规则，但它并不代表目标会议的整个更新版本，因为它只传递应用于该会议的修改。例如，为了更改会议标题，<confInfo>参数的形式如下：
<confInfo entity="xcon:8977777@example.com">
<conference-description>
<display-text> *** NEW CONFERENCE TITLE *** </display-text>
</conference-description>
</confInfo>
<confInfo entity="xcon:8977777@example.com">
<conference-description>
<display-text> *** NEW CONFERENCE TITLE *** </display-text>
</conference-description>
</confInfo>
Figure 7: Updating a Conference Object: Modifying the Title of a Conference
图7：更新会议对象：修改会议标题
Similarly, to remove the title of an existing conference, a confRequest/update carrying the following <confInfo> parameter would do the job.
类似地，要删除现有会议的标题，携带以下<confInfo>参数的confRequest/update将完成此工作。
<confInfo entity="xcon:8977777@example.com">
<conference-description>
<display-text/>
</conference-description>
</confInfo>
<confInfo entity="xcon:8977777@example.com">
<conference-description>
<display-text/>
</conference-description>
</confInfo>
Figure 8: Updating a Conference Object: Removing the Title of a Conference
图8：更新会议对象：删除会议标题
In the case of a confResponse/update with a <response-code> of "200", no additional information is REQUIRED in the response message, which means the return of a <confInfo> parameter is OPTIONAL. A subsequent confRequest/retrieve transaction might provide the CCMP client with the current status of the conference after the modification, or the notification protocol might address that task as well. A <response-code> of "200" indicates that the conference object has been changed according to the request by the conference server. The <version> parameter MUST be enclosed in the confResponse/update message, in order to let the client understand what is the current conference-object version, upon the applied modifications. A <response-code> of "409" indicates that the changes reflected in the <confInfo> parameter of the request are not feasible. This could be due to policies, requestor roles, specific privileges, unacceptable values, etc., with the reason specific to a conferencing system and its configuration. Together with a <response-code> of "409", the <version> parameter MUST be attached in the confResponse/update, allowing the client to later retrieve the current version of the target conference if the one she attempted to modify was not the most up to date.
如果confResponse/update的<response code>为“200”，则响应消息中不需要额外信息，这意味着返回<confInfo>参数是可选的。后续confRequest/retrieve事务可能向CCMP客户端提供修改后会议的当前状态，或者通知协议也可能处理该任务。“200”的<response code>表示会议对象已根据会议服务器的请求进行了更改。<version>参数必须包含在confResponse/update消息中，以便客户端在应用修改后了解当前会议对象版本。“409”的<response code>表示请求的<confInfo>参数中反映的更改不可行。这可能是由于策略、请求者角色、特定权限、不可接受的值等，以及特定于会议系统及其配置的原因。与“409”的<response code>一起，<version>参数必须附加在confResponse/update中，如果她试图修改的会议不是最新的，则允许客户端稍后检索目标会议的当前版本。
In the case of a confRequest with an <operation> parameter of "delete", the <confObjID> parameter representing the XCON-URI of the target conference MUST be included while the <confInfo> parameter MUST NOT be included in the request. The conference server MUST ignore any <confInfo> parameter that is received within such a request. The confResponse MUST contain the same value for the <confObjID> parameter that was included in the confRequest. If the confResponse/delete operation contains a <response-code> of "200", the conference indicated in the <confObjID> parameter has been successfully deleted. A confResponse/delete with a <response-code> of "200" MUST NOT contain the <confInfo> parameter. The <version> parameter SHOULD NOT be returned in any confResponse/delete. If the conference server cannot delete the conference referenced by the <confObjID> parameter received in the confRequest because it is the parent of another conference object that is in use, the conference server MUST return a <response-code> of "425".
如果confRequest的<operation>参数为“delete”，则表示目标会议的XCON-URI的<confObjID>参数必须包含在请求中，而<confInfo>参数不得包含在请求中。会议服务器必须忽略在此类请求中接收到的任何<confInfo>参数。confResponse必须包含与confRequest中包含的参数相同的值。如果confResponse/delete操作包含<response code>为“200”，则<ConfBjid>参数中指示的会议已成功删除。<response code>为“200”的confResponse/delete不能包含<confInfo>参数。<version>参数不应在任何confResponse/delete中返回。如果会议服务器无法删除confRequest中接收到的<confObjID>参数所引用的会议，因为它是正在使用的另一个会议对象的父对象，则会议服务器必须返回<response code>“425”。
A confRequest with an <operation> parameter of "retrieve", "update", or "delete" carrying a <confObjID> parameter which is not associated with one of the conferences (active or registered) that the system is holding will generate, on the server's side, a confResponse message containing a <response-code> of "404". This also holds for the case in which the mentioned <confObjID> parameter is related to an existing conference object stored at the server, but associated with a blueprint or with a sidebar rather than an actual conference.
带有<operation>参数“retrieve”、“update”或“delete”的confRequest带有<confObjID>参数，该参数与系统正在举行的一个会议（活动或注册）无关，将在服务器端生成包含<response code>的“404”confResponse消息。这也适用于所提到的<confObjID>参数与存储在服务器上的现有会议对象相关，但与蓝图或侧栏相关，而不是与实际会议相关的情况。
The schema for the confRequest/confResponse pair is shown in Figure 9.
confRequest/confResponse对的模式如图9所示。
<!-- confRequest -->
<!-- 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>
<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 -->
<!-- confRequestType -->
<xs:element name="confRequest" type="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>
<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>
<!-- confResponse -->
<!-- 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>
<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 -->
<!-- confResponseType -->
<xs:element name="confResponse" type="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>
<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>
Figure 9: Structure of the confRequest and confResponse Messages
图9:confRequest和confResponse消息的结构
The usersRequest message allows a client to manipulate the <users> element of the conference object represented by the <confObjID> parameter. The <users> element contains the list of <user> elements associated with conference participants, the list of the users to which access to the conference is allowed/denied, conference participation policies, etc. The <confObjID> parameter MUST be included in a usersRequest message.
usersRequest消息允许客户端操作由<confObjID>参数表示的会议对象的<users>元素。<users>元素包含与会议参与者相关的<user>元素列表、允许/拒绝访问会议的用户列表、会议参与策略等。<confObjID>参数必须包含在usersRequest消息中。
A <usersInfo> parameter MAY be included in a usersRequest message depending upon the operation. If the <usersInfo> parameter is included in the usersRequest message, the parameter MUST be compliant with the <users> field of the XCON data model.
根据操作的不同，usersRequest消息中可能包含<usersInfo>参数。如果usersRequest消息中包含<usersInfo>参数，则该参数必须符合XCON数据模型的<users>字段。
Two operations are allowed for a usersRequest message:
usersRequest消息允许两种操作：
1. "retrieve": In this case the request MUST NOT include a
<usersInfo> parameter, while the successful response MUST contain
the desired <users> element in the <usersInfo> parameter. The
1. "retrieve": In this case the request MUST NOT include a
<usersInfo> parameter, while the successful response MUST contain
the desired <users> element in the <usersInfo> parameter. The
conference server MUST ignore a <usersInfo> parameter if it is received in a request with an <operation> parameter of "retrieve".
如果在带有<operation>参数“retrieve”的请求中接收到<usersInfo>参数，则会议服务器必须忽略该参数。
2. "update": In this case, the <usersInfo> parameter MUST contain the modifications to be applied to the <users> element indicated. If the <response-code> is "200", then the <usersInfo> parameter SHOULD NOT be returned. Any <usersInfo> parameter that is returned SHOULD be ignored. A <response-code> of "426" indicates that the conferencing client is not allowed to make the changes reflected in the <usersInfo> contained in the usersRequest message. This could be due to policies, roles, specific privileges, etc., with the reason being specific to a conferencing system and its configuration.
2. “更新”：在这种情况下，<usersInfo>参数必须包含要应用于所示<users>元素的修改。如果<response code>为“200”，则不应返回<usersInfo>参数。应忽略返回的任何<usersInfo>参数。“426”的<response code>表示不允许会议客户端进行usersRequest消息中包含的<usersInfo>中反映的更改。这可能是由于策略、角色、特定权限等造成的，原因是特定于会议系统及其配置。
Operations of "create" and "delete" are not applicable to a usersRequest message and MUST NOT be considered by the server, which means that a <response-code> of "403" MUST be included in the usersResponse message.
“创建”和“删除”操作不适用于usersRequest消息，服务器不得考虑，这意味着usersResponse消息中必须包含“403”的<response code>。
<!-- usersRequest -->
<!-- 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>
<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 -->
<!-- usersRequestType -->
<xs:element name="usersRequest" type="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>
<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>
<!-- usersResponse -->
<!-- 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>
<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 -->
<!-- usersResponseType -->
<xs:element name="usersResponse" type="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>
<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>
Figure 10: Structure of the usersRequest and usersResponse Messages
图10:usersRequest和usersResponse消息的结构
A userRequest message is used to manipulate <user> elements inside a conference document associated with a conference identified by the <confObjID> parameter. Besides retrieving information about a specific conference user, the message is used to request that the conference server either create, modify, or delete information about a user. A userRequest message MUST include the <confObjID> and the <operation> parameters, and it MAY include a <userInfo> parameter containing the detailed user's information depending upon the operation and whether the <userInfo> has already been populated for a specific user. Note that a user may not necessarily be a conferencing control client (i.e., some participants in a conference are not "XCON aware").
userRequest消息用于操纵与由<confObjID>参数标识的会议相关联的会议文档中的<user>元素。除了检索有关特定会议用户的信息外，该消息还用于请求会议服务器创建、修改或删除有关用户的信息。userRequest消息必须包括<confObjID>和<operation>参数，并且它可能包括<userInfo>参数，该参数包含详细的用户信息，具体取决于操作以及是否已经为特定用户填充了<userInfo>。请注意，用户不一定是会议控制客户端（即，会议中的一些参与者不是“XCON感知的”）。
An XCON-USERID SHOULD be assigned to each and every user subscribed to the system. In such a way, a user who is not a conference participant can make requests (provided she has successfully passed authorization and authentication checks), like creating a conference or retrieving conference information.
应为每个订阅系统的用户分配一个XCON-USERID。通过这种方式，非会议参与者的用户可以发出请求（前提是她已成功通过授权和身份验证检查），如创建会议或检索会议信息。
Conference users can be created in a number of different ways. In each of these cases, the <operation> parameter MUST be set to "create" in the userRequest message. Each of the userResponse messages for these cases MUST include the <confObjID>, <confUserID>, <operation>, and <response-code> parameters. In the case of a <response-code> of "200", the userResponse message MAY include the <userInfo> parameter depending upon the manner in which the user was created:
会议用户可以通过多种不同的方式创建。在每种情况下，必须在userRequest消息中将<operation>参数设置为“create”。这些情况下的每个userResponse消息必须包括<confObjID>、<confUserID>、<operation>和<response code>参数。在<response code>为“200”的情况下，userResponse消息可以包括<userInfo>参数，这取决于创建用户的方式：
o A conferencing client with an XCON-USERID adds itself to the conference: In this case, the <userInfo> parameter MAY be included in the userRequest. The <userInfo> parameter MUST contain a <user> element (compliant with the XCON data model) and the 'entity' attribute MUST be set to a value that represents the XCON-USERID of the user initiating the request. No additional parameters beyond those previously described are required in the userResponse message, in the case of a <response-code> of "200".
o 具有XCON-USERID的会议客户端将自己添加到会议中：在这种情况下，<userInfo>参数可能包含在userRequest中。<userInfo>参数必须包含<user>元素（符合XCON数据模型），并且“entity”属性必须设置为表示发起请求的用户的XCON-USERID的值。在<response code>为“200”的情况下，userResponse消息中不需要除上述参数以外的其他参数。
o A conferencing client acts on behalf of another user whose XCON-USERID is known: In this case, the <userInfo> parameter MUST be included in the userRequest. The <userInfo> parameter MUST contain a <user> element and the 'entity' attribute value MUST be set to the XCON-USERID of the other user in question. No additional parameters beyond those previously described are required in the userResponse message, in the case of a <response-code> of "200".
o 会议客户端代表另一个已知XCON-USERID的用户：在这种情况下，<userInfo>参数必须包含在userRequest中。<userInfo>参数必须包含<user>元素，“entity”属性值必须设置为其他用户的XCON-USERID。在<response code>为“200”的情况下，userResponse消息中不需要除上述参数以外的其他参数。
o A conferencing client who has no XCON-USERID and who wants to enter, via CCMP, a conference whose identifier is known: In this case, a side effect of the request is that the user is provided with a new XCON-USERID (created by the server) carried inside the <confUserID> parameter of the response. This is the only case in which a CCMP request can be valid though carrying a void <confUserID> parameter. A <userInfo> parameter MUST be enclosed in the request, providing at least a contact URI of the joining client, in order to let the focus initiate the signaling phase needed to add her to the conference. The mandatory 'entity' attribute of the <userInfo> parameter in the request MUST be filled with a placeholder value with the user part of the XCON-USERID containing a value of AUTO_GENERATE_X as described in Section 4.3, to conform to the rules contained in the XCON data model XML schema. The messages (userRequest and userResponse) in this case should look like the following:
o 没有XCON-USERID且希望通过CCMP进入其标识符已知的会议的会议客户端：在这种情况下，请求的一个副作用是向用户提供一个新的XCON-USERID（由服务器创建），该ID包含在响应的<confUserID>参数中。这是CCMP请求通过携带void<confUserID>参数而有效的唯一情况。请求中必须包含一个<userInfo>参数，至少提供加入客户端的联系人URI，以便让焦点启动将其添加到会议所需的信令阶段。请求中<userInfo>参数的强制“entity”属性必须用占位符值填充，XCON-USERID的用户部分包含AUTO_GENERATE_X值，如第4.3节所述，以符合XCON数据模型XML模式中包含的规则。本例中的消息（userRequest和userResponse）应如下所示：
Request fields:
请求字段：
confUserID=null;
confObjID=confXYZ;
operation=create;
userInfo=
confUserID=null;
confObjID=confXYZ;
operation=create;
userInfo=
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <endpoint entity="sip:GHIL345@example.com"> ...
<userInfo entity=“xcon userid:AUTO\u生成_1@example.com“><endpoint entity=“sip:GHIL345@example.com"> ...
Response fields (in case of success):
响应字段（如果成功）：
confUserID=user345;
confObjID=confXYZ;
operation=create;
response-code=200;
userInfo=null; //or the entire userInfo object
confUserID=user345;
confObjID=confXYZ;
operation=create;
response-code=200;
userInfo=null; //or the entire userInfo object
Figure 11: userRequest and userResponse in the Absence of an xcon-userid
图11：缺少xcon用户ID时的userRequest和userResponse
o A conferencing client is unaware of the XCON-USERID of a third user: In this case, the XCON-USERID in the request, <confUserID>, is the sender's and the 'entity' attribute of the attached <userInfo> parameter is filled with the placeholder value "xcon-userid:AUTO_GENERATE_1@example.com". The XCON-USERID for the third user MUST be returned to the client issuing the request in the 'entity' attribute of the response <userInfo> parameter, if the <response-code> is "200". This scenario is intended to support both the case where a brand new conferencing system user is added to a conference by a third party (i.e., a user who has not yet been provided with an XCON-USERID) and the case where the CCMP client issuing the request does not know the to-be-added user's XCON-USERID (which means such an identifier could already exist on the server's side for that user). In this last case, the conference server is in charge of avoiding XCON-URI duplicates for the same conferencing client, looking at key fields in the request-provided <userInfo> parameter, such as the signaling URI. If the joining user is brand new, then the generation of a new XCON-USERID is needed; otherwise, if that user exists already, the server must recover the corresponding XCON-USERID.
o 会议客户端不知道第三个用户的XCON-USERID：在这种情况下，请求中的XCON-USERID，<confUserID>，是发送方的，附加的<userInfo>参数的“实体”属性由占位符值“XCON USERID:AUTO_GENERATE”填充_1@example.com". 如果<response code>为“200”，则必须将第三个用户的XCON-USERID返回到响应<userInfo>参数的“entity”属性中发出请求的客户端。此场景旨在支持第三方（即尚未提供XCON-USERID的用户）将全新的会议系统用户添加到会议的情况，以及发出请求的CCMP客户端不知道要添加的用户的XCON-USERID的情况（这意味着该用户的服务器端可能已经存在这样的标识符）。在最后一种情况下，会议服务器负责避免同一会议客户端的XCON-URI重复，查看请求中提供的<userInfo>参数中的关键字段，如信令URI。如果加入用户是全新的，则需要生成新的XCON-USERID；否则，如果该用户已经存在，则se服务器必须恢复相应的XCON-USERID。
In the case of a userRequest with an <operation> parameter of
"retrieve", the <confObjID> parameter representing the XCON-URI of
the target conference MUST be included. The <confUserID>, containing
the CCMP client's XCON-USERID, MUST also be included in the
In the case of a userRequest with an <operation> parameter of
"retrieve", the <confObjID> parameter representing the XCON-URI of
the target conference MUST be included. The <confUserID>, containing
the CCMP client's XCON-USERID, MUST also be included in the
userRequest message. If the client wants to retrieve information about her profile in the specified conference, no <userInfo> parameter is needed in the retrieve request. On the other hand, if the client wants to obtain someone else's info within the given conference, she MUST include in the userRequest/retrieve a <userInfo> parameter whose 'entity' attribute conveys the desired user's XCON-USERID. If the userResponse for the retrieve operation contains a <response-code> of "200", the <userInfo> parameter MUST be included in the response.
用户请求消息。如果客户端希望在指定的会议中检索有关其配置文件的信息，则在检索请求中不需要<userInfo>参数。另一方面，如果客户端希望在给定会议中获取其他人的信息，则必须在userRequest/retrieve中包含一个<userInfo>参数，该参数的“entity”属性传递所需用户的XCON-USERID。如果检索操作的userResponse包含<response code>为“200”，则响应中必须包含<userInfo>参数。
In case of a userRequest with an <operation> parameter of "update", the <confObjID>, <confUserID>, and <userInfo> parameters MUST be included in the request. The <userInfo> parameter is of type "user-type" and contains all the changes to be applied to a specific <user> element in the conference object identified by the <confObjID> parameter in the userRequest message. The user to be modified is identified through the 'entity' attribute of the <userInfo> parameter included in the request. In the case of a userResponse with a <response-code> of "200", no additional information is required in the userResponse message. A <response-code> of "200" indicates that the referenced <user> element has been updated by the conference server. A <response-code> of "426" indicates that the conferencing client is not allowed to make the changes reflected in the <userInfo> in the initial request. This could be due to policies, roles, specific privileges, etc., with the reason specific to a conferencing system and its configuration.
如果userRequest的<operation>参数为“update”，则请求中必须包含<confObjID>、<confUserID>和<userInfo>参数。<userInfo>参数的类型为“user type”，包含要应用于由userRequest消息中的<confObjID>参数标识的会议对象中特定<user>元素的所有更改。要修改的用户通过请求中包含的<userInfo>参数的“entity”属性进行标识。如果userResponse的<response code>为“200”，则userResponse消息中不需要额外的信息。“200”的<response code>表示引用的<user>元素已由会议服务器更新。“426”的<response code>表示不允许会议客户端进行初始请求中<userInfo>中反映的更改。这可能是由于策略、角色、特定权限等，其原因特定于会议系统及其配置。
In the case of a userRequest with an <operation> parameter of "delete", the <confObjID> representing the XCON-URI of the target conference MUST be included. The <confUserID> parameter, containing the CCMP client's XCON-USERID, MUST be included in the userRequest message. If the client wants to exit the specified conference, no <userInfo> parameter is needed in the delete request. On the other hand, if the client wants to remove another participant from the given conference, she MUST include in the userRequest/delete a <userInfo> parameter whose 'entity' attribute conveys the XCON-USERID of that participant. The userResponse MUST contain the same value for the <confObjID> parameter that was included in the <confObjID> parameter in the userRequest. The userResponse MUST contain a <response-code> of "200" if the target <user> element has been successfully deleted. If the userResponse for the delete operation contains a <response-code> of "200", the userResponse MUST NOT contain the <userInfo> parameter.
如果userRequest的<operation>参数为“delete”，则必须包括表示目标会议的XCON-URI的<confObjID>。userRequest消息中必须包含包含CCMP客户端的XCON-USERID的<confUserID>参数。如果客户端希望退出指定的会议，则删除请求中不需要<userInfo>参数。另一方面，如果客户端希望从给定会议中删除另一个参与者，则必须在userRequest/delete中包含一个<userInfo>参数，该参数的“entity”属性表示该参与者的XCON-USERID。userResponse必须包含与userRequest中的<confObjID>参数中包含的<confObjID>参数相同的值。如果目标<user>元素已成功删除，则userResponse必须包含<response code>的“200”。如果删除操作的userResponse包含<response code>的“200”，则userResponse不能包含<userInfo>参数。
<!-- userRequest -->
<!-- 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>
<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 -->
<!-- userRequestType -->
<xs:element name="userRequest" type="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>
<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>
<!-- userResponse -->
<!-- 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>
<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 -->
<!-- userResponseType -->
<xs:element name="userResponse" type="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>
<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>
Figure 12: Structure of the userRequest and userResponse Messages
图12:userRequest和userResponse消息的结构
A sidebarsByValRequest message is used to execute a retrieve-only operation on the <sidebars-by-val> field of the conference object represented by the <confObjID>. The sidebarsByValRequest message is of a retrieve-only type, so an <operation> parameter MUST NOT be included in a sidebarsByValRequest message. As with blueprints and conferences, CCMP allows for the use of xpath filters whenever a selected subset of the sidebars available at the server's side has to be retrieved by the client. This applies both to sidebars by reference and sidebars by value. A sidebarsByValResponse message with a <response-code> of "200" MUST contain a <sidebarsByValInfo> parameter containing the desired <sidebars-by-val> element. A sidebarsByValResponse message MUST return to the client a <version> element related to the current version of the main conference object (i.e., the one whose identifier is contained in the <confObjID> field of the request) with which the sidebars in question are associated. The <sidebarsByValInfo> parameter contains the list of the conference objects associated with the sidebars by value derived from the main conference. The retrieved sidebars can then be updated or deleted using the sidebarByValRequest message, which is described in Section 5.3.8.
sidebarsByValRequest消息用于在会议对象的<confObjID>表示的<sidebars by val>字段上执行仅检索操作。sidebarsByValRequest消息属于仅检索类型，因此sidebarsByValRequest消息中不得包含<operation>参数。与蓝图和会议一样，当客户端必须检索服务器端可用的边栏的选定子集时，CCMP允许使用xpath过滤器。这既适用于引用侧栏，也适用于值侧栏。<response code>为“200”的sidebarsByValResponse消息必须包含一个<sidebarsByValInfo>参数，该参数包含所需的<sidebars by val>元素。sidebarsByValResponse消息必须向客户端返回与主会议对象（即，其标识符包含在请求的<confObjID>字段中的对象）的当前版本相关的<version>元素，该元素与相关的侧栏相关联。<sidebarsByValInfo>参数包含通过从主会议派生的值与侧栏关联的会议对象列表。然后可以使用sidebarByValRequest消息更新或删除检索到的侧栏，如第5.3.8节所述。
<!-- sidebarsByValRequest -->
<!-- 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>
<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 -->
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="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>
<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>
<!-- sidebarsByValResponse -->
<!-- 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>
<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 -->
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="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>
<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>
Figure 13: Structure of the sidebarsByValRequest and sidebarsByValResponse Messages
图13:sidebarsByValRequest和sidebarsByValResponse消息的结构
A sidebarByValRequest message MUST contain the <operation> parameter, which distinguishes among retrieval, creation, modification, and deletion of a specific sidebar. The other required parameters depend upon the type of operation.
sidebarByValRequest消息必须包含<operation>参数，用于区分特定侧栏的检索、创建、修改和删除。其他所需参数取决于操作类型。
In the case of a "create" operation, the <confObjID> parameter MUST be included in the sidebyValRequest message. In this case, the <confObjID> parameter contains the XCON-URI of the main conference in which the sidebar has to be created. If no "sidebarByValInfo" parameter is included, the sidebar is created by cloning the main conference, as envisioned in the XCON framework [RFC5239] following the implementation specific cloning rules. Otherwise, similar to the case of direct creation, the sidebar conference object is built on the basis of the "sidebarByValInfo" parameter provided by the requestor. As a consequence of a sidebar-by-val creation, the conference server MUST update the main conference object reflected by the <confObjID> parameter in the sidebarbyValRequest/create message introducing the new sidebar object as a new <entry> in the proper section <sidebars-by-val>. The newly created sidebar conference object MAY be included in the sidebarByValResponse in the <sidebarByValInfo> parameter, if the <response-code> is "200". The XCON-URI of the newly created sidebar MUST appear in the <confObjID> parameter of the response. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the addition of the sidebar to the conference.
在“创建”操作的情况下，sidebyValRequest消息中必须包含<confObjID>参数。在这种情况下，<confObjID>参数包含必须在其中创建边栏的主会议的XCON-URI。如果未包含“sidebarByValInfo”参数，则按照XCON框架[RFC5239]中的设想，按照特定于实现的克隆规则，通过克隆主会议来创建侧栏。否则，与直接创建的情况类似，侧栏会议对象是基于请求者提供的“sidebarByValInfo”参数构建的。作为val创建侧栏的结果，会议服务器必须更新sidebarbyValRequest/create消息中的<confObjID>参数反映的主会议对象，该消息将新侧栏对象作为适当部分<sidebars by val>中的新<entry>引入。如果<response code>为“200”，则新创建的侧栏会议对象可能包含在<sidebarByValInfo>参数中的sidebarByValResponse中。新创建的边栏的XCON-URI必须出现在响应的<confObjID>参数中。会议服务器可以通知已订阅会议事件包且有权接收侧栏添加到会议的通知的任何会议客户端。
In the case of a sidebarByValRequest message with an <operation> parameter of "retrieve", the URI for the conference object created for the sidebar (received in response to a create operation or in a sidebarsByValResponse message) MUST be included in the <confObjID> parameter in the request. This retrieve operation is handled by the conference server in the same manner as in the case of an <operation> parameter of "retrieve" included in a confRequest message, as described in Section 5.3.4.
如果sidebarByValRequest消息的<operation>参数为“retrieve”，则为侧栏创建的会议对象的URI（响应创建操作或在sidebarsByValResponse消息中接收）必须包含在请求的<confObjID>参数中。如第5.3.4节所述，会议服务器处理该检索操作的方式与confRequest消息中包含的“retrieve”参数的<operation>相同。
In the case of a sidebarByValRequest message with an <operation> parameter of "update", the <sidebarByValInfo> MUST also be included in the request. The <confObjID> parameter contained in the request message identifies the specific sidebar instance to be updated. An update operation on the specific sidebar instance contained in the <sidebarByValInfo> parameter is handled by the conference server in the same manner as an update operation on the conference instance as reflected by the <confInfo> parameter included in a confRequest message as detailed in Section 5.3.4. A sidebarByValResponse message MUST return to the client a <version> element related to the current version of the sidebar whose identifier is contained in the <confObjID> field of the request.
如果sidebarByValRequest消息的<operation>参数为“update”，则请求中还必须包含<sidebarByValInfo>。请求消息中包含的<confObjID>参数标识要更新的特定侧栏实例。<sidebarByValInfo>参数中包含的特定侧栏实例上的更新操作由会议服务器以与会议实例上的更新操作相同的方式处理，如第5.3.4节所述，confRequest消息中包含的<confInfo>参数所反映。sidebarByValResponse消息必须向客户端返回一个与侧栏当前版本相关的<version>元素，其标识符包含在请求的<confObjID>字段中。
If an <operation> parameter of "delete" is included in the sidebarByVal request, the <sidebarByValInfo> parameter MUST NOT be included in the request. Any <sidebarByValInfo> included in the request MUST be ignored by the conference server. The URI for the conference object associated with the sidebar MUST be included in the <confObjID> parameter in the request. If the specific conferencing user, as reflected by the <confUserID> parameter, in the request is authorized to delete the conference, the conference server deletes the conference object reflected by the <confObjID> parameter and updates the data in the conference object from which the sidebar was cloned. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the deletion of the sidebar from the conference.
如果sidebarByVal请求中包含<operation>参数“delete”，则请求中不得包含<sidebarByValInfo>参数。会议服务器必须忽略请求中包含的任何<sidebarByValInfo>。与侧边栏关联的会议对象的URI必须包含在请求的<confObjID>参数中。如果请求中的<confUserID>参数所反映的特定会议用户被授权删除会议，则会议服务器将删除<Confubjid>参数所反映的会议对象，并更新从中克隆侧栏的会议对象中的数据。会议服务器可以通知已订阅会议事件包且有权接收从会议中删除侧栏通知的任何会议客户端。
If a sidebarByValRequest with an <operation> parameter of "retrieve", "update", or "delete" carries a <confObjID> parameter which is not associated with any existing sidebar-by-val, a confResponse message containing a <response-code> of "404" will be generated on the server's side. This also holds for the case in which the mentioned <confObjID> parameter is related to an existing conference object stored at the server, but associated with a blueprint or with an actual conference or with a sidebar-by-ref rather than a sidebar-by-val.
如果带有<operation>参数“retrieve”、“update”或“delete”的sidebarByValRequest包含一个<confObjID>参数，该参数与val未关联的任何现有侧边栏，则服务器端将生成一条包含<response code>为“404”的confResponse消息。这也适用于以下情况：所述<confObjID>参数与存储在服务器上的现有会议对象相关，但与蓝图或实际会议相关，或与按ref而不是按val的边栏相关。
<!-- sidebarByValRequest -->
<!-- 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>
<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 -->
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="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>
<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>
<!-- sidebarByValResponse -->
<!-- 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>
<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 -->
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="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>
<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>
Figure 14: Structure of the sidebarByValRequest and sidebarByValResponse Messages
图14:sidebarByValRequest和sidebarByValResponse消息的结构
Similar to the sidebarsByValRequest, a sidebarsByRefRequest can be invoked to retrieve the <sidebars-by-ref> element of the conference object identified by the <confObjID> parameter. The sidebarsByRefRequest message is of a retrieve-only type, so an <operation> parameter MUST NOT be included in a sidebarsByRefRequest message. In the case of a <response-code> of "200", the <sidebarsByRefInfo> parameter, containing the <sidebars-by-ref> element of the conference object, MUST be included in the response. The <sidebars-by-ref> element represents the set of URIs of the sidebars associated with the main conference, whose description (in the form of a standard XCON conference document) is external to the main conference itself. Through the retrieved URIs, it is then possible to access single sidebars using the sidebarByRefRequest message, described in Section 5.3.10. A sidebarsByRefResponse message MUST carry back to the client a <version> element related to the current version of the main conference object (i.e., the one whose identifier is contained in the <confObjId> field of the request) with which the sidebars in question are associated.
与sidebarsByValRequest类似，可以调用sidebarsByRefRequest来检索由<confObjID>参数标识的会议对象的<sidebars by ref>元素。sidebarsByRefRequest消息属于仅检索类型，因此sidebarsByRefRequest消息中不得包含<operation>参数。如果<response code>为“200”，则响应中必须包括<sidebarsByRefInfo>参数，该参数包含会议对象的<sidebars by ref>元素。<sidebars by ref>元素表示与主会议相关联的侧栏的URI集，其描述（以标准XCON会议文档的形式）在主会议本身之外。然后，通过检索到的URI，可以使用sidebarByRefRequest消息访问单侧栏，如第5.3.10节所述。sidebarsByRefResponse消息必须向客户端带回与讨论中的侧栏关联的主会议对象（即，其标识符包含在请求的<confObjId>字段中）的当前版本相关的<version>元素。
<!-- sidebarsByRefRequest -->
<!-- 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>
<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 -->
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="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>
<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>
<!-- sidebarsByRefResponse -->
<!-- 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>
<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 -->
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="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>
<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>
Figure 15: Structure of the sidebarsByRefRequest and sidebarsByRefResponse Messages
图15:sidebarsByRefRequest和sidebarsByRefResponse消息的结构
A sidebarByValResponse message MUST return to the client a <version> element related to the current version of the sidebar whose identifier is contained in the <confObjID> field of the request.
sidebarByValResponse消息必须向客户端返回一个与侧栏当前版本相关的<version>元素，其标识符包含在请求的<confObjID>字段中。
In the case of a create operation, the <confObjID> parameter MUST be included in the sidebyRefRequest message. In this case, the <confObjID> parameter contains the XCON-URI of the main conference in which the sidebar has to be created. If no <sidebarByRefInfo> parameter is included, following the XCON framework [RFC5239], the sidebar is created by cloning the main conference, observing the implementation-specific cloning rules. Otherwise, similar to the case of direct creation, the sidebar conference object is built on the basis of the <sidebarByRefInfo> parameter provided by the requestor. If the creation of the sidebar is successful, the conference server MUST update the <sidebars-by-ref> element in the conference object from which the sidebar was created (i.e., as identified by the <confObjID> in the original sidebarByRefRequest), with the URI of the newly created sidebar. The newly created conference object MAY be included in the response in the <sidebarByRefInfo> parameter with a <response-code> of "200". The URI for the conference object associated with the newly created sidebar object MUST appear in the <confObjID> parameter of the response. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the addition of the sidebar to the conference.
对于创建操作，sidebyRefRequest消息中必须包含<confObjID>参数。在这种情况下，<confObjID>参数包含必须在其中创建边栏的主会议的XCON-URI。如果未包含<sidebarByRefInfo>参数，则遵循XCON框架[RFC5239]，通过克隆主会议创建侧栏，并遵守特定于实现的克隆规则。否则，与直接创建的情况类似，侧栏会议对象是基于请求者提供的<sidebarByRefInfo>参数构建的。如果侧栏的创建成功，会议服务器必须使用新创建的侧栏的URI更新从中创建侧栏的会议对象中的<sidebars by ref>元素（即，由原始侧栏中的<confObjID>标识）。新创建的会议对象可以包含在<sidebarByRefInfo>参数的响应中，其<response code>为“200”。与新创建的边栏对象关联的会议对象的URI必须出现在响应的<confObjID>参数中。会议服务器可以通知已订阅会议事件包且有权接收侧栏添加到会议的通知的任何会议客户端。
In the case of a sidebarByRefRequest message with an <operation> parameter of "retrieve", the URI for the conference object created for the sidebar MUST be included in the <confObjID> parameter in the request. A retrieve operation on the <sidebarByRefInfo> is handled by the conference server in the same manner as a retrieve operation on the confInfo included in a confRequest message as detailed in Section 5.3.4.
如果sidebarByRefRequest消息的<operation>参数为“retrieve”，则为侧栏创建的会议对象的URI必须包含在请求的<confObjID>参数中。会议服务器处理<sidebarByRefInfo>上的检索操作的方式与confRequest消息中包含的confInfo上的检索操作相同，详见第5.3.4节。
In the case of a sidebarByRefRequest message with an <operation> parameter of "update", the URI for the conference object created for the sidebar MUST be included in the <confObjID> parameter in the request. The <sidebarByRefInfo> MUST also be included in the request in the case of an "update" operation. An update operation on the <sidebarByRefInfo> is handled by the conference server in the same manner as an update operation on the <confInfo> included in a confRequest message as detailed in Section 5.3.4. A sidebarByRefResponse message MUST carry back to the client a <version> element related to the current version of the sidebar whose identifier is contained in the <confObjID> field of the request.
如果sidebarByRefRequest消息的<operation>参数为“update”，则为侧栏创建的会议对象的URI必须包含在请求的<confObjID>参数中。在“更新”操作的情况下，<sidebarByRefInfo>也必须包含在请求中。会议服务器处理<sidebarByRefInfo>上的更新操作的方式与confRequest消息中包含的<confInfo>上的更新操作相同，详见第5.3.4节。sidebarByRefResponse消息必须将与侧栏当前版本相关的<version>元素带回客户端，侧栏的标识符包含在请求的<confObjID>字段中。
If an <operation> parameter of "delete" is included in the sidebarByRefRequest, the <sidebarByRefInfo> parameter MUST NOT be included in the request. Any <sidebarByRefInfo> included in the request MUST be ignored by the conference server. The URI for the conference object for the sidebar MUST be included in the <confObjID> parameter in the request. If the specific conferencing user as reflected by the <confUserID> parameter in the request is authorized to delete the conference, the conference server SHOULD delete the conference object reflected by the <confObjID> parameter and SHOULD update the <sidebars-by-ref> element in the conference object from which the sidebar was originally cloned. The conference server can notify any conferencing clients that have subscribed to the conference event package and that are authorized to receive the notification of the deletion of the sidebar.
如果sidebarByRefRequest中包含<operation>参数“delete”，则请求中不得包含<sidebarByRefInfo>参数。会议服务器必须忽略请求中包含的任何<sidebarByRefInfo>。侧栏的会议对象的URI必须包含在请求的<confObjID>参数中。如果请求中的<confUserID>参数所反映的特定会议用户被授权删除会议，则会议服务器应删除<Confubjid>参数所反映的会议对象，并应更新最初克隆侧栏的会议对象中的<sidebars by ref>元素。会议服务器可以通知已订阅会议事件包且有权接收侧栏删除通知的任何会议客户端。
If a sidebarByRefRequest with an <operation> parameter of "retrieve", "update", or "delete" carries a <confObjID> parameter that is not associated with any existing sidebar-by-ref, a confResponse message containing a <response-code> of "404" will be generated on the server's side. This also holds for the case in which the value of the mentioned <confObjID> parameter is related to an existing conference object stored at the server, but associated with a blueprint or with an actual conference or with a sidebar-by-val rather than a sidebar-by-ref.
如果带有<operation>参数“retrieve”、“update”或“delete”的sidebarByRefRequest包含一个<confObjID>参数，该参数与任何现有的侧边栏都没有关联，则服务器端将生成一条包含<response code>的“404”confResponse消息。这也适用于以下情况：所述<confObjID>参数的值与存储在服务器上的现有会议对象相关，但与蓝图或实际会议相关，或与val的边栏相关，而不是与sidebar-by-ref相关。
<!-- sidebarByRefRequest -->
<!-- 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>
<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 -->
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="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>
<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>
<!-- sidebarByRefResponse -->
<!-- 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>
<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 -->
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="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>
<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>
Figure 16: Structure of the sidebarByRefRequest and sidebarByRefResponse Messages
图16:sidebarByRefRequest和sidebarByRefResponse消息的结构
In order to allow specifying new request and response pairs for conference control, CCMP defines the extendedRequest and extendedResponse messages. Such messages constitute a CCMP skeleton in which implementers can transport the information needed to realize conference control mechanisms not explicitly envisioned in the CCMP specification; these mechanisms are called, in this context, "extensions". Each extension is assumed to be characterized by an appropriate name that MUST be carried in the extendedRequest/ extendedResponse pair in the provided <extensionName> field. Extension-specific information can be transported in the form of schema-defined XML elements inside the <any> element present in both extendedRequest and extendedResponse.
为了允许为会议控制指定新的请求和响应对，CCMP定义了extendedRequest和extendedResponse消息。此类消息构成CCMP框架，其中实现者可以传输实现CCMP规范中未明确设想的会议控制机制所需的信息；在本文中，这些机制被称为“扩展”。假设每个扩展都有一个适当的名称，该名称必须在提供的<extensionName>字段中的extendedRequest/extendedResponse对中携带。扩展特定的信息可以在extendedRequest和extendedResponse中的<any>元素中以模式定义的XML元素的形式传输。
The conferencing client SHOULD be able to determine the extensions supported by a CCMP server and to recover the XML schema defining the related specific elements by means of an optionsRequest/ optionsResponse CCMP transaction (see Section 5.3.12).
会议客户端应能够确定CCMP服务器支持的扩展，并通过OptionRequest/OptionResponse CCMP事务恢复定义相关特定元素的XML模式（见第5.3.12节）。
The meaning of the common CCMP parameters inherited by the extendedRequest and extendedResponse from the basic CCMP request and response messages SHOULD be preserved and exploited appropriately while defining an extension.
在定义扩展时，extendedRequest和extendedResponse从基本CCMP请求和响应消息继承的公共CCMP参数的含义应适当保留和利用。
<!-- extendedRequest -->
<!-- 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>
<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 -->
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="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>
<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>
<!-- extendedResponse -->
<!-- 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>
<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 -->
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="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>
<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>
Figure 17: Structure of the extendedRequest and extendedResponse Messages
图17:extendedRequest和extendedResponse消息的结构
The optionsRequest message (Figure 18) retrieves general information about conference server capabilities. These capabilities include the standard CCMP messages (request/response pairs) and potential extension messages supported by the conference server. As such, it is a basic CCMP message, rather than a specialization of the general CCMP request.
OptionRequest消息（图18）检索有关会议服务器功能的一般信息。这些功能包括标准CCMP消息（请求/响应对）和会议服务器支持的潜在扩展消息。因此，它是基本CCMP消息，而不是一般CCMP请求的专门化。
The optionsResponse returns, in the appropriate <options> field, a list of the supported CCMP message pairs as defined in this specification. These messages are in the form of a list: <standard-message-list> including each of the supported messages as reflected by <standard-message> elements. The optionsResponse message also allows for an <extended-message-list>, which is a list of additional message types in the form of <extended-message-list> elements that are currently undefined, to allow for future extensibility. The following information is provided for both types of messages:
optionResponse在相应的<options>字段中返回本规范中定义的受支持CCMP消息对列表。这些消息以列表的形式出现：<standard message list>，包括<standard message>元素反映的每个受支持的消息。OptionResponse message还允许使用<extended message list>，这是以当前未定义的<extended message list>元素的形式列出的其他消息类型，以允许将来进行扩展。为这两种类型的消息提供以下信息：
o <name> (REQUIRED): in case of standard messages, it can be one of the 10 standard message names defined in this document (i.e., "blueprintsRequest", "confsRequest", etc.). In case of extensions, this element MUST carry the same value of the <extension-name> inserted in the corresponding extendedRequest/ extendedResponse message pair.
o <name>（必选）：对于标准消息，它可以是本文档中定义的10个标准消息名称之一（即“blueprintsRequest”、“confsRequest”等）。对于扩展，此元素必须具有插入相应extendedRequest/extendedResponse消息对中的<extension name>的相同值。
o <operations> (OPTIONAL): this field is a list of <operation> entries, each representing the Create, Read, Update, Delete (CRUD) operation supported by the server for the message. If this element is absent, the client SHOULD assume the server is able to
o <operations>（可选）：此字段是<operations>条目的列表，每个条目表示服务器支持的邮件创建、读取、更新、删除（CRUD）操作。如果缺少此元素，客户端应假定服务器能够
handle the entire set of CRUD operations or, in case of standard messages, all the operations envisioned for that message in this document.
处理整个CRUD操作集，或者在标准消息的情况下，处理本文档中为该消息设想的所有操作。
o <schema-ref> (OPTIONAL): since all CCMP messages can potentially contain XML elements not envisioned in the CCMP schema (due to the presence of <any> elements and attributes), a reference to a proper schema definition specifying such new elements/attributes can also be sent back to the clients by means of such field. If this element is absent, no new elements are introduced in the messages other than those explicitly defined in the CCMP specification.
o <schema ref>（可选）：由于所有CCMP消息可能包含CCMP模式中未预见的XML元素（由于存在<any>元素和属性），因此对指定此类新元素/属性的适当模式定义的引用也可以通过此类字段发送回客户端。如果缺少此元素，则除了CCMP规范中明确定义的元素外，消息中不会引入其他新元素。
o <description> (OPTIONAL): human-readable information about the related message.
o <description>（可选）：有关相关消息的人类可读信息。
The only parameter needed in the optionsRequest is the sender confUserID, which is mirrored in the same parameter of the corresponding optionsResponse.
OptionRequest中唯一需要的参数是sender confUserID，它镜像在相应OptionResponse的相同参数中。
The CCMP server MUST include the <standard-message-list> containing at least one <operation> element in the optionsResponse, since a CCMP server is REQUIRED to be able to handle both the request and response messages for at least one of the operations.
CCMP服务器必须在OptionResponse中包含包含至少一个<operation>元素的<standard message list>，因为CCMP服务器必须能够处理至少一个操作的请求和响应消息。
<!-- optionsRequest -->
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponse -->
<!-- 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>
<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 -->
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="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>
<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>
<!-- options-type -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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>
Figure 18: Structure of the optionsRequest and optionsResponse Messages
图18:OptionRequest和OptionResponse消息的结构
All CCMP response messages MUST include a <response-code>. This document defines an IANA registry for the CCMP response codes, as described in Section 12.5.2. The following summarizes the CCMP response codes:
所有CCMP响应消息必须包含<response code>。本文件定义了CCMP响应代码的IANA注册表，如第12.5.2节所述。以下总结了CCMP响应代码：
200 Success:
200成功：
Successful completion of the requested operation.
成功完成请求的操作。
400 Bad Request:
400错误请求：
Syntactically malformed request.
语法错误的请求。
401 Unauthorized:
401未经授权：
User not allowed to perform the required operation.
不允许用户执行所需的操作。
403 Forbidden:
403禁止：
Operation not allowed (e.g., cancellation of a blueprint).
不允许操作（例如，取消蓝图）。
404 Object Not Found:
404找不到对象：
The target conference object does not exist at the server (The object in the error message refers to the <confObjID> parameter in the generic request message).
服务器上不存在目标会议对象（错误消息中的对象指的是通用请求消息中的<confObjID>参数）。
409 Conflict:
409冲突：
A generic error associated with all those situations in which a requested client operation cannot be successfully completed by the server. An example of such a situation is when the modification of an object cannot be applied due to conflicts arising at the
与服务器无法成功完成请求的客户端操作的所有情况相关联的一般错误。这种情况的一个例子是，由于在同一时间发生冲突，无法应用对对象的修改
server's side, e.g., because the client version of the object is an obsolete one and the requested modifications collide with the up-to-date state of the object stored at the server. Such code would also be used if a client attempts to create an object (conference or user) with an entity that already exists.
服务器端，例如，因为对象的客户端版本已过时，请求的修改与存储在服务器上的对象的最新状态冲突。如果客户机试图使用已经存在的实体创建对象（会议或用户），也将使用此类代码。
420 User Not Found:
420找不到用户：
Target user missing at the server (it is related to the XCON-USERID in the 'entity' attribute of the <userInfo> parameter when it is included in userRequests).
服务器上缺少目标用户（当XCON-USERID包含在userRequests中时，它与<userInfo>参数的“entity”属性中的XCON-USERID相关）。
421 Invalid confUserID:
421无效的序列号：
User does not exist at the server (This code is returned for requests where the <confUserID> parameter is invalid).
服务器上不存在用户（对于<confUserID>参数无效的请求，将返回此代码）。
422 Invalid Conference Password:
422无效的会议密码：
The password for the target conference object contained in the request is wrong.
请求中包含的目标会议对象的密码错误。
423 Conference Password Required:
423需要会议密码：
"conference-password" missing in a request to access a password-protected conference object.
访问受密码保护的会议对象的请求中缺少“会议密码”。
424 Authentication Required:
424需要身份验证：
User's authentication information is missing or invalid.
用户的身份验证信息丢失或无效。
425 Forbidden Delete Parent:
425禁止删除父项：
Cancel operation failed since the target object is a parent of child objects that depend on it, or because it affects, based on the "parent-enforceable" mechanism, the corresponding element in a child object.
取消操作失败，因为目标对象是依赖于它的子对象的父对象，或者因为它基于“父可执行”机制影响子对象中的相应元素。
426 Forbidden Change Protected:
426禁止更改保护：
Update refused by the server because the target element cannot be modified due to its implicit dependence on the value of a parent object ("parent-enforceable" mechanism).
服务器拒绝更新，因为无法修改目标元素，因为它隐式依赖于父对象的值（“父可执行”机制）。
427 Invalid Domain Name:
427无效域名：
The domain name in an AUTO_GENERATE_X instance in the conference object is not within the CCMP server's domain of responsibility.
会议对象中自动生成实例中的域名不在CCMP服务器的责任域内。
500 Server Internal Error:
500服务器内部错误：
The server cannot complete the required service due to a system internal error.
由于系统内部错误，服务器无法完成所需的服务。
501 Not Implemented:
501未实施：
Operation defined by the protocol, but not implemented by this server.
由协议定义但未由此服务器实现的操作。
510 Request Timeout:
510请求超时：
The time required to serve the request has exceeded the configured service threshold.
服务请求所需的时间已超过配置的服务阈值。
511 Resources Not Available:
511资源不可用：
This code is used when the CCMP server cannot execute a command because of resource issues, e.g., it cannot create a sub-conference because the system has reached its limits on the number of sub-conferences, or if a request for adding a new user fails because the max number of users has been reached for the conference or the max number of users has been reached for the conferencing system.
当CCMP服务器因资源问题而无法执行命令时使用此代码，例如，由于系统已达到子会议数量限制，因此无法创建子会议，或者，由于已达到会议的最大用户数或已达到会议系统的最大用户数，因此添加新用户的请求失败。
The handling of a <response-code> of "404", "409", "420", "421", "425", "426", or "427" is only applicable to specific operations for specialized message responses and the details are provided in Section 5.3. The following table summarizes these response codes and the specialized message and operation to which they are applicable:
“404”、“409”、“420”、“421”、“425”、“426”或“427”的<response code>的处理仅适用于专用消息响应的特定操作，详情见第5.3节。下表总结了这些响应代码及其适用的专用消息和操作：
+----------+-------------+--------------+-------------+-------------+
| Response | Create | Retrieve | Update | Delete |
| code | | | | |
+----------+-------------+--------------+-------------+-------------+
| 404 | userRequest | All retrieve | All update | All delete |
| | sidebarBy | requests | requests | requests |
| | ValRequest, | EXCEPT: | | |
| | sidebarsBy | blueprints | | |
| | RefRequest | Request, | | |
| | | confsRequest | | |
| -------- | ----------- | ------------ | ----------- | ----------- |
| 409 | N/A | N/A | All update | N/A |
| | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 420 | userRequest | userRequest | userRequest | userRequest |
| | (third- | | | |
| | party | | | |
| | invite with | | | |
| | third-user | | | |
| | entity) (*) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 421 | All create | All retrieve | All update | All delete |
| | requests | requests | requests | requests |
| | EXCEPT: | | | |
| | userRequest | | | |
| | with no | | | |
| | confUserID | | | |
| | (**) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 425 | N/A | N/A | N/A | All delete |
| | | | | request |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 426 | N/A | N/A | All update | N/A |
| | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 427 | ConfRequest | N/A | All update | N/A |
| | UserRequest | | requests | |
+----------+-------------+--------------+-------------+-------------+
+----------+-------------+--------------+-------------+-------------+
| Response | Create | Retrieve | Update | Delete |
| code | | | | |
+----------+-------------+--------------+-------------+-------------+
| 404 | userRequest | All retrieve | All update | All delete |
| | sidebarBy | requests | requests | requests |
| | ValRequest, | EXCEPT: | | |
| | sidebarsBy | blueprints | | |
| | RefRequest | Request, | | |
| | | confsRequest | | |
| -------- | ----------- | ------------ | ----------- | ----------- |
| 409 | N/A | N/A | All update | N/A |
| | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 420 | userRequest | userRequest | userRequest | userRequest |
| | (third- | | | |
| | party | | | |
| | invite with | | | |
| | third-user | | | |
| | entity) (*) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 421 | All create | All retrieve | All update | All delete |
| | requests | requests | requests | requests |
| | EXCEPT: | | | |
| | userRequest | | | |
| | with no | | | |
| | confUserID | | | |
| | (**) | | | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 425 | N/A | N/A | N/A | All delete |
| | | | | request |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 426 | N/A | N/A | All update | N/A |
| | | | requests | |
| -------- | ----------- | ----------- | ----------- | ----------- |
| 427 | ConfRequest | N/A | All update | N/A |
| | UserRequest | | requests | |
+----------+-------------+--------------+-------------+-------------+
Table 2: Response Codes and Associated Operations
表2：响应代码和相关操作
(*) "420" in answer to a "userRequest/create" operation: In the case of a third-party invite, this code can be returned if the <confUserID> (contained in the 'entity' attribute of the <userInfo> parameter) of the user to be added is unknown. In the case above, if instead it is the <confUserID> parameter of the sender of the request that is invalid, a <response-code> of "421" is returned to the client.
（*）“420”回答“userRequest/create”操作：对于第三方邀请，如果要添加的用户的<confUserID>（包含在<userInfo>参数的“entity”属性中）未知，则可以返回此代码。在上述情况下，如果请求的发送方的<confUserID>参数无效，则向客户端返回<response code>“421”。
(**) "421" is not sent in answer to userRequest/create messages having a "null" confUserID, since this case is associated with a user who is unaware of his own XCON-USERID, but wants to enter a known conference.
（**）发送“421”不是为了回答具有“null”confUserID的userRequest/create消息，因为此案例与不知道自己的XCON-USERID但希望进入已知会议的用户相关。
In the case of a <response-code> of "510", a conferencing client MAY re-attempt the request within a period of time that would be specific to a conferencing client or conference server.
在“510”的<response code>的情况下，会议客户端可以在特定于会议客户端或会议服务器的时间段内重新尝试请求。
A <response-code> of "400" indicates that the conferencing client sent a malformed request, which is indicative of an error in the conferencing client or in the conference server. The handling is specific to the conferencing client implementation (e.g., generate a log, display an error message, etc.). It is NOT RECOMMENDED that the client re-attempt the request in this case.
“400”的<response code>表示会议客户端发送了格式错误的请求，这表示会议客户端或会议服务器中存在错误。处理特定于会议客户端实现（例如，生成日志、显示错误消息等）。在这种情况下，不建议客户端重新尝试请求。
A <response-code> of "401" or "403" indicates the client does not have the appropriate permissions, or there is an error in the permissions: re-attempting the request would likely not succeed and thus it is NOT RECOMMENDED.
“401”或“403”的<response code>表示客户端没有适当的权限，或者权限中存在错误：重新尝试请求可能不会成功，因此不建议这样做。
Any unexpected or unknown <response-code> SHOULD be treated by the client in the same manner as a <response-code> of "500", the handling of which is specific to the conferencing client implementation.
任何意外或未知的<response code>应由客户端以与<response code>相同的方式处理，即“500”，其处理特定于会议客户端实现。
In this section a typical, non-normative, scenario in which CCMP comes into play is described, by showing the actual composition of the various CCMP messages. In the call flows of the example, the conferencing client is a CCMP-enabled client, and the conference server is a CCMP-enabled server. The XCON-USERID of the client, Alice, is "xcon-userid:alice@example.com" and it appears in the <confUserID> parameter in all requests. The sequence of operations is as follows:
在本节中，通过显示各种CCMP消息的实际组成，描述了CCMP发挥作用的典型、非规范性场景。在该示例的呼叫流中，会议客户端是启用CCMP的客户端，会议服务器是启用CCMP的服务器。客户端的XCON-USERID Alice是“XCON USERID:alice@example.com并且它出现在所有请求中的<confUserID>参数中。操作顺序如下：
1. Alice retrieves the list of available blueprints from the server (Section 6.1);
1. Alice从服务器检索可用蓝图列表（第6.1节）；
2. Alice asks for detailed information about a specific blueprint (Section 6.2);
2. Alice询问有关特定蓝图的详细信息（第6.2节）；
3. Alice decides to create a new conference by cloning the retrieved blueprint (Section 6.3);
3. Alice决定通过克隆检索到的蓝图创建一个新的会议（第6.3节）；
4. Alice modifies information (e.g., XCON-URI, name, and description) associated with the newly created blueprint (Section 6.4);
4. Alice修改与新创建的蓝图（第6.4节）相关的信息（例如，XCON-URI、名称和描述）；
5. Alice specifies a list of users to be contacted when the conference is activated (Section 6.5);
5. Alice指定了激活会议时要联系的用户列表（第6.5节）；
6. Alice joins the conference (Section 6.6);
6. Alice加入会议（第6.6节）；
7. Alice lets a new user, Ciccio, (whose XCON-USERID is "xcon-userid:Ciccio@example.com") join the conference (Section 6.7).
7. Alice允许新用户Ciccio（其XCON-USERID为“XCON USERID:Ciccio@example.com）参加会议（第6.7节）。
8. Alice asks for the CCMP server capabilities (Section 6.8);
8. Alice要求提供CCMP服务器功能（第6.8节）；
9. Alice exploits an extension of the CCMP server (Section 6.9).
9. Alice利用CCMP服务器的扩展（第6.9节）。
Note that the examples do not include any details beyond the basic operation.
请注意，这些示例不包括基本操作以外的任何细节。
In the following sections, we deal with each of the aforementioned actions separately.
在下面的部分中，我们将分别处理上述每个操作。
This section illustrates the transaction associated with retrieval of the blueprints, together with a dump of the two messages exchanged (blueprintsRequest and blueprintsResponse). As shown in the figure, the blueprintsResponse message contains, in the <blueprintsInfo> parameter, information about the available blueprints, in the form of the standard XCON-URI of the blueprint, plus additional (and optional) information, like its display-text and purpose.
本节说明了与检索蓝图相关的事务，以及交换的两条消息（blueprintsRequest和blueprintsResponse）的转储。如图所示，blueprintsResponse消息在<blueprintsInfo>参数中包含可用蓝图的信息（以蓝图的标准XCON-URI的形式），以及其他（可选）信息，如其显示文本和用途。
Alice retrieves from the server the list of available blueprints:
Alice从服务器检索可用蓝图列表：
CCMP Client CCMP Server
| |
| CCMP blueprintsRequest message |
| - confUserID: Alice |
| - confObjID: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintsResponse message |
| - confUserID: Alice |
| - confObjID: (null) |
| - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP blueprintsRequest message |
| - confUserID: Alice |
| - confObjID: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintsResponse message |
| - confUserID: Alice |
| - confObjID: (null) |
| - response-code: 200 |
| - blueprintsInfo: bp123,bp124,.. |
|<------------------------------------------------------|
| |
. .
. .
1. blueprintsRequest message:
1. 蓝图请求消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<ccmp:blueprintsRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<ccmp:blueprintsRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintsResponse message from the server:
2. 来自服务器的Blueprint响应消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room:
conference room with public access,
where only audio is available, more users
can talk at the same time
and the requests for the AudioFloor
are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
8 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprints-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:AudioRoom@example.com</info:uri>
<info:display-text>AudioRoom</info:display-text>
<info:purpose>Simple Room:
conference room with public access,
where only audio is available, more users
can talk at the same time
and the requests for the AudioFloor
are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
8 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference1@example.com</info:uri>
<info:display-text>AudioConference1</info:display-text>
<info:purpose>Public Audio Conference:
conference with public access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri>
<info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference
where both audio and video are available,
only one user can talk.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference2@example.com</info:uri>
<info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference:
conference with private access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
</blueprintsInfo>
</ccmp:blueprintsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference1@example.com</info:uri>
<info:display-text>AudioConference1</info:display-text>
<info:purpose>Public Audio Conference:
conference with public access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:VideoConference1@example.com</info:uri>
<info:display-text>VideoConference1</info:display-text>
<info:purpose>Public Video Conference: conference
where both audio and video are available,
only one user can talk.
</info:purpose>
</info:entry>
<info:entry>
<info:uri>xcon:AudioConference2@example.com</info:uri>
<info:display-text>AudioConference2</info:display-text>
<info:purpose>Basic Audio Conference:
conference with private access,
where only audio is available,
only one user can talk at the same time,
and the requests for the AudioFloor MUST
be accepted by a Chair.
</info:purpose>
</info:entry>
</blueprintsInfo>
</ccmp:blueprintsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 19: Getting Blueprints from the Server
图19：从服务器获取蓝图
This section illustrates the second transaction in the overall flow. In this case, Alice, who now knows the XCON-URIs of the blueprints available at the server, makes a drill-down query, in the form of a CCMP blueprintRequest message, to get detailed information about one of them (the one called with XCON-URI "xcon:AudioRoom@example.com"). The picture shows such a transaction. Notice that the response contains, in the <blueprintInfo> parameter, a document compliant with the standard XCON data model.
本节说明了整个流程中的第二个事务。在本例中，Alice现在知道服务器上可用蓝图的XCON URI，以CCMP blueprintRequest消息的形式进行深入查询，以获取其中一个蓝图的详细信息（使用XCON-URI“XCON:AudioRoom@example.com"). 图为此类交易。请注意，响应在<blueprintInfo>参数中包含符合标准XCON数据模型的文档。
Alice retrieves detailed information about a specified blueprint:
Alice检索有关指定蓝图的详细信息：
CCMP Client CCMP Server
| |
| CCMP blueprintRequest message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - blueprintInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintResponse message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - response-code: 200 |
| - blueprintInfo: bp123Info |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP blueprintRequest message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - blueprintInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP blueprintResponse message |
| - confUserID: Alice |
| - confObjID: bp123 |
| - operation: retrieve |
| - response-code: 200 |
| - blueprintInfo: bp123Info |
|<------------------------------------------------------|
| |
. .
. .
1. blueprintRequest message:
1. blueprintRequest消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintResponse message from the server:
2. 来自服务器的Blueprint响应消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-blueprint-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description>
<info:display-text>AudioRoom</info:display-text>
<info:available-media>
<info:entry label="audioLabel">
<info:display-text>audio stream</info:display-text>
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioFloor">
<xcon:media-label>audioLabel</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:AudioRoom@example.com">
<info:conference-description>
<info:display-text>AudioRoom</info:display-text>
<info:available-media>
<info:entry label="audioLabel">
<info:display-text>audio stream</info:display-text>
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="audioFloor">
<xcon:media-label>audioLabel</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</blueprintInfo>
</ccmp:blueprintResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 20: Getting Information about a Specific Blueprint
图20：获取关于特定蓝图的信息
This section illustrates the third transaction in the overall flow. Alice decides to create a new conference by cloning the blueprint having XCON-URI "xcon:AudioRoom@example.com", for which she just retrieved detailed information through the blueprintRequest message. This is achieved by sending a confRequest/create message having the blueprint's URI in the <confObjID> parameter. The picture shows such a transaction. Notice that the response contains, in the <confInfo> parameter, the document associated with the newly created conference, which is compliant with the standard XCON data model. The <confObjID> parameter in the response is set to the XCON-URI of the new conference (in this case, "xcon:8977794@example.com"). We also
本节说明了整个流程中的第三个事务。Alice决定通过克隆具有XCON-URI“XCON:AudioRoom@example.com“，她只是通过blueprintRequest消息获取了详细信息。这是通过发送confRequest/create消息来实现的，该消息在<confObjID>参数中具有蓝图的URI。图为此类交易。请注意，响应在<confInfo>参数中包含与新创建的会议相关联的文档，该文档符合标准XCON数据模型。响应中的<confObjID>参数设置为新会议的XCON-URI（在本例中为“XCON:8977794@example.com"). 我们也
notice that this value is equal to the value of the 'entity' attribute of the <conference-info> element of the document representing the newly created conference object.
请注意，该值等于表示新创建的会议对象的文档的<conference info>元素的“entity”属性的值。
Alice creates a new conference by cloning the "xcon:AudioRoom@example.com" blueprint:
Alice通过克隆“xcon:AudioRoom@example.com“蓝图：
CCMP Client CCMP Server
| |
| CCMP confRequest message |
| - confUserID: Alice |
| - confObjID: AudioRoom |
| - operation: create |
| - confInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP confResponse message |
| - confUserID: Alice |
| - confObjID: newConfId |
| - operation: create |
| - response-code: 200 |
| - version: 1 |
| - confInfo: newConfInfo |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP confRequest message |
| - confUserID: Alice |
| - confObjID: AudioRoom |
| - operation: create |
| - confInfo: (null) |
|------------------------------------------------------>|
| |
| CCMP confResponse message |
| - confUserID: Alice |
| - confObjID: newConfId |
| - operation: create |
| - response-code: 200 |
| - version: 1 |
| - confInfo: newConfInfo |
|<------------------------------------------------------|
| |
. .
. .
1. confRequest message:
1. 请求信息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse message from the server:
2. 来自服务器的confResponse消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
New conference by Alice cloned from AudioRoom
</info:display-text>
<info:available-media>
<info:entry label="333">
<info:display-text>audio stream</info:display-text>
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="11">
<xcon:media-label>333</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:confResponse>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
New conference by Alice cloned from AudioRoom
</info:display-text>
<info:available-media>
<info:entry label="333">
<info:display-text>audio stream</info:display-text>
<info:type>audio</info:type>
</info:entry>
</info:available-media>
</info:conference-description>
<info:users>
<xcon:join-handling>allow</xcon:join-handling>
</info:users>
<xcon:floor-information>
<xcon:floor-request-handling>confirm</xcon:floor-request-handling>
<xcon:conference-floor-policy>
<xcon:floor id="11">
<xcon:media-label>333</xcon:media-label>
</xcon:floor>
</xcon:conference-floor-policy>
</xcon:floor-information>
</confInfo>
</ccmp:confResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 21: Creating a New Conference by Cloning a Blueprint
图21：通过克隆蓝图创建新会议
This section illustrates the fourth transaction in the overall flow. Alice decides to modify some of the details associated with the conference she just created. More precisely, she changes the <display-text> element under the <conference-description> element of the document representing the conference. This is achieved through a confRequest/update message carrying the fragment of the conference document to which the required changes have to be applied. As shown in the picture, the response contains a code of "200", which acknowledges the modifications requested by the client, while also updating the conference version number from 1 to 2, as reflected in the "version" parameter.
本节说明了整个流程中的第四个事务。Alice决定修改与她刚刚创建的会议相关的一些细节。更准确地说，她更改了代表会议的文档的<conference description>元素下的<display text>元素。这是通过一条confRequest/update消息实现的，该消息包含必须应用所需更改的会议文件片段。如图所示，响应包含一个代码“200”，它确认客户端请求的修改，同时还将会议版本号从1更新为2，如“version”参数所示。
Alice updates information about the conference she just created:
Alice更新了她刚刚创建的会议的信息：
CCMP Client CCMP Server
| |
| CCMP confRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - confInfo: confUpdates |
|------------------------------------------------------>|
| |
| CCMP confResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - response-code: 200 |
| - version: 2 |
| - confInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP confRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - confInfo: confUpdates |
|------------------------------------------------------>|
| |
| CCMP confResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - response-code: 200 |
| - version: 2 |
| - confInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. confRequest message:
1. 请求信息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<ccmp:confRequest>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
Alice's conference
</info:display-text>
</info:conference-description>
</confInfo>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<ccmp:confRequest>
<confInfo entity="xcon:8977794@example.com">
<info:conference-description>
<info:display-text>
Alice's conference
</info:display-text>
</info:conference-description>
</confInfo>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse message from the server:
2. 来自服务器的confResponse消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>2</version>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-conf-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>2</version>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 22: Updating Conference Information
图22：更新会议信息
This section illustrates the fifth transaction in the overall flow. Alice modifies the <allowed-users-list> under the <users> element in the document associated with the conference she created. To achieve this, she makes use of the usersRequest message provided by CCMP.
本节说明了整个流程中的第五个事务。Alice修改与她创建的会议关联的文档中<users>元素下的<allowed users list>。为了实现这一点，她利用了CCMP提供的usersRequest消息。
Alice updates information about the list of users to whom access to the conference is permitted:
Alice更新有关允许访问会议的用户列表的信息：
CCMP Client CCMP Server
| |
| CCMP usersRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - usersInfo: usersUpdates |
|------------------------------------------------------>|
| |
| CCMP usersResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - response-code: 200 |
| - version: 3 |
| - usersInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP usersRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - usersInfo: usersUpdates |
|------------------------------------------------------>|
| |
| CCMP usersResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: update |
| - response-code: 200 |
| - version: 3 |
| - usersInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. usersRequest message:
1. 用户请求消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<ccmp:usersRequest>
<usersInfo>
<xcon:allowed-users-list>
<xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer"
uri="tel:+1-972-555-1234"/>
<xcon:target method="refer"
uri="sip:Carol@example.com"/>
</xcon:allowed-users-list>
</usersInfo>
</ccmp:usersRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>update</operation>
<ccmp:usersRequest>
<usersInfo>
<xcon:allowed-users-list>
<xcon:target method="dial out"
uri="xmpp:cicciolo@pippozzo.com"/>
<xcon:target method="refer"
uri="tel:+1-972-555-1234"/>
<xcon:target method="refer"
uri="sip:Carol@example.com"/>
</xcon:allowed-users-list>
</usersInfo>
</ccmp:usersRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. usersResponse message from the server:
2. 来自服务器的用户响应消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>3</version>
<ccmp:usersResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-users-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>3</version>
<ccmp:usersResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 23: Updating the List of Allowed Users for the Conference 'xcon:8977794@example.com'
图23：更新会议“xcon”的允许用户列表：8977794@example.com'
This section illustrates the sixth transaction in the overall flow. Alice uses CCMP to add herself to the newly created conference. This is achieved through a userRequest/create message containing, in the <userInfo> parameter, a <user> element compliant with the XCON data model representation. Notice that such an element includes information about the user's Addresses of Record, as well as her current endpoint. The picture below shows the transaction. Notice how the <confUserID> parameter is equal to the 'entity' attribute of the <userInfo> element, which indicates that the request issued by the client is a first-party one.
本节说明了整个流程中的第六个事务。Alice使用CCMP将自己添加到新创建的会议中。这是通过userRequest/create消息实现的，该消息在<userInfo>参数中包含符合XCON数据模型表示的<user>元素。请注意，这样的元素包括有关用户记录地址的信息，以及用户当前端点的信息。下图显示了该交易。请注意，<confUserID>参数如何等于<userInfo>元素的“entity”属性，这表示客户端发出的请求是第一方请求。
Alice joins the conference by issuing a userRequest/create message with her own ID to the server:
Alice通过向服务器发出带有自己ID的userRequest/create消息加入会议：
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: AliceUserInfo |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 4 |
| - userInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: AliceUserInfo |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 4 |
| - userInfo: (null) |
|<------------------------------------------------------|
| |
. .
. .
1. userRequest message:
1. 用户请求消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:alice@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Alice83@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:alice_789@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. userResponse message from the server:
2. 来自服务器的userResponse消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>4</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>4</version>
<ccmp:userResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 24: Alice Joins the Conference through CCMP
图24:Alice通过CCMP加入会议
This section illustrates the seventh and last transaction in the overall flow. Alice uses CCMP to add a new conferencing system user, Ciccio, to the conference. This "third-party" request is realized through a userRequest/create message containing, in the <userInfo> parameter, a <user> element compliant with the XCON data model representation. Notice that such an element includes information about Ciccio's Addresses of Record, as well as his current endpoint, but has a placeholder 'entity' attribute, "AUTO_GENERATE_1@example.com" as discussed in Section 4.3, since the XCON-USERID is initially unknown to Alice. Thus, the conference server is in charge of generating a new XCON-USERID for the user Alice indicates (i.e., Ciccio), and returning it in the 'entity' attribute of the <userInfo> parameter carried in the response, as well as adding the user to the conference. The picture below shows the transaction.
本节说明了整个流程中的第七个也是最后一个事务。Alice使用CCMP将新的会议系统用户Ciccio添加到会议中。此“第三方”请求通过userRequest/create消息实现，该消息在<userInfo>参数中包含符合XCON数据模型表示的<user>元素。请注意，这样的元素包含有关Ciccio的记录地址及其当前端点的信息，但有一个占位符“entity”属性“AUTO_GENERATE”_1@example.com“如第4.3节所述，因为Alice最初不知道XCON-USERID。因此，会议服务器负责为Alice指示的用户（即Ciccio）生成新的XCON-USERID，并将其返回到响应中携带的<userInfo>参数的“entity”属性中，以及将用户添加到会议中。下图显示了该交易。
Alice adds user "Ciccio" to the conference by issuing a third-party userRequest/create message to the server:
Alice通过向服务器发出第三方userRequest/create消息向会议添加用户“Ciccio”：
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: dummyUserID, CiccioUserInfo |
|------------------------------------------------------>|
| |
| CCMP optionsResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 5 |
| - userInfo: userIDCiccio, |
| CiccioUserInfo |
| |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP userRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - userInfo: dummyUserID, CiccioUserInfo |
|------------------------------------------------------>|
| |
| CCMP optionsResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: create |
| - response-code: 200 |
| - version: 5 |
| - userInfo: userIDCiccio, |
| CiccioUserInfo |
| |
|<------------------------------------------------------|
| |
. .
. .
1. "third-party" userRequest message from Alice:
1. 来自Alice的“第三方”用户请求消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. "third-party" userResponse message from the server:
2. 来自服务器的“第三方”用户响应消息：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<version>5</version>
<ccmp:userResponse>
<userInfo entity="xcon-userid:Ciccio@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-user-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<version>5</version>
<ccmp:userResponse>
<userInfo entity="xcon-userid:Ciccio@example.com">
<info:associated-aors>
<info:entry>
<info:uri>
mailto:Ciccio@example.com
</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<info:endpoint entity="sip:Ciccio@example.com"/>
</userInfo>
</ccmp:userResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 25: Alice Adds a New User to the Conference through CCMP
图25:Alice通过CCMP向会议添加一个新用户
This section illustrates how Alice can discover which standard CCMP messages and what extensions are supported by the CCMP server with which she interacts through an optionsRequest/optionsResponse transaction.
本节说明Alice如何发现CCMP服务器支持哪些标准CCMP消息以及哪些扩展，并通过OptionRequest/OptionResponse事务与之交互。
To prepare the optionsRequest, Alice just puts her XCON-USERID in the <confUserID> parameter. Looking at the <options> element in the received optionsResponse, Alice infers the following server capabilities as regards standard CCMP messages:
为了准备optionRequest，Alice只需将她的XCON-USERID放入<confUserID>参数中。查看收到的optionResponse中的<options>元素，Alice推断出标准CCMP消息的以下服务器功能：
o the server doesn't support sidebarsByValRequest nor the sidebarByValRequest messages, since they do not appear in the <standard-message-list>;
o 服务器不支持sidebarsByValRequest或sidebarByValRequest消息，因为它们不显示在<标准消息列表>中；
o the only implemented operation for the blueprintRequest message is "retrieve", since no other <operation> entries are included in the related <operations> field.
o blueprintRequest消息的唯一实现操作是“检索”，因为相关的<operations>字段中不包括其他<operations>条目。
By analyzing the <extended-message-list>, Alice discovers the server implements a bluePrint extension, referred to as "confSummaryRequest" in this example. This extension allows Alice to recover via CCMP a brief description of a specific conference; the XML elements involved in this extended conference control transaction are available at the URL indicated in the <schema-ref> element, and the only operation provided by this extension is "retrieve". To better understand how Alice can exploit the "confSummaryRequest" extension via CCMP, see Section 6.9.
通过分析<ExtendedMessageList>，Alice发现服务器实现了一个蓝图扩展，在本例中称为“confSummaryRequest”。此扩展允许Alice通过CCMP恢复特定会议的简要描述；此扩展会议控制事务中涉及的XML元素在<schema ref>元素中指示的URL处可用，此扩展提供的唯一操作是“检索”。为了更好地理解Alice如何通过CCMP利用“confSummaryRequest”扩展，请参阅第6.9节。
The figure below shows the optionsRequest/optionsResponse message exchange between Alice and the CCMP server.
下图显示了Alice和CCMP服务器之间的OptionRequest/OptionResponse消息交换。
CCMP Client CCMP Server
| |
| CCMP optionsRequest message |
| - confUserID: Alice |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP optionsRequest message |
| - confUserID: Alice |
|------------------------------------------------------>|
| |
| CCMP userResponse message |
| - confUserID: Alice |
| - response-code: 200 |
| - options (list of both |
| standard and extended |
| supported messages) |
|<------------------------------------------------------|
| |
. .
. .
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
</ccmpRequest>
</ccmp:ccmpRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. optionsResponse (the server returns the list of its conference control capabilities)
2. 选项响应（服务器返回其会议控制功能列表）
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
<standard-message>
<name>blueprintRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
</standard-message>
<standard-message>
<name>confsRequest</name>
</standard-message>
<standard-message>
<name>confRequest</name>
</standard-message>
<standard-message>
<name>usersRequest</name>
</standard-message>
<standard-message>
<name>userRequest</name>
</standard-message>
<standard-message>
<name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list>
<extended-message-list>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-options-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:optionsResponse>
<options>
<standard-message-list>
<standard-message>
<name>blueprintsRequest</name>
</standard-message>
<standard-message>
<name>blueprintRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
</standard-message>
<standard-message>
<name>confsRequest</name>
</standard-message>
<standard-message>
<name>confRequest</name>
</standard-message>
<standard-message>
<name>usersRequest</name>
</standard-message>
<standard-message>
<name>userRequest</name>
</standard-message>
<standard-message>
<name>sidebarsByRefRequest</name>
</standard-message>
<standard-message>
<name>sidebarByRefRequest</name>
</standard-message>
</standard-message-list>
<extended-message-list>
<extended-message>
<name>confSummaryRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
<schema-def>
http://example.com/ccmp-extension-schema.xsd
</schema-def>
<description>
confSummaryRequest is intended
to allow the requestor to retrieve
a brief description
of the conference indicated in the
confObjID request parameter
</description>
</extended-message>
</extended-message-list>
</options>
</ccmp:optionsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
<extended-message>
<name>confSummaryRequest</name>
<operations>
<operation>retrieve</operation>
</operations>
<schema-def>
http://example.com/ccmp-extension-schema.xsd
</schema-def>
<description>
confSummaryRequest is intended
to allow the requestor to retrieve
a brief description
of the conference indicated in the
confObjID request parameter
</description>
</extended-message>
</extended-message-list>
</options>
</ccmp:optionsResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 26: Alice Asks for the Server Control Capabilities
图26:Alice要求提供服务器控制功能
In this section, a very simple example of CCMP extension support is provided. Alice can recover information about this and other server-supported extensions by issuing an optionsRequest (see Section 6.8).
本节提供了一个非常简单的CCMP扩展支持示例。Alice可以通过发出optionsRequest（参见第6.8节）来恢复有关此扩展和其他服务器支持扩展的信息。
The extension in question is named "confSummaryRequest" and allows a CCMP client to obtain from the CCMP server synthetic information about a specific conference. The conference summary is carried in the form of an XML element as follows:
该扩展名为“confSummaryRequest”，允许CCMP客户端从CCMP服务器获取有关特定会议的综合信息。会议摘要以XML元素的形式进行，如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/ccmp-extension"
xmlns="http://example.com/ccmp-extension">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/ccmp-extension"
xmlns="http://example.com/ccmp-extension">
<xs:element name="confSummary" type="conf-summary-type"/>
<xs:element name="confSummary" type="conf-summary-type"/>
<xs:complexType name="conf-summary-type">
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="status" type="xs:string"/>
<xs:element name="public" type="xs:boolean"/>
<xs:element name="media" type="xs:string"/>
<xs:complexType name="conf-summary-type">
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="status" type="xs:string"/>
<xs:element name="public" type="xs:boolean"/>
<xs:element name="media" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:sequence>
</xs:complexType>
</xs:schema>
</xs:schema>
Figure 27: Example of XML Schema defining an extension parameter (ccmp-extension-schema.xsd)
图27：定义扩展参数的XML模式示例（ccmp extension Schema.xsd）
As can be inferred from the schema file, the <confSummary> element contains conference information related to the following:
从架构文件可以推断，<confSummary>元素包含与以下内容相关的会议信息：
o title
o 标题
o status (active or registered)
o 状态（活动或已注册）
o participation modality (if everyone is allowed to participate, the boolean <public> element is set to "true")
o 参与模式（如果允许所有人参与，则布尔<public>元素设置为“true”）
o involved media
o 相关媒体
In order to retrieve a conference summary related to the conference she participates in, Alice sends to the CCMP server an extendedRequest with a "confSummaryRequest" <extensionName>, specifying the conference XCON-URI in the confObjID request parameter, as depicted in the figure below.
为了检索与她参加的会议相关的会议摘要，Alice向CCMP服务器发送一个带有“confSummaryRequest”<extensionName>，并在ConfBjid请求参数中指定会议XCON-URI的extendedRequest，如下图所示。
CCMP Client CCMP Server
| |
| CCMP extendedRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - extensionName: confSummaryRequest |
|------------------------------------------------------>|
| |
| CCMP extendedResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - response-code: 200 |
| - extensionName: |
| confSummaryRequest |
| - confSummary |
|<------------------------------------------------------|
| |
. .
. .
CCMP Client CCMP Server
| |
| CCMP extendedRequest message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - extensionName: confSummaryRequest |
|------------------------------------------------------>|
| |
| CCMP extendedResponse message |
| - confUserID: Alice |
| - confObjID: 8977794 |
| - operation: retrieve |
| - response-code: 200 |
| - extensionName: |
| confSummaryRequest |
| - confSummary |
|<------------------------------------------------------|
| |
. .
. .
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:extendedRequest>
<extensionName>confRequestSummary</extensionName>
</ccmp:extendedRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:extendedRequest>
<extensionName>confRequestSummary</extensionName>
</ccmp:extendedRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. extendedResponse (the server provides Alice with a brief description of the desired conference)
2. extendedResponse（服务器向Alice提供所需会议的简要说明）
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:extendedResponse>
<extensionName>confSummaryRequest</extensionName>
<example:confSummary>
<title> Alice's conference </title>
<status> active </status>
<public> true </public>
<media> audio </media>
</example:confSummary>
</ccmp:extendedResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:ccmp="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:example="http://example.com/ccmp-extension">
<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ccmp:ccmp-extended-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:extendedResponse>
<extensionName>confSummaryRequest</extensionName>
<example:confSummary>
<title> Alice's conference </title>
<status> active </status>
<public> true </public>
<media> audio </media>
</example:confSummary>
</ccmp:extendedResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 28: Alice Exploits the 'confSummaryRequest' Extension
图28:Alice利用“confSummaryRequest”扩展
If a conferencing client is not pre-configured to use a specific conference server for the requests, the client MUST first discover the conference server before it can send any requests. The result of the discovery process, is the address of the server supporting conferencing. In this document, the result is an http: or https: URI, which identifies a conference server.
如果会议客户端未预先配置为使用特定会议服务器进行请求，则客户端必须首先发现会议服务器，然后才能发送任何请求。发现过程的结果是支持会议的服务器的地址。在本文档中，结果是http:或https:URI，用于标识会议服务器。
DNS is RECOMMENDED to be used to locate a conference server in the case that the client is not pre-configured to use a specific conference server. URI-Enabled NAPTR (U-NAPTR) resolution for conferencing takes a domain name as input and produces a URI that identifies the conference server. This process also requires an Application Service tag and an Application Protocol tag, which differentiate conferencing-related NAPTR records from other records for that domain.
如果客户端未预先配置为使用特定会议服务器，建议使用DNS来定位会议服务器。用于会议的启用URI的NAPTR（U-NAPTR）解析将域名作为输入，并生成标识会议服务器的URI。此过程还需要一个应用程序服务标签和一个应用程序协议标签，用于区分与会议相关的NAPTR记录与该域的其他记录。
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节定义了应用程序服务标签“XCON”，用于标识特定域的集中式会议（XCON）服务器。第12.4.2节中定义的应用协议标签“CCMP”用于标识理解CCMP的XCON服务器。
The NAPTR records in the following example (Figure 29) demonstrate the use of the Application Service and Application Protocol tags. Iterative NAPTR resolution is used to delegate responsibility for the conferencing service from "zonea.example.com." and "zoneb.example.com." to "outsource.example.com.".
下面示例（图29）中的NAPTR记录演示了应用程序服务和应用程序协议标记的使用。迭代NAPTR解析用于将会议服务的责任从“zonea.example.com.”和“zoneb.example.com.”委派给“outsource.example.com.”。
zonea.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex
. ; replacement
)
zonea.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex
. ; replacement
)
Figure 29: Sample XCON-CCMP Service NAPTR Records
图29:XCON-CCMP服务NAPTR记录示例
Details for the "XCON" Application Service tag and the "CCMP" Application Protocol tag are included in Section 12.4.
“XCON”应用服务标签和“CCMP”应用协议标签的详细信息见第12.4节。
As per [RFC5239], CCMP is one of the following four protocols, which have been formally identified within the XCON framework:
根据[RFC5239]，CCMP是以下四种协议之一，已在XCON框架内正式确定：
Conference Control Protocol:
会议控制协议：
mediates between conference and media control client (conferencing client) and conference server. This document describes such a protocol.
在会议和媒体控制客户端（会议客户端）与会议服务器之间进行调解。本文件描述了此类协议。
Binary floor Control Protocol:
二进制地板控制协议：
operates between the floor control client and the floor control server. An example of such a protocol is the Binary Floor Control Protocol (BFCP), specified in [RFC4582].
在地板控制客户端和地板控制服务器之间操作。此类协议的一个示例是[RFC4582]中规定的二进制地板控制协议（BFCP）。
Call Signaling Protocol:
呼叫信令协议：
operates between the Call Signaling Client and the focus. Examples of call signaling protocols include SIP, H.323 and IAX. Such protocols are capable of negotiating a conferencing session.
在呼叫信令客户端和焦点之间操作。呼叫信令协议的示例包括SIP、H.323和IAX。此类协议能够协商会议会话。
Notification Protocol:
通知协议：
operates between the Notification Client and the XCON Notification Service. This specification does not define a new notification protocol. For clients that use SIP as the call signaling protocol, the XCON event package [RFC6502] MUST be used by the client for notifications of changes in the conference data as described below.
在通知客户端和XCON通知服务之间操作。本规范未定义新的通知协议。对于使用SIP作为呼叫信令协议的客户端，客户端必须使用XCON事件包[RFC6502]来通知会议数据的更改，如下所述。
The protocol specified in this document is a proactive one and is used by a conferencing client to send requests to a conference server in order to retrieve information about the conference objects stored by the server and to possibly manipulate them. However, a complete conferencing solution is not prohibited from providing clients with a means for receiving asynchronous updates about the status of the objects available at the server. The notification protocol, while conceptually independent of all the mentioned companion protocols, can nonetheless be chosen in a way that is consistent with the overall protocol architecture characterizing a specific deployment, as discussed in the following.
本文档中指定的协议是主动协议，会议客户端使用该协议向会议服务器发送请求，以检索服务器存储的会议对象信息，并可能对其进行操作。但是，完整的会议解决方案并不禁止向客户端提供接收有关服务器上可用对象状态的异步更新的方法。尽管通知协议在概念上独立于所有提及的配套协议，但仍可以按照与表征特定部署的总体协议体系结构一致的方式来选择，如下所述。
When the conferencing control client uses SIP [RFC3261] as the signaling protocol to participate in the conference, SIP event notification can be used. In such a case, the conferencing control client MUST implement the conference event package for XCON [RFC6502]. This is the default mechanism for conferencing clients as is SIP for signaling per the XCON framework [RFC5239].
当会议控制客户端使用SIP[RFC3261]作为信令协议来参与会议时，可以使用SIP事件通知。在这种情况下，会议控制客户端必须为XCON[RFC6502]实现会议事件包。这是会议客户端的默认机制，就像根据XCON框架[RFC5239]发送信令的SIP一样。
In the case where the interface to the conference server is entirely web based, there is a common mechanism for web-based systems that could be used -- a "call back". With this mechanism, the conferencing client provides the conference server with an HTTP URL that is invoked when a change occurs. This is a common implementation mechanism for e-commerce. This works well in the scenarios whereby the conferencing client is a web server that provides the graphical HTML user interface and uses CCMP as the back-end interface to the conference server. This model can coexist with the SIP event notification model. PC-based clients behind NATs could provide a SIP event URI, whereas web-based clients using CCMP in the back end would probably find the HTTP call back approach much easier. The details of this approach are out of scope for CCMP; thus, we expect a future specification will document this solution.
在会议服务器的接口完全基于web的情况下，可以使用基于web的系统的通用机制——“回调”。通过这种机制，会议客户端向会议服务器提供一个HTTP URL，在发生更改时调用该URL。这是一种常见的电子商务实现机制。这在会议客户端是提供图形HTML用户界面并使用CCMP作为会议服务器后端接口的web服务器的情况下非常有效。此模型可以与SIP事件通知模型共存。NAT后面基于PC的客户端可以提供SIP事件URI，而在后端使用CCMP的基于web的客户端可能会发现HTTP回调方法更容易。该方法的细节超出CCMP的范围；因此，我们希望未来的规范将记录此解决方案。
This section describes the use of HTTP [RFC2616] and HTTP over TLS [RFC2818] as transport mechanisms for CCMP, which a conforming conference server and conferencing client MUST support.
本节描述了HTTP[RFC2616]和HTTP over TLS[RFC2818]作为CCMP传输机制的使用，一致性会议服务器和会议客户端必须支持该传输机制。
Although CCMP uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a conferencing server might not be a fully compliant HTTP server. It is intended that a conference server can easily be built using an HTTP server with extensibility mechanisms, and that a conferencing client can trivially use existing HTTP libraries. This subset of requirements helps implementers avoid ambiguity with the many options the full HTTP protocol offers.
尽管CCMP使用HTTP作为传输，但它使用HTTP功能的严格子集，并且由于某些功能的限制，会议服务器可能不是完全兼容的HTTP服务器。会议服务器可以使用具有可扩展性机制的HTTP服务器轻松构建，会议客户端可以轻松使用现有的HTTP库。这个需求子集有助于实现者避免对完整HTTP协议提供的许多选项产生歧义。
Support of HTTP authentication [RFC2617] and cookies [RFC6265] is OPTIONAL for a conferencing client that conforms to this specification. These mechanisms are unnecessary because CCMP requests carry their own authentication information (in the "subject" field; see Section 5.1). A conferencing client SHOULD include support for HTTP proxy authentication.
对于符合此规范的会议客户端，支持HTTP身份验证[RFC2617]和Cookie[RFC6265]是可选的。这些机制是不必要的，因为CCMP请求携带它们自己的身份验证信息（在“主题”字段中；参见第5.1节）。会议客户端应包括对HTTP代理身份验证的支持。
A CCMP request is carried in the body of an HTTP POST request. The conferencing client MUST include a Host header in the request.
CCMP请求在HTTP POST请求的主体中进行。会议客户端必须在请求中包含主机标头。
The MIME type of CCMP request and response bodies is "application/ ccmp+xml". The conference server and conferencing client MUST provide this value in the HTTP Content-Type and Accept header fields. If the conference server does not receive the appropriate Content-Type and Accept header fields, the conference server SHOULD fail the request, returning a 406 (Not Acceptable) response. CCMP responses SHOULD include a Content-Length header.
CCMP请求和响应主体的MIME类型为“application/CCMP+xml”。会议服务器和会议客户端必须在HTTP内容类型和接受标头字段中提供此值。如果会议服务器未接收到适当的内容类型和Accept标头字段，则会议服务器应使请求失败，并返回406（不可接受）响应。CCMP响应应包括内容长度标题。
Conferencing clients MUST NOT use the Expect header or the Range header in CCMP requests. The conference server MAY return 501 (Not Implemented) errors if either of these HTTP features are used. In the case that the conference server receives a request from the conferencing client containing an If-* (conditional) header, the conference server SHOULD return a 412 (precondition failed) response.
会议客户端不得在CCMP请求中使用Expect标头或Range标头。如果使用这些HTTP功能之一，会议服务器可能返回501（未实现）错误。如果会议服务器从会议客户端接收到包含If-*（条件）头的请求，则会议服务器应返回412（前提条件失败）响应。
The POST method is the only method REQUIRED for CCMP. If a conference server chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a conferencing client only uses a POST method, the GET or HEAD MUST be either a URL that was found outside its normal context (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody is testing or debugging a system. The conference server could provide information in the CCMP response indicating that the URL corresponds to a conference server and only responds to CCMP POST requests or the conference server could instead try to avoid any leak of information by returning a very generic HTTP error message such as 405 (Method Not Allowed).
POST方法是CCMP所需的唯一方法。如果会议服务器选择支持get或Head，则应该考虑应用程序进行GET的类型。由于会议客户端仅使用POST方法，因此GET或HEAD必须是在其正常上下文之外找到的URL（例如，有人在协议跟踪或日志文件中找到URL并将其输入浏览器），或者有人正在测试或调试系统。会议服务器可以在CCMP响应中提供指示URL对应于会议服务器并且仅响应CCMP POST请求的信息，或者会议服务器可以通过返回非常通用的HTTP错误消息（例如405）来尝试避免任何信息泄漏（不允许使用方法）。
The conference server populates the HTTP headers of responses so that they are consistent with the contents of the message. In particular, the CacheControl header SHOULD be set to disable caching of any conference information by HTTP intermediaries. Otherwise, there is the risk of stale information and/or the unauthorized disclosure of the information. The HTTP status code MUST indicate a 2xx series response for all CCMP Response and Error messages.
会议服务器填充响应的HTTP头，使其与消息内容一致。特别是，应将CacheControl标头设置为禁用HTTP中介对任何会议信息的缓存。否则，将存在过时信息和/或未经授权披露信息的风险。HTTP状态代码必须指示所有CCMP响应和错误消息的2xx系列响应。
The conference server MAY redirect a CCMP request. A conference server MUST NOT include CCMP responses in a 3xx response. A conferencing client MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the conferencing client MUST observe the delay indicated by the Retry-After header. The conferencing client MUST authenticate the server that returns the redirect response before following the redirect. A conferencing client SHOULD authenticate the conference server indicated in a redirect.
会议服务器可以重定向CCMP请求。会议服务器不得在3xx响应中包含CCMP响应。会议客户端必须使用服务器在3xx响应中提供的位置头来处理重定向。重定向时，会议客户端必须遵守Retry After标头指示的延迟。在执行重定向之前，会议客户端必须对返回重定向响应的服务器进行身份验证。会议客户端应验证重定向中指示的会议服务器。
The conference server SHOULD support persistent connections and request pipelining. If pipelining is not supported, the conference server MUST NOT allow persistent connections. The conference server MUST support termination of a response by the closing of a connection.
会议服务器应支持持久连接和请求管道。如果不支持管道，则会议服务器不得允许持续连接。会议服务器必须支持通过关闭连接来终止响应。
Implementations of CCMP that implement HTTP transport MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the conferencing client and the conference server. The conferencing client MUST implement the server authentication method described in HTTPS [RFC2818]. The device uses the URI obtained during conference server discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the conferencing client SHOULD fail a request if server authentication fails.
实现HTTP传输的CCMP实现必须通过TLS实现传输[RFC2818]。TLS在会议客户端和会议服务器之间提供消息完整性和机密性。会议客户端必须实现HTTPS[RFC2818]中描述的服务器身份验证方法。设备使用在会议服务器发现期间获得的URI对服务器进行身份验证。HTTPS[RFC2818]的第3.1节提供了此身份验证方法的详细信息。使用TLS时，如果服务器身份验证失败，会议客户端应使请求失败。
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.
如XCON框架[RFC5239]中所述，由于多个端点的自然参与以及使用CCMP操纵会议服务器上数据的能力，存在与会议相关的各种潜在攻击。攻击的示例包括：一个端点试图侦听其无权参与的会议，一个端点试图断开其他用户的连接或使其静音，以及一个端点在试图创建不允许创建的会议时窃取服务。
The following summarizes the security considerations for CCMP:
以下总结了CCMP的安全注意事项：
1. The client MUST determine the proper conference server. The conference server discovery is described in Section 7.
1. 客户端必须确定正确的会议服务器。第7节介绍了会议服务器发现。
2. The client MUST connect to the proper conference server. The mechanisms for addressing this security consideration are described in Section 10.1.
2. 客户端必须连接到正确的会议服务器。第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].
3. 协议必须支持机密性和完整性机制。如第9节所述，CCMP的实现必须通过TLS实现HTTP传输[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.
4. 存在与授权在会议系统上执行操作以调用特定功能相关的安全问题。会议服务器应确保只有经过授权的实体才能操作会议数据。第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.
5. 必须确保会议中用户身份的隐私和安全。第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.
6. 最后一个问题与会议服务器本身的拒绝服务（DoS）攻击有关。第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.
在上述考虑因素中，第1项和第3项在本文件前面的参考章节中进行了说明。其余的安全注意事项将在以下各节中详细介绍。
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.
第7节描述了一种使用DNS的机制，会议客户端通过该机制发现会议服务器。主要问题是伪造DNS回复；因此，建议使用DNS安全性（DNSSEC），以确保在出现此问题的情况下，客户端从DNS服务器接收有效响应。
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
当使用TLS[RFC5246]执行CCMP事务时，会议服务器可以通过将包含该标识符的证书作为subjectAltName（即分别作为iPAddress或dNSName）提供给会议客户端，从而将其身份验证为域名或IP地址。CCMP的任何实现都必须能够通过TLS进行交易，以便客户端能够
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.
请求上述身份验证。请注意，为了使提供的证书在客户端有效，在HTTP作为传输的情况下，客户端必须能够按照[RFC2818]中的过程验证证书。特别是，证书的验证路径必须以客户端的一个信任锚点结束，即使该信任锚点是会议服务器证书本身。如果客户端具有关于适当会议服务器的预期标识或凭证的外部信息，则可以省略上述认证检查。
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.
许多策略授权决策都基于用户的身份或用户可能具有的角色。会议服务器必须实现用户身份验证机制，以验证其身份。用户可以通过多种方式向系统验证其身份。对于使用呼叫信令协议之一加入会议的用户，可以使用特定协议的用户认证机制。例如，在用户使用SIP信令加入会议的情况下，必须使用[RFC3261]中定义的用户认证。对于使用CCMP参加会议的用户，CCMP请求消息提供一个主题字段，其中包含用户名和密码，可用于身份验证。由于建议通过TLS传输CCMP消息，因此可以安全地发送此信息。
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.
XCON框架[RFC5239]概述了其他授权机制。在通过多个机制授权用户的情况下，建议会议服务器将CCMP接口的授权与其他授权机制相关联；例如，公共交换电话网（PSTN）用户使用PIN加入并使用CCMP控制会议。当会议服务器显示授权用户的身份时，它可能会提供有关系统证明或验证身份的方式的信息。会议服务器还可以允许完全未经身份验证的用户进入系统——此信息还应传达给相关方。
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/
一旦通过会议服务器上可用的各种机制对用户进行身份验证和授权，会议服务器必须分配会议用户标识符（XCON-USERID），并应将XCON-USERID与用于身份验证和授权的任何特定于信令的用户标识符相关联。该XCON-USERID可以通过会议通知界面提供给特定用户，并且必须提供给使用CCMP（即，在适当的CCMP响应消息中）与会议系统交互的用户。每个用户的XCON用户ID/
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.
会议参与者包含在会议对象中<user>元素的“entity”属性中。用户对会议对象的任何后续操作都需要XCON-USERID，并在CCMP请求和响应中的confUserID参数中携带。
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.
请注意，XCON兼容会议系统的策略管理不在本文档以及XCON工作组（WG）的范围内。然而，策略管理框架的规范可以在整个XCON体系结构中实现，特别是在基于角色的访问控制（RBAC）方法方面。在RBAC中，识别以下元素：（i）用户；二作用；三物体；四业务；（v） 权限。对于上述所有元素，存在到主XCON实体的直接映射。例如，RBAC对象映射到XCON数据模型对象，RBAC操作映射到CCMP操作。
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.
未来的文档可以为XCON定义RBAC框架，首先关注角色的定义，然后指定所需的权限策略集和角色策略集（用于将策略权限集与特定角色关联）。有了这些策略，可以适当地控制对符合XCON数据模型的会议对象的访问。就为用户分配角色而言，RBAC模型中的用户与会议对象中的<users>元素直接相关。<users>元素由表示会议系统中特定用户的<user>元素组成。
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.
每个<user>元素都包含一个带有XCON-USERID的“entity”属性和一个<role>元素。因此，每个授权用户（由XCON-USERID表示）都可以与<role>元素相关联。
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.
XCON框架[RFC5239]概述了会议系统用户所需的隐私和匿名性。CCMP通过使用TLS提供XCON-USERID形式的身份安全性。
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:
会议服务器应支持确保XCON-USERID隐私的机制。会议客户端通过操纵XCON数据模型[RFC6501]中定义的<提供匿名性>元素来指示所需的隐私级别。<provide anonymity>元素控制用户透露其身份的程度。以下总结了客户端在其请求中包含的<provide anonymity>元素的值：
"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.
如果客户端需要隐私，则会议客户端应在CCMP confRequest消息的<confInfo>参数中包含<provide anonymity>元素，参数为<operation>的“update”或“create”，或在CCMP userRequest消息的<userInfo>参数中包含<operation>参数的“update”或“create”。如果会议对象中不包含<provide anonymity>元素，则其他用户可以看到参与者的身份。当参与者在会议对象上执行后续操作或检索会议对象时，或者当他们收到后续通知时，他们会意识到其他参与者是“匿名”或“半私有”的。
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.2节所述必要授权所必需的。可以使用策略控制人工管理员查看信息的程度（例如，可以对人工管理员隐藏数据模型中的某些信息）。
[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
[RFC4732]概述了可能的DoS攻击。为了将DoS攻击的可能性降至最低，建议会议系统要求参与会议的任何客户端都具有用户身份验证和授权。这可以通过使用第10.2节中描述的机制，以及通过使用与特定信令（例如，会话启动协议安全（SIPS））和媒体协议（例如，安全实时传输协议（SRTP））相关联的安全机制来实现。此外，第4.4节描述了使用定时器机制来缓解CCMP消息挂起的情况
indefinitely, thus increasing the potential that pending requests continue to increase when is a server is receiving more requests than it can process.
无限期地增加了当服务器接收的请求超过其处理能力时，挂起的请求继续增加的可能性。
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.
本节给出了“application/ccmp+XML”格式的XML模式定义[W3C.REC-xmlschema-1-20041028][W3C.REC-xmlschema-2-20041028]。这是“应用程序/ccmp+xml”格式的正式定义。如第12节所述，新的XML名称空间、新的XML模式以及该模式的MIME类型在IANA中注册。请注意，此XML模式定义不打算用于状态XML文档的动态验证。模式中包括空格，以符合RFC格式的行长度限制，而不会对文档的可读性产生负面影响。任何合格的处理器都应删除前导和尾随空格。
<?xml version="1.0" encoding="utf-8"?>
<?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: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: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" />
<xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP request definition -->
<!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
<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 -->
<!-- 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>
<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 -->
<!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<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 -->
<!-- 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: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>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP REQUESTS -->
<!-- CCMP REQUESTS -->
<!-- blueprintsRequest -->
<!-- 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>
<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 -->
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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: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>
</xs:complexContent>
</xs:complexType>
<!-- confRequestType -->
<!-- confRequestType -->
<xs:element name="confRequest" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- usersRequestType -->
<xs:element name="usersRequest" type="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>
<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 -->
<!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<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>
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userRequestType -->
<!-- userRequestType -->
<xs:element name="userRequest" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<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>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefRequest -->
<!-- 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>
<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 -->
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- CCMP RESPONSES -->
<!-- blueprintsResponse -->
<!-- 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>
<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 -->
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="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: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>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse -->
<!-- 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>
<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 -->
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType" />
<xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsResponseType">
<xs:sequence>
<xs:element name="confsInfo" type="info:uris-type"
<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>
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponse -->
<!-- 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>
<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 -->
<!-- confResponseType -->
<xs:element name="confResponse" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- usersResponseType -->
<xs:element name="usersResponse" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- userResponseType -->
<xs:element name="userResponse" type="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>
<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 -->
<!-- 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: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>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="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>
<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 -->
<!-- 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>
<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 -->
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<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>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedResponse -->
<!-- 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>
<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 -->
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="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>
<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 -->
<!-- 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>
<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 -->
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="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>
<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 -->
<!-- CCMP ELEMENT TYPES -->
<!-- response-codeType-->
<!-- 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>
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
</xs:simpleType>
<!-- operationType -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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>
<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 -->
<!-- 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: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: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>
</xs:schema>
Figure 30: CCMP XML Schema
图30:CCMPXML模式
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.
此文档注册了新的XML名称空间、新的XML模式和模式的MIME类型。本文档还注册了“XCON”应用程序服务标签和“CCMP”应用程序协议标签，并定义了CCMP操作类型和响应代码的注册表。
This section registers a new XML namespace, "urn:ietf:params:xml:ns:xcon-ccmp".
本节注册了一个新的XML名称空间“urn:ietf:params:XML:ns:xcon-ccmp”。
URI: urn:ietf:params:xml:ns:xcon-ccmp
URI: urn:ietf:params:xml:ns:xcon-ccmp
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF XCON工作组(xcon@ietf.org)，玛丽·巴恩斯。barnes@gmail.com).
XML:
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
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
This section registers an XML schema per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:schema:xcon-ccmp
URI: urn:ietf:params:xml:schema:xcon-ccmp
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF XCON工作组(xcon@ietf.org)，玛丽·巴恩斯。barnes@gmail.com).
Schema: The XML for this schema can be found as the entirety of Section 11 of this document.
模式：此模式的XML可作为本文档第11节的全部内容找到。
This section registers the "application/ccmp+xml" MIME type.
本节注册“application/ccmp+xml”MIME类型。
To: ietf-types@iana.org
致：ietf-types@iana.org
Subject: Registration of MIME media type application/ccmp+xml
Subject: Registration of MIME media type application/ccmp+xml
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: ccmp+xml
MIME子类型名称：ccmp+xml
Required parameters: (none)
所需参数：（无）
Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC3023], Section 3.2.
可选参数：字符集与[RFC3023]第3.2节中规定的“应用程序/xml”的字符集参数相同。
Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC3023], Section 3.2.
编码注意事项：与[RFC3023]第3.2节中规定的“应用程序/xml”的编码注意事项相同。
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.
安全注意事项：此内容类型旨在承载与会议控制相关的协议数据。有些数据可能被认为是私有的。这种媒体类型不提供任何保护，因此需要第10节所述的其他机制来保护数据。此媒体类型不包含可执行内容。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: RFC 6503.
已发布规范：RFC6503。
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
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>
Person & email address to contact for further information: Mary
Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller: The IETF
作者/变更控制者：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.
其他信息：此媒体类型是application/xml[RFC3023]的一种专门化，其中描述的许多注意事项也适用于application/ccmp+xml。
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节定义了应用程序服务标签“XCON”，用于标识特定域的集中式会议（XCON）服务器。第12.4.2节中定义的应用协议标签“CCMP”用于标识理解CCMP的XCON服务器。
This section registers a new S-NAPTR/U-NAPTR Application Service tag for XCON, as mandated by [RFC3958].
本节根据[RFC3958]的规定，为XCON注册一个新的S-NAPTR/U-NAPTR应用程序服务标签。
Application Service Tag: XCON
应用程序服务标签：XCON
Intended usage: Identifies a server that supports centralized conferencing.
预期用途：标识支持集中会议的服务器。
Defining publication: RFC 6503
定义出版物：RFC 6503
Contact information: The authors of this document
联系方式：本文件的作者
Author/Change controller: The IESG
作者/变更控制员：IESG
12.4.2. Registration of a Conference Server Application Protocol Tag for CCMP
12.4.2. 为CCMP注册会议服务器应用程序协议标记
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for CCMP, as mandated by [RFC3958].
本节根据[RFC3958]的规定，为CCMP注册一个新的S-NAPTR/U-NAPTR应用协议标签。
Application Service Tag: CCMP
应用程序服务标签：CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Manipulation Protocol.
预期用途：标识集中式会议（XCON）操作协议。
Applicable Service Tag(s): XCON
适用的服务标签：XCON
Terminal NAPTR Record Type(s): U
终端NAPTR记录类型：U
Defining Publication: RFC 6503
定义出版物：RFC 6503
Contact Information: The authors of this document
联系方式：本文件的作者
Author/Change Controller: The IESG
作者/变更控制员：IESG
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.
IANA已为CCMP创建了一个新的注册表：http://www.iana.org/assignments/ccmp-parameters. 本文档为CCMP操作类型和响应代码创建初始子注册表。
The following summarizes the registry for CCMP messages:
以下总结了CCMP消息的注册表：
Related Registry: CCMP Message Types Registry
相关注册表：CCMP消息类型注册表
Defining RFC: RFC 6503.
定义RFC:RFC6503。
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.
注册/分配程序：按照[RFC5226]中概述的策略，需要为CCMP的CCMP消息类型分配新值的IANA策略。
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF XCON工作组(xcon@ietf.org)，玛丽·巴恩斯。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.
本规范在以下位置建立消息子注册表：http://www.iana.org/assignments/ccmp-messages. 初始消息表使用第4.1节中描述的CCMP消息填充，并在第11节的XML模式中定义。
Message Description Reference
------- ----------- ---------
optionsRequest Used by a conferencing client [RFC6503]
to query a conference server for
its capabilities, in terms of
supported messages.
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.
Options Response返回特定会议服务器支持的CCMP消息[RFC6503]列表。
blueprintsRequest Used by a conferencing client [RFC6503] to query a conference server for its capabilities, in terms of available conference blueprints.
蓝图会议客户端[RFC6503]使用的请求，用于根据可用的会议蓝图查询会议服务器的功能。
blueprintsResponse Returns a list of blueprints supported [RFC6503] by the specific conference server.
blueprintsResponse返回特定会议服务器支持[RFC6503]的蓝图列表。
blueprintRequest Sent to retrieve the conference object [RFC6503] associated with a specific blueprint.
发送blueprintRequest以检索与特定蓝图关联的会议对象[RFC6503]。
blueprintResponse Returns the conference object [RFC6503] associated with a specific blueprint.
blueprintResponse返回与特定蓝图关联的会议对象[RFC6503]。
confsRequest Used by a conferencing client [RFC6503] to query a conference server for its scheduled/active conferences.
confsRequest由会议客户端[RFC6503]用于查询会议服务器的计划/活动会议。
confsResponse Returns the list of the currently [RFC6503] activated/scheduled conferences at the server.
confsResponse返回服务器上当前[RFC6503]激活/计划的会议列表。
confRequest Used to create a conference object [RFC6503] and/or to request an operation on the conference object as a whole.
confRequest用于创建会议对象[RFC6503]和/或请求整个会议对象上的操作。
confResponse Indicates the result of the operation [RFC6503] on the conference object as a whole.
confResponse表示整个会议对象上的操作[RFC6503]的结果。
userRequest Used to request an operation on the [RFC6503] <user> element in the conference object.
userRequest用于请求会议对象中[RFC6503]<user>元素上的操作。
userResponse Indicates the result of the requested [RFC6503] operation on the <user> element in the conference object.
userResponse表示会议对象中<user>元素上请求的[RFC6503]操作的结果。
usersRequest Used to manipulate the <users> element [RFC6503] in the conference object, including parameters such as the <allowed-users-list>, <join-handling>, etc.
usersRequest用于操作会议对象中的<users>元素[RFC6503]，包括<allowed users list>、<join handling>等参数。
usersResponse Indicates the result of the request [RFC6503] to manipulate the <users> element in the conference object.
usersResponse表示请求[RFC6503]操作会议对象中的<users>元素的结果。
sidebarsByValRequest Used to retrieve the <sidebars-by-val> [RFC6503] element of the target conference object.
sidebarsByValRequest用于检索目标会议对象的<sidebars by val>[RFC6503]元素。
sidebarsByValResponse Returns the list of the sidebar-by-val [RFC6503] conferences within the target conference object.
sidebarsByValResponse返回目标会议对象中val[RFC6503]会议的侧栏列表。
sidebarsByRefRequest Used to retrieve the <sidebars-by-ref> [RFC6503] element of the target conference object.
sidebarsByRefRequest用于检索目标会议对象的<sidebars by ref>[RFC6503]元素。
sidebarsByRefResponse Returns the list of the sidebar-by-ref [RFC6503] conferences associated with the target conference object.
sidebarsByRefResponse返回与目标会议对象关联的参考[RFC6503]会议的侧栏列表。
sidebarByValRequest Used to request an operation on a [RFC6503] sidebar-by-val conference.
sidebarByValRequest用于请求val会议在[RFC6503]侧栏上执行操作。
sidebarByValResponse Indicates the result of the request to [RFC6503] manipulate a sidebar-by-val conference.
sidebarByValResponse表示请求[RFC6503]通过val会议操作侧栏的结果。
sidebarByRefRequest Used to request an operation on a [RFC6503] sideber-by-ref conference.
sidebarByRefRequest用于请求在[RFC6503]sideber by ref会议上进行操作。
sidebarByRefResponse Indicates the result of the request to [RFC6503] manipulate a sidebar-by-ref conference.
sidebarByRefResponse表示请求[RFC6503]按参考会议操作侧栏的结果。
The following summarizes the requested registry for CCMP response codes:
以下总结了请求的CCMP响应代码注册表：
Related Registry: CCMP Response Code Registry
相关注册表：CCMP响应代码注册表
Defining RFC: RFC 6503.
定义RFC:RFC6503。
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.
注册/分配程序：按照[RFC5226]中概述的政策，应要求为CCMP响应代码分配新值的IANA政策。
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF XCON工作组(xcon@ietf.org)，玛丽·巴恩斯。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:
本规范在下面建立响应代码子注册表http://www.iana.org/assignments/ccmp-parameters. 使用第5.4节中定义的响应代码填充初始响应代码表，如下所示：
Default
Response
Number String Description Reference
------ ------------- ------------ ---------
200 Success The request was successfully [RFC6503]
processed.
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.
400错误请求请求以某种方式[RFC6503]格式错误。
401 Unauthorized The user was not authorized for [RFC6503] the specific operation on the conference object.
401未授权用户未被授权[RFC6503]对会议对象进行特定操作。
403 Forbidden The specific operation is not [RFC6503] valid for the target conference object.
403禁止特定操作对目标会议对象无效[RFC6503]。
404 Object Not Found The specific conference object [RFC6503] was not found.
404找不到对象找不到特定的会议对象[RFC6503]。
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.
409冲突服务器无法成功完成请求的操作[RFC6503]。例如，无法应用对象的修改，因为对象的客户端版本已过时，并且请求的修改与存储在服务器上的对象的最新状态冲突。
420 User Not Found The user who is the target of the [RFC6503] requested operation is unknown.
420找不到用户[RFC6503]请求操作的目标用户未知。
421 Invalid confUserID The <confUserID> parameter of the [RFC6503] sender in the request is invalid.
421无效的confUserID请求中[RFC6503]发送方的<confUserID>参数无效。
422 Invalid Conference A request to access/manipulate [RFC6503] Password a password-protected conference object contained an invalid <conference-password> parameter.
422无效会议访问/操作[RFC6503]密码的请求受密码保护的会议对象包含无效的<Conference Password>参数。
423 Conference Password A request to access/manipulate [RFC6503] Required a password-protected conference object did not contain a <conference-password> parameter.
423会议密码访问/操作[RFC6503]的请求需要密码保护的会议对象不包含<Conference Password>参数。
424 Authentication The server wants to authenticate [RFC6503] Required the request through the <subject> parameter but the parameter is not provided in the request.
424身份验证服务器希望通过<subject>参数验证请求所需的[RFC6503]，但请求中未提供该参数。
425 Forbidden Delete The conferencing system cannot [RFC6503] Parent delete the specific conference object because it is a parent for another conference object.
425禁止删除会议系统无法[RFC6503]删除特定会议对象的父对象，因为它是另一个会议对象的父对象。
426 Forbidden Change The target conference object [RFC6503] Protected cannot be changed (e.g., due to policies, roles or privileges).
426禁止更改受保护的目标会议对象[RFC6503]无法更改（例如，由于策略、角色或特权）。
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.
427无效域名会议对象中[RFC6503]自动生成实例中的域名不在会议服务器的责任域内。
500 Server Internal The conference server experienced [RFC6503] Error some sort of internal error.
500服务器内部会议服务器遇到[RFC6503]错误某种内部错误。
501 Not Implemented The specific operation is not [RFC6503] implemented on the conferencing system.
501未执行特定操作[RFC6503]未在会议系统上执行。
510 Request Timeout The request could not be [RFC6503] processed within a reasonable time (as specified by the conferencing system).
510请求超时请求无法在合理时间内[RFC6503]处理（由会议系统指定）。
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.
511非可用资源由于资源问题，会议服务器无法[RFC6503]执行命令，例如，由于系统已达到会议数量限制，因此无法创建会议。
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.
作者感谢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）和Mykyta Yevstifeyev（IANA）。特别感谢Roberta Presta对本文件的宝贵贡献。罗伯塔曾在那不勒斯大学学习CCMP规范，准备她的硕士论文。她还实施了用于试验的CCMP原型，并从中提取了第6节中提供的转储。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[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.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，2008年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
[RFC6501]Novo，O.，Camarillo，G.，Morgan，D.，和J.Urpalainen，“集中会议的会议信息数据模型（XCON）”，RFC 65012012年3月。
[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-1-20041028]Beech，D.，Thompson，H.，Mendelsohn，N.，和M.Maloney，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<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>.
[W3C.REC-xmlschema-2-20041028]Biron，P.和A.Malhotra，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[REST] Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[REST]Fielding，“架构风格和基于网络的软件架构的设计”，2000年。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582]Camarillo，G.，Ott，J.，和K.Drage，“二进制地板控制协议（BFCP）”，RFC 4582，2006年11月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.
[RFC6502]Camarillo，G.，Srinivasan，S.，Even，R.，和J.Urpalainen，“集中会议的会议事件包数据格式扩展（XCON）”，RFC 65022002，2012年3月。
[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-part1-20070427]尼尔森，H.，门德尔松，N.，莫罗，J.，古德金，M.，哈德利，M.，拉丰，Y.，和A.卡马尔卡，“SOAP版本1.2第1部分：消息传递框架（第二版）”，万维网联盟建议REC-soap12-part1-20070427，2007年4月<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>.
[W3C.REC-soap12-part2-20070427]Moreau，J.，Gudgin，M.，Karmarkar，A.，Mendelsohn，N.，Hadley，M.，Lafon，Y.，和H.Nielsen，“SOAP版本1.2第2部分：附件（第二版）”，万维网联盟建议REC-soap12-part2-20070427，2007年4月<http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
Appendix A. Evaluation of Other Protocol Models and Transports Considered for CCMP
附录A.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.
本节提供了选择HTTP作为CCMP请求/响应传输的一些背景信息。除了HTTP之外，对象上的操作至少可以通过两种不同的方式实现，即远程过程调用——使用附录A.1中描述的SOAP和按照RESTful体系结构附录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.
在SOAP和RESTFUL方法中，服务器必须在每次更新请求中重新创建对象的内部状态表示，检查参数并触发函数调用。在SOAP方法中，可以为每个原子元素描述单独的操作，但这将大大增加协议的复杂性。CCMP的粗粒度方法确实要求服务器在未更改的更新中处理XML元素，并且在一个更新中可以有多个更改。对于CCMP，资源（REST）模型可能更具吸引力，因为会议操作符合CRUD方法。
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.
然而，这两种方法都不理想。SOAP被认为会带来额外的开销。应用RESTful方法是非常尴尬的，因为CCMP需要更复杂的请求/响应协议来维护服务器和客户端的数据。这并不能很好地映射到基本的请求/响应模型，响应通常表示请求是否成功，而不是提供额外的数据来维持客户端和服务器数据之间的同步。此外，CCMP客户端还可以在通知中接收数据。虽然某些会议客户端使用的通知方法或协议可以独立于CCMP，但服务器中的相同数据用于CCMP和通知-这需要传输层（例如HTTP）之上的服务器应用程序来维护数据，在CCMP模型中，数据对传输协议是透明的。
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
因此，本文档中定义的CCMP解决方案被视为过去最著名的候选方案中的一个很好的折衷方案，被称为“HTTP单动词传输+CCMP正文”。通过这种方法，CCMP能够利用现有的HTTP功能。与SOAP一样，CCMP使用“单一HTTP动词”进行传输（即，每个请求/响应对使用单一事务类型）；这允许将CCMP消息与HTTP消息分离。类似地，与任何RESTful方法一样，CCMP消息直接插入HTTP消息体中，从而避免了与其他中介相关的任何不必要的处理和通信负担。使用这种方法，不需要修改CCMP
messages/operations is required to use a different transport protocol.
使用不同的传输协议需要消息/操作。
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.
CCMP的远程过程调用（RPC）机制可以使用SOAP（简单对象访问协议[W3C.REC-soap12-part1-20070427][W3C.REC-soap12-part2-20070427]），其中会议和其他对象被建模为具有相关操作的服务。会议和其他对象由它们自己的本地标识符选择，例如用户的类似电子邮件的名称。这种方法的优点是，它可以轻松定义具有定义良好的错误条件的原子操作。
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.
所有SOAP操作都将使用一个HTTP谓词。虽然RESTful方法需要为每个对象使用URI，但SOAP可以使用任何令牌。
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.
会议对象也可以建模为URI标识的资源，基本CRUD操作映射到HTTP方法POST/PUT以创建对象，GET以读取对象，PATCH/POST/PUT以更改对象，DELETE以删除对象。许多对象（如会议）已经具有自然URI。
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.
CCMP可以映射到CRUD（创建、读取、更新、删除）设计模式中。基本CRUD操作用于操纵会议对象，这些对象是XML文档，包含指定会议实例的特征信息，无论是活动会议还是会议服务器通过简单的克隆操作创建新会议实例所使用的会议蓝图。
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].
遵循CRUD方法，CCMP可以使用通用协议（如HTTP[RFC2616]）来传输“集中式会议的会议信息数据模型”[RFC6501]中定义的特定于域的XML编码数据对象。
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.
继CRUD方法之后，CCMP可以遵循众所周知的REST（代表性状态转移）体系结构风格[REST]。CCMP可以通过指定资源URI、资源格式、每个URI支持的方法以及在特定URI上调用特定方法时必须返回的状态代码映射到REST原理。REST风格的方法必须确保所有操作都可以映射到HTTP操作。
The following summarizes the specific HTTP method that could be used for each of the CCMP Requests:
以下总结了可用于每个CCMP请求的特定HTTP方法：
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.
检索：可以在XCON URI上使用HTTP GET，以便客户端可以以XML数据模型文档的形式获取有关会议对象的数据。
Create: HTTP PUT could be used to create a new object as identified by the XCON-URI or XCON-USERID.
Create:httpput可用于创建由XCON-URI或XCON-USERID标识的新对象。
Change: Either HTTP PATCH or HTTP POST could be used to change the conference object identified by the XCON-URI.
更改：可以使用HTTP补丁或HTTP POST更改XCON-URI标识的会议对象。
Delete: HTTP DELETE could be used to delete conference objects and parameters within conference objects identified by the XCON-URI.
删除：HTTP Delete可用于删除XCON-URI标识的会议对象中的会议对象和参数。
Authors' Addresses
作者地址
Mary Barnes Polycom TX USA
美国德克萨斯州玛丽·巴恩斯宝利通公司
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com
Chris Boulton NS-Technologies
克里斯·博尔顿技术公司
EMail: chris@ns-technologies.com
EMail: chris@ns-technologies.com
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
西蒙彼得洛罗马诺大学那不勒斯经由克劳迪奥21那不勒斯80125意大利
EMail: spromano@unina.it
EMail: spromano@unina.it
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027
Henning Schulzrinne哥伦比亚大学计算机科学系，纽约州纽约市计算机科学大楼450号，邮编10027
EMail: hgs+xcon@cs.columbia.edu
EMail: hgs+xcon@cs.columbia.edu