[要約] RFC 6503は、中央集約型の会議システムにおいて、会議の作成、管理、および操作を行うためのプロトコルであるCCMP（Centralized Conferencing Manipulation Protocol）を定義しています。XMLを用いたメッセージ形式により、会議のスケジュール、参加者の権限設定、メディアストリームの制御などを遠隔から行う手順を規定しています。多様な会議クライアントとサーバー間での相互運用性を確保し、一貫した会議管理サービスを提供することを目的としています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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)".
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メッセージの詳細について説明します。会議の作成と操作に関連する典型的なコールフローを説明するCCMPの完全な非規範的な例をセクション6で提供します。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].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、[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-AWAREクライアント：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 .
........................................................
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を使用する会議システムに関連付けられたクライアントのアドレス指定と管理に必須 (REQUIRED) の識別子の詳細を説明します。
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
各会議にはゼロ以上のユーザーがいる場合があります。すべての会議参加者はユーザーですが、一部のユーザーは管理機能のみを持ち、メディアに貢献または受け取っていない場合があります。ユーザーは、エラーレポートを簡素化するために、一度に1人のユーザーが追加されます。親オブジェクトから会議がクローン化されると、ユーザーも同様に継承されているため、同じ参加者または共通の管理者を持つ会議を簡単に設定できます。Conference Serverは個々のユーザーを作成し、一意のConferenceユーザー識別子（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.
一般的なデータモデル。各CCMP要求は、セクション5.3.6で指摘されており、会議参加者としてのシステムの最初の入り口にあるユーザーのケースを表して、適切な<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データモデルで指定されているCommon <Conference-Info>要素で定義されているさまざまな要素を使用して、<ユーザー>要素を含む会議に関連するユーザーと、その中に含まれる各<ユーザー>要素を記述します。たとえば、特定のユーザーが<sold-users-list> in <users>：そのようなリストに関与する各<Target>要素を見ることにより、会議にどのように期待し、許可されているかを判断することができます。ユーザーが会議に参加することが期待される方法を定義する「メソッド」属性、つまり、ダイヤルが許可されているユーザーの「ダイヤルイン」、「ダイヤルアウト」、カンファレンスフォーカスが到達しようとしているユーザーの「ダイヤルアウト」（ 「ダイヤルイン」はデフォルトモードです）。会議が現在アクティブな場合、ダイヤルアウトユーザーにすぐに連絡します。それ以外の場合は、会議の開始時に連絡されます。会議制御プロトコルとして機能する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 AWAREクライアントを認証できます。したがって、登録された会議クライアントがCCMPサーバーに連絡したい場合はいつでも、「サブジェクト」パラメーターの一部として、ユーザー名とパスワードの両方をCCMPリクエストで携帯する必要があります。CCMPは、会議サーバーでユーザーのサブスクリプションを維持していません。したがって、クライアントが会議アカウントを登録できるようにする特定のメカニズムは提供されません。「サブジェクト」パラメーターは、事前に登録されたクライアントに関連付けられた認証データを運ぶために使用され、特定の登録モダリティはこのドキュメントの範囲外です。
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メッセージは、XMLドキュメントまたはXMLドキュメントフラグメントであり、XCONデータモデル表現[RFC6501]に準拠しています。
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に要約されているように、プロトコルモデルの各操作は原子であり、全体として成功または失敗します。会議サーバーは、特定の会議クライアントによって呼び出された操作が、同じ会議のオブジェクトでの別のクライアントの操作の前に完了するという点で、操作が原子的であることを確認しなければなりません (MUST)。このデータロック機能の詳細はCCMP仕様の範囲外であり、会議サーバーに特有の実装ですが、セクション4.2で説明されているように、データの整合性がCCMPによって提供されることを保証するためのコア機能があります。
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リクエストがHTTP PostメッセージのCCMP要求やHTTP 200 OK応答のCCMP応答を含む輸送ソリューションとしての使用を説明しています。この実装アプローチについては、セクション4.4でさらに説明します。
The main operations provided by CCMP belong in four general categories:
CCMPが提供する主な操作は、4つの一般的なカテゴリに属します。
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 サイドバーに関連付けられた会議オブジェクトは、どちらもメインカンファレンスに埋め込まれています（つまり、<sidebars-by-value>の<intry>要素）と外部（つまり、xcon-urisが<sidebarsの<Entry>要素に含まれています-by-ref>）、
o <user> elements associated with conference users, and
o <ユーザー>会議ユーザーに関連付けられた要素、および
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>パラメーターを含まなければなりません (MUST)。クライアントが会議オブジェクトの変更を含む更新メッセージをサーバーに送信し、変更がすべて正常に適用された場合、サーバーは、変更されたオブジェクトのバージョン番号を含む、<response-code>が「200」の応答を返さなければなりません (MUST)。この方式では、会議オブジェクトのバージョン「X」で作業しているクライアントが、バージョン番号が「X+1」である、<response-code>が「200」の応答を受信した場合、自分が操作したバージョンが最新であったと確信できます。しかし、応答に含まれるバージョンが「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」パラメーターは、サーバーにとって必要ないため、要求では任意です (OPTIONAL)。必要な変更が競合なしに対象の会議オブジェクトに適用できる限り、サーバーは、クライアントが情報の最新のビューを保存しているかどうかを気にしません。さらに、データの整合性を確保するために、会議サーバーは、会議オブジェクトの内部表現に変更を加える前に、まずすべてのパラメーターをチェックします。たとえば、会議の<subject>を変更した後で、<service-uris>のいずれかに無効な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はxが値が不明な各データモデルフィールドの一意の数値インデックス。サーバーでの処理を簡素化するために、ランダムな一意の文字列（FOO_BAR_LAなど）または非数量値の使用ではなく、このワイルドカードストリングが選択されます。 AUTO_GENERATE_Xの値は、特定の要求のコンテキスト内でのみ一意です。プレースホルダーのAUTO_GENERATE_Xの値は、属性または要素の値の部分の中になければなりません (MUST)（例: <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のインスタンスが属性／要素の値部分にない場合、サーバーは「400 Bad Request」の<response-code>を送信しなければなりません (MUST)。AUTO_GENERATE_XがURIのユーザー部分にのみ現れる場合（つまりXCON-USERIDまたはXCON-URIの場合）、サーバーは、ドメイン名がサーバーの責任ドメイン内のものであることを確認する必要があります。ドメイン名がサーバーの責任ドメイン内にない場合、サーバーは「427 Invalid Domain Name」の<response-code>を送信しなければなりません (MUST)。サーバーは、特定のワイルドカードフィールド（たとえばAUTO_GENERATE_1）の各インスタンスを、同じ識別子に置き換えなければなりません (MUST)。識別子は、要求で受信された同じXMLドキュメント内のAUTO_GENERATE_Xの各インスタンスごとに一意でなければなりません (MUST)。たとえば、AUTO_GENERATE_1を置き換える値は、AUTO_GENERATE_2を置き換える値と同じであってはなりません (MUST NOT)。AUTO_GENERATE_Xのインスタンスを置き換える値は、すべての会議オブジェクトで同じではないことに注意してください。たとえば、2つの異なるドキュメントでAUTO_GENERATE_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.
このアプローチを使用すると、データモデルの要件との互換性が維持され、サーバー側での会議オブジェクトのクライアントが開始する操作を可能にします。このメカニズムの使用は、新しいユーザーの作成や既存のカンファレンスに新しいユーザーを追加するなど、複数の操作を使用することにより、CANケースでは回避できることに注意してください。ただし、AUTO_GENERATE_Xメカニズムにより、単一の操作を使用して、会議オブジェクトに同じ変更を行うことができます。
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ポスト操作の本文に配置し、CCMP応答をHTTP応答メッセージの本文に配置します。考慮された他のアプローチの非網羅的な要約と、このドキュメントで説明されているHTTPソリューションの知覚された利点は、付録Aに記載されています。
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.
特定の期間。この場合、サーバーは保留中の要求に対して「510」の<response-code>を返すべきです (SHOULD)。さらに、この状況を緩和するため、クライアントは応答を無期限に待ってはならず (MUST NOT)、タイマーを実装しなければならず (MUST)、タイマーが満了したときにクライアントは接続を閉じなければなりません (MUST)。このタイマーのデフォルト値としては30秒が推奨されます (RECOMMENDED)。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メッセージには、コンテンツタイプ内に表示され、HTTPリクエストと応答のヘッダーフィールドを受け入れる「application/ccmp+xml」のMIMEタイプがあります。CCMPメッセージのXMLドキュメントは、UTF-8でエンコードしなければなりません (MUST)。この仕様は、[RFC3023]に記載されている推奨事項と規則に従って、タイプの命名規則（ 'xml'接尾辞）や「charset」パラメーターの使用法を含めます。「charset」パラメーターはXMLドキュメントに含めなければなりません (MUST)。セクション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メッセージは、リクエストまたは応答のいずれかです。一般的なCCMP要求メッセージは、セクション5.1で定義されています。一般的なCCMP応答メッセージは、セクション5.2で定義されています。CCMPリクエストと応答メッセージに掲載される特定のメッセージタイプの詳細については、セクション5.3で説明します。CCMP応答コードは、セクション5.4にリストされています。
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.
件名：会議システムに登録されているクライアントのユーザー名とパスワードを含むオプションの (OPTIONAL)パラメーター。会議システムを購読する各ユーザーは、それらの資格情報を装備していると想定されており、各CCMPリクエストにそれらを同封すべきです (SHOULD)。これらのフィールドを使用して、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を含む任意 (OPTIONAL) のパラメーター。XCON-USERIDは、会議システムのコンテキスト内で会議クライアントを識別するために使用され、会議サーバーと対話する会議クライアントごとに会議サーバーによって割り当てられます。<confUserID>パラメーターは、CCMPの要求および応答メッセージで必須です (REQUIRED)。ただし、XCON-USERIDを持たず、識別子が既知の会議にCCMP経由で参加したいユーザーの場合は例外です。そのような場合、要求の副作用として、ユーザーに適切なXCON-USERIDが提供されます。前述のケースの例は、セクション5.3.6で示されます。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confObjID：ターゲット会議オブジェクトのxcon-uriを含むオプションの (OPTIONAL)パラメーター。
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.
operation：特殊化された要求メッセージの種類を絞り込む任意 (OPTIONAL) のパラメーター。<operation>パラメーターは、blueprintsRequestおよびconfsRequestの特殊化されたメッセージを除くすべての要求で必須です (REQUIRED)。
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.
conference-password：このパラメーターは任意です (OPTIONAL)が、対象の会議オブジェクトがパスワードで保護されている（つまり[RFC6501]の<conference-password>要素を含む）すべての要求には挿入しなければなりません (MUST)。必要なときに会議パスワードが要求に含まれていない場合は、「423」のCCMP <response-code>を返さなければなりません (MUST)。
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リクエストメッセージに含めなければなりません (MUST)。特殊なメッセージと関連するパラメーターの詳細は、セクション5.3に記載されています。
<!-- Definition of CCMP Request -->
<xs:element name="ccmpRequest" type="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>
<!-- 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>
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要求メッセージを発行した会議クライアントのXCON-USERIDを含む、CCMP応答メッセージの必須 (REQUIRED) のパラメーター。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confObjID：ターゲット会議オブジェクトのxcon-uriを含むオプションの (OPTIONAL)パラメーター。
operation: An OPTIONAL parameter for CCMP response messages. This parameter is REQUIRED in all responses except for the "blueprintsResponse" and "confsResponse" specialized messages.
operation：CCMP応答メッセージの任意 (OPTIONAL) のパラメーター。このパラメーターは、「blueprintsResponse」および「confsResponse」の特殊化されたメッセージを除くすべての応答で必須です (REQUIRED)。
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.
response-code：要求に関連付けられた応答コードを含む必須 (REQUIRED) のパラメーター。応答コードは、セクション5.4に列挙されているコードから選択しなければなりません (MUST)。
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.
応答ストリング：応答に関連付けられたオプションの (OPTIONAL)理由文字列。特にエラーの場合、この文字列を使用して、クライアントにエラー自体に関する詳細情報を提供できます。
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.
version：confObjIDによって参照される会議オブジェクトの現在のバージョン番号を反映する任意 (OPTIONAL) のパラメーター。この番号は、その会議に関連する<conference-info>要素の'version'属性に含まれています。このパラメーターはCCMP応答メッセージでは必須であり (REQUIRED)、CCMP要求メッセージには含めるべきではありません (SHOULD NOT)。
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応答メッセージに含めるべきです (SHOULD)。この場合、会議サーバーは「400」の<応答コード>を返さなければなりません (MUST)。特殊なメッセージと関連するパラメーターの詳細は、セクション5.3に記載されています。
<!-- Definition of CCMP Response -->
<xs:element name="ccmpResponse" type="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>
<!-- 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>
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. blueprintsRequest/blueprintsResponse
2. confsRequest/confsResponse
2. conpsrequest/confsResponse
3. blueprintRequest/blueprintResponse
3. blueprintRequest/blueprintreasponse
4. confRequest/confResponse
4. confRequest/confResponse
5. usersRequest/usersResponse
5. usersRequest/usersResponse
6. userRequest/userResponse
6. userRequest/userRersponse
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. optionsRequest/optionsResponse
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>パラメーターを必要としないことに注意してください。エンティティは、サポートする各要求メッセージに対する応答メッセージをサポートしなければなりません (MUST)。対応する応答メッセージは、同じ<operation>パラメーターを含まなければなりません (MUST)。一部のエントリには「N/A」というラベルが付いており、その操作がその要求タイプに対して無効であることを示していることに注意してください。「N/A*」ラベルの場合、その操作は特定の特権ユーザーまたはシステム管理者に対して許可されてもよいです (MAY)が、本ドキュメントに含まれる機能の一部ではありません。
+---------------+------------+------------+------------+------------+
| 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.
（**）：このようなリクエストのターゲット要素である<ユーザー>セクションは、関連する会議の作成と削除と併せて作成および削除されるため、これらの操作はユーザーレクエストメッセージに対して許可されていません。資料。したがって、「更新」と「取得」は、そのようなメッセージの唯一の意味的に正しい操作です。
(***): 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>を返さなければなりません (MUST)。
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のリストをリクエストします。これらのXCON-URIは、その後、セクション5.3.3ごとに特定の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を反映しなければなりません (MUST)。blueprintsRequestメッセージは特定の会議インスタンスを対象とせず、「取得専用」の要求であるため、<confObjID>および<operation>パラメーターをblueprintsRequest/Responseメッセージに含めてはなりません (MUST NOT)。
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.
利用可能なブループリントの特定のサブセットを取得するために、クライアントは、要求の任意 (OPTIONAL) の「xpathFilter」パラメーターに適切なXPathクエリを指定することで、選択フィルターを指定できます。ブループリントの情報は通常、一般的な機能と特性を表します。たとえば、オーディオとビデオの両方のストリームをサポートするブループリントを選択するための、考えられるxpathFilterの値は次のとおりです："/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']"。会議サーバーは、ブループリントに機密情報（パスワードなど）を含めるべきではありません (SHOULD NOT)。
The associated blueprintsResponse message SHOULD contain, as shown in Figure 4, a "blueprintsInfo" parameter containing the above mentioned XCON-URI list.
関連するblueprintsResponseメッセージには、図4に示すように、上記のXCON-URIリストを含む「blueprintsInfo」パラメーターを含めるべきです (SHOULD)。
<!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType">
<xs:sequence>
<xs:element name="blueprintsInfo"
type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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を反映しなければなりません (MUST)。<confObjID>パラメーターは、confsRequestメッセージに含めてはなりません (MUST NOT)。confsRequestメッセージは、会議サーバーで利用可能な情報を収集することが唯一の目的であるため、取得専用タイプです。したがって、<operation>パラメーターをconfsRequestメッセージに含めてはなりません (MUST NOT)。利用可能な会議の特定のサブセットを取得するために、クライアントは、要求の任意 (OPTIONAL) の「xpathFilter」パラメーターに適切なXPathクエリを指定することで、選択フィルターを指定できます。たとえば、登録済みの会議のみを選択するための、考えられるxpathFilterの値は「/ conference-info[conference-description/conference-state/ active='false']」です。関連するconfsResponseメッセージは、「confsInfo」パラメーターにXCON-URIのリストを含めるべきです (SHOULD)。ユーザーは、応答メッセージを受信すると、さらなるCCMPメッセージを通じて、利用可能な会議オブジェクトと対話できます。
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType"/>
<xs:complexType name="confsResponseType">
<xs:sequence>
<xs:element name="confsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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>パラメーターを含まなければなりません (MUST)。繰り返しますが、<confUserID>パラメーターは、すべてのblueprintRequest/Responseメッセージに含められ、要求を発行する会議クライアントのXCON-USERIDを反映しなければなりません (MUST)。<confObjID>パラメーターは、ブループリントのXCON-URIを含まなければなりません (MUST)。この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>パラメーターを含むべきではありません (SHOULD NOT)。値が「create」、「update」、または「delete」の<operation>パラメーターは、特権ユーザー（たとえば会議サーバーの管理スタッフ）の場合を除き、blueprintRequestメッセージに含めるべきではありません (SHOULD NOT)。特権ユーザーは、「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.
利用可能なシステムの青写真の1つに値が関連付けられていない<confObjID>パラメーターを運ぶblueprintRequest/取得は、サーバーの側で「404」の<応答コード>を含むblueprintreasponseメッセージを生成します。これは、言及された<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.
「取得」操作の「200」の<応答コード>の場合、<blueprintInfo>パラメーターをblueprintResponseメッセージに含めなければなりません (MUST)。<blueprintInfo>パラメーターには、BluePrintre -Equestで指定された<sonfobjid>パラメーターで識別される青写真に関連付けられた会議文書が含まれています。
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType">
<xs:sequence>
<xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType"/>
<xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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クライアントは、アクティブな会議または登録済みの会議に関連付けられた会議オブジェクトを操作できます。<confUserID>パラメーターは、すべてのconfRequest/Responseメッセージに含められ、要求を発行する会議クライアントのXCON-USERIDを反映しなければなりません (MUST)。confRequestおよびconfResponseメッセージは、<operation>パラメーターも含まなければなりません (MUST)。confResponseメッセージは、要求元に<response-code>を返さなければならず (MUST)、それを説明する<response-string>を含んでもよいです (MAY)。操作の種類に応じて、<confObjID>および<confInfo>パラメーターがconfRequestおよび応答に含まれてもよいです (MAY)。操作の各種類について、以下のテキストでは、<confObjID>および<confInfo>パラメーターをconfRequestおよびconfResponseメッセージに含める必要があるかどうかを説明しています。
The creation case deserves care. To create a new conference through a confRequest message, two approaches can be considered:
作成事例はケアに値します。confRequestメッセージを通じて新しい会議を作成するには、2つのアプローチを考慮することができます。
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を含めなければなりません (MUST)が、<conpinfo>パラメーターはconfRequestに含まれてはなりません (MUST NOT)。アクティブな会議のクローニングは、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> パラメータを含めてはならず (MUST NOT)、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.
どちらの作成の場合も、「create」操作が正常に完了したときのconfResponseは、「200」の<response-code>を含み、会議クライアントがその後のCCMP要求を通じてその会議を操作できるようにするため、新しく作成された会議のXCON-URIを<confObjID>パラメーターに含めなければなりません (MUST)。さらに、作成された会議ドキュメントを含む<confInfo>パラメーターは、会議システム実装の裁量により含めてもよいです (MAY)。また、作成時点では会議オブジェクトは最初のバージョンであるため、「1」に初期化された必須 (REQUIRED) の<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.
「取得」の<OPERTION>パラメーターを使用したconfRequestの場合、ターゲット会議のxcon-uriを表す<confObjID>パラメーターを含めなければならず (MUST)、<confInfo>パラメーターをリクエストに含めてはなりません (MUST NOT)。会議サーバーは、confRequestの「取得」操作で受信される<confInfo>パラメーターを無視しなければなりません (MUST)。取得操作のfonsponseに「200」の<応答コード>が含まれている場合、<conpinfo>パラメーターを応答に含めなければなりません (MUST)。<confInfo>パラメーターには、現在の状態のターゲット会議オブジェクトを説明する会議文書全体を含めなければなりません (MUST)。取得した会議オブジェクトの現在の状態も、適切な「バージョン」応答パラメーターで報告しなければなりません (MUST)。
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:
<operation>パラメーターが「update」のconfRequestの場合、<confInfo>および<confObjID>パラメーターを要求に含めなければなりません (MUST)。<confInfo>は、識別子が<confObjID>パラメーターと同じ値を持つ会議に適用されるすべての変更を含む、「conference-type」型のオブジェクトを表します。このような場合、<confInfo>パラメーターは確かにXCONデータモデルに示されている規則に従う必要がありますが、その会議に適用する変更のみを伝えるため、対象会議の更新後の全体を表すものではないことに注意してください。たとえば、会議のタイトルを変更するには、<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.
同様に、既存の会議のタイトルを削除するために、以下の<conpenfo>パラメーターを運ぶコフレクエスト/アップデートがジョブを行います。
<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.
<response-code>が「200」のconfResponse/updateの場合、応答メッセージに追加情報は必須ではなく (REQUIRED)、つまり<confInfo>パラメーターを返すかどうかは任意です (OPTIONAL)。その後のconfRequest/retrieveトランザクションによって、変更後の会議の現在の状態をCCMPクライアントに提供できます。あるいは、通知プロトコルがそのタスクを担うこともあります。「200」の<response-code>は、要求に従って会議サーバーが会議オブジェクトを変更したことを示します。適用された変更後の現在の会議オブジェクトのバージョンをクライアントが把握できるようにするため、<version>パラメーターをconfResponse/updateメッセージに含めなければなりません (MUST)。「409」の<response-code>は、要求の<confInfo>パラメーターに反映された変更が実行不可能であることを示します。これは、ポリシー、要求者の役割、特定の権限、受け入れられない値などが原因である可能性があり、その理由は会議システムとその構成に固有です。「409」の<response-code>とともに、クライアントが変更しようとしたものが最新でなかった場合に、後で対象会議の現在のバージョンを取得できるようにするため、<version>パラメーターをconfResponse/updateに付加しなければなりません (MUST)。
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".
<operation>パラメーターが「delete」のconfRequestの場合、対象会議のXCON-URIを表す<confObjID>パラメーターを要求に含めなければならず (MUST)、<confInfo>パラメーターは要求に含めてはなりません (MUST NOT)。会議サーバーは、そのような要求内で受信した<confInfo>パラメーターを無視しなければなりません (MUST)。confResponseは、confRequestに含まれていたものと同じ値を<confObjID>パラメーターに含めなければなりません (MUST)。confResponse/delete操作が「200」の<response-code>を含む場合、<confObjID>パラメーターで示された会議は正常に削除されています。<response-code>が「200」のconfResponse/deleteは、<confInfo>パラメーターを含んではなりません (MUST NOT)。<version>パラメーターは、どのconfResponse/deleteでも返すべきではありません (SHOULD NOT)。使用中の別の会議オブジェクトの親であるために、confRequestで受信した<confObjID>パラメーターが参照する会議を会議サーバーが削除できない場合、会議サーバーは「425」の<response-code>を返さなければなりません (MUST)。
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.
「取得」、「更新」、または「削除」のパラメーターを含む<操作>パラメーターを含む<confObjID>パラメーターを運ぶパラメーターは、システムが保持している会議（アクティブまたは登録）に関連付けられていないパラメーターを生成します。サーバーの側、「404」の<応答コード>を含むfensponseメッセージ。これは、言及された<confObjID>パラメーターがサーバーに保存されている既存の会議オブジェクトに関連しているが、実際の会議ではなく青写真またはサイドバーに関連する場合にも当てはまります。
The schema for the confRequest/confResponse pair is shown in Figure 9.
confRequest/confResponseペアのスキーマを図9に示します。
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 9: Structure of the confRequest and confResponse Messages
図9：confRequestおよびfensponseメッセージの構造
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メッセージに含まれなければなりません (MUST)。
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.
a <usersininfo>パラメーターは、操作に応じてユーザーリケストメッセージに含まれる場合があります (MAY)。<usersInfo>パラメーターがusersRequestメッセージに含まれている場合、パラメーターはXCONデータモデルの<ユーザー>フィールドに準拠しなければなりません (MUST)。
Two operations are allowed for a usersRequest message:
ユーザーRequestメッセージの2つの操作が許可されています。
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".
Conference Serverは、「取得」の<操作>パラメーターを使用してリクエストで受信された場合、<usersInfo>パラメーターを無視しなければなりません (MUST)。
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>パラメーターには、示されている<ユーザー>要素に適用される変更を含めなければなりません (MUST)。<応答 - コード>の場合、「200」の場合、<usersInfo>パラメーターを返さないでください (SHOULD NOT)。返される<usersInfo>パラメーターは無視すべきです (SHOULD)。「426」の<応答コード>は、ConferencingクライアントがユーザーRequestメッセージに含まれる<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.
「Create」と「Delete」の操作は、ユーザーRequestメッセージには適用されず、サーバーが考慮してはなりません (MUST NOT)。つまり、「403」の<応答コード>をusersResponseメッセージに含めなければなりません (MUST)。
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="usersRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo"
type="info:users-type" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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>パラメーターによって識別された会議に関連付けられた会議ドキュメント内の<ユーザー>要素を操作するために使用されます。特定の会議ユーザーに関する情報を取得することに加えて、メッセージは、会議サーバーがユーザーに関する情報を作成、変更、または削除することを要求するために使用されます。userRequestメッセージには、<confObjID>および<操作>パラメーターを含めなければならず (MUST)、操作に応じて詳細なユーザー情報を含む<userininfo>パラメーターを含めることができます (MAY)。ユーザーが必ずしも会議制御クライアントであるとは限らないことに注意してください（つまり、会議の参加者の中には「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は、システムにサブスクライブされたすべてのユーザーに割り当てられるべきです (SHOULD)。このような方法では、会議参加者ではないユーザーは、会議の作成や会議情報の取得など、リクエストを行うことができます（承認と認証のチェックに成功した場合）。
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:
会議ユーザーは、さまざまな方法で作成できます。これらの各ケースでは、<操作>パラメーターをユーザーリクエストメッセージで「作成」するように設定しなければなりません (MUST)。これらのケースの各userResponseメッセージには、<confObjID>、<confUserID>、<operation>、および<応答 - コード>パラメーターが含まれていなければなりません (MUST)。「200」の<応答コード>の場合、userResponseメッセージには、ユーザーの作成方法に応じて<userInfo>パラメーターを含めることができます (MAY)。
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に含めてもよいです (MAY)。<userInfo>パラメーターは<user>要素（XCONデータモデルに準拠）を含まなければならず (MUST)、'entity'属性は、要求を開始するユーザーのXCON-USERIDを表す値に設定しなければなりません (MUST)。<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に含めなければなりません (MUST)。<userInfo>パラメーターは<user>要素を含まなければならず (MUST)、'entity'属性の値は、当該の別のユーザーのXCON-USERIDに設定しなければなりません (MUST)。<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経由で参加したい会議クライアント：この場合、要求の副作用として、応答の<confUserID>パラメーター内で運ばれる新しいXCON-USERID（サーバーによって作成される）がユーザーに提供されます。これは、空の<confUserID>パラメーターを運んでいてもCCMP要求が有効となりうる唯一のケースです。フォーカスが、そのユーザーを会議に追加するために必要なシグナリングフェーズを開始できるよう、要求には、少なくとも参加するクライアントの連絡先URIを提供する<userInfo>パラメーターを含めなければなりません (MUST)。要求内の<userInfo>パラメーターの必須の'entity'属性には、XCONデータモデルXMLスキーマに含まれる規則に適合させるため、セクション4.3で説明されているように、XCON-USERIDのユーザー部分がAUTO_GENERATE_Xの値を含むプレースホルダー値を設定しなければなりません (MUST)。この場合のメッセージ（userRequestとuserResponse）は、次のようになります。
Request fields:
リクエストフィールド：
confUserID=null;
confObjID=confXYZ;
operation=create;
userInfo=
<userInfo entity="xcon-userid:AUTO_GENERATE_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
Figure 11: userRequest and userResponse in the Absence of an xcon-userid
図11：XCON-USERIDがない場合のuserRequestとusererSponse
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 会議クライアントが第3のユーザーのXCON-USERIDを認識していない場合: この場合、リクエスト内のXCON-USERIDである <confUserID> は送信者のものであり、添付された <userInfo> パラメータの「entity」属性にはプレースホルダー値 "xcon-userid:AUTO_GENERATE_1@example.com" が設定されます。<response-code> が "200" の場合、第3のユーザーに対するXCON-USERIDは、レスポンスの <userInfo> パラメータの「entity」属性としてリクエストを発行したクライアントに返送されなければなりません (MUST)。このシナリオは、第三者（サードパーティ）によって会議に全く新しい会議システムユーザーが追加される場合（すなわち、まだXCON-USERIDが付与されていないユーザー）と、リクエストを発行するCCMPクライアントが追加対象ユーザーのXCON-USERIDを知らない場合（サーバー側にはすでにそのユーザーの識別子が存在している可能性があることを意味します）の双方をサポートすることを意図しています。後者の場合、会議サーバーはシグナリングURIなどのリクエストで提供された <userInfo> パラメータ内の主要フィールドを確認し、同一会議クライアントに対するXCON-URIの重複を回避する責務を負います。参加するユーザーが全く新しい場合は新しいXCON-USERIDの生成が必要であり、そうでない場合（そのユーザーがすでに存在する場合）はサーバーが対応する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
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.
userRequestメッセージ。クライアントが指定された会議で自分のプロフィールに関する情報を取得したい場合は、取得要求に<userInfo>パラメーターが必要です。一方、クライアントが指定された会議内で他の誰かの情報を取得したい場合は、「エンティティ」属性が目的のユーザーのXCON-USERIDを伝える「エンティティ」属性がその<userInfo>パラメーターをuserRequest/取得に含めなければなりません (MUST)。取得操作のuserResponseに「200」の<応答コード>が含まれている場合、<userininfo>パラメーターを応答に含めなければなりません (MUST)。
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.
「update」のパラメーターを備えたユーザーリケストの場合、<confObjID>、<confUserID>、および<userInfo>パラメーターをリクエストに含めなければなりません (MUST)。 <userInfo>パラメーターは「user-type」タイプであり、userRequestメッセージの<confObjID>パラメーターで識別されたカンファレンスオブジェクトの特定の<ユーザー>要素に適用するすべての変更を含みます。変更されるユーザーは、リクエストに含まれる<userInfo>パラメーターの「エンティティ」属性を介して識別されます。 「200」の<応答コード>を備えたuserResponseの場合、userResponseメッセージには追加情報は必要ありません。 「200」の<応答コード>は、参照される<ユーザー>要素が会議サーバーによって更新されたことを示しています。 「426」の<応答コード>は、最初のリクエストで<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.
「delete」の<操作>パラメーターを備えたuserRequestの場合、ターゲット会議のxcon-uriを表す<confObjID>を含めなければなりません (MUST)。 CCMPクライアントのXCON-USERIDを含む<Conduserid>パラメーターは、userRequestメッセージに含めなければなりません (MUST)。クライアントが指定された会議を終了したい場合は、削除要求に<userInfo>パラメーターが必要です。一方、クライアントが指定された会議から別の参加者を削除したい場合は、「エンティティ」属性がその参加者のXCON-USERIDを伝える「エンティティ」属性がその<userInfo>パラメーターをuserRequest/delete a <userInfo>パラメーターに含めなければなりません (MUST)。 userResponseには、userRequestの<confObjID>パラメーターに含まれていた<sonfobjid>パラメーターに対して同じ値を含めなければなりません (MUST)。ターゲット<ユーザー>要素が正常に削除されている場合、userresresponseには「200」の<応答コード>を含めなければなりません (MUST)。削除操作のuserResponseに「200」の<応答コード>が含まれている場合、userResponseには<userInfo>パラメーターが含まれてはなりません (MUST NOT)。
<!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo"
type="info:user-type" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="userResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 12: Structure of the userRequest and userResponse Messages
図12：userRequestおよびuserResresponseメッセージの構造
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メッセージは取得専用タイプであるため、<operation>パラメーターをsidebarsByValRequestメッセージに含めてはなりません (MUST NOT)。ブループリントや会議と同様に、CCMPでは、サーバー側で利用可能なサイドバーの選択されたサブセットをクライアントが取得する必要がある場合は常に、XPathフィルターを使用できます。これは、参照によるサイドバーと値によるサイドバーの両方に適用されます。<response-code>が「200」のsidebarsByValResponseメッセージは、目的の<sidebars-by-val>要素を含む<sidebarsByValInfo>パラメーターを含まなければなりません (MUST)。sidebarsByValResponseメッセージは、対象のサイドバーが関連付けられているメイン会議オブジェクト（つまり、識別子が要求の<confObjID>フィールドに含まれているもの）の現在のバージョンに関する<version>要素をクライアントに返さなければなりません (MUST)。<sidebarsByValInfo>パラメーターは、メイン会議から派生した値によるサイドバーに関連付けられた会議オブジェクトのリストを含みます。取得したサイドバーは、セクション5.3.8で説明するsidebarByValRequestメッセージを使用して、更新または削除できます。
<!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType">
<xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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メッセージには、特定のサイドバーの検索、作成、修正、および削除を区別する<portion>パラメーターを含めなければなりません (MUST)。他の必要なパラメーターは、操作の種類によって異なります。
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.
「create」操作の場合、<confObjID>パラメーターをsidebarbyValRequestメッセージに含めなければなりません (MUST)。この場合、<confObjID>パラメーターは、サイドバーを作成する対象のメイン会議のXCON-URIを含みます。「sidebarByValInfo」パラメーターが含まれていない場合、サイドバーは、XCONフレームワーク[RFC5239]で想定されているとおり、実装固有のクローニング規則に従ってメイン会議をクローニングすることで作成されます。そうでない場合は、直接作成の場合と同様に、サイドバー会議オブジェクトは、要求者が提供する「sidebarByValInfo」パラメーターに基づいて構築されます。値によるサイドバーの作成の結果として、会議サーバーは、sidebarbyValRequest/createメッセージの<confObjID>パラメーターで示されるメイン会議オブジェクトを、新しいサイドバーオブジェクトを適切なセクション<sidebars-by-val>に新しい<entry>として追加する形で更新しなければなりません (MUST)。新しく作成されたサイドバー会議オブジェクトは、<response-code>が「200」の場合、sidebarByValResponseの<sidebarByValInfo>パラメーターに含めてもよいです (MAY)。新しく作成されたサイドバーのXCON-URIは、応答の<confObjID>パラメーターに現れなければなりません (MUST)。会議サーバーは、会議イベントパッケージを購読しており、会議へのサイドバー追加の通知を受信する権限を持つ会議クライアントに通知できます。
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.
<operation>パラメーターが「retrieve」であるsidebarByValRequestメッセージの場合、（create操作への応答として、またはsidebarsByValResponseメッセージで受信した）サイドバー用に作成された会議オブジェクトのURIを、要求の<confObjID>パラメーターに含めなければなりません (MUST)。このretrieve操作は、セクション5.3.4で説明されているとおり、confRequestメッセージに含まれる<operation>パラメーターが「retrieve」である場合と同じ方法で、会議サーバーによって処理されます。
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メッセージの場合、<sidebarByValInfo>もリクエストに含めなければなりません (MUST)。リクエストメッセージに含まれる<confObjID>パラメーターは、更新される特定のサイドバーインスタンスを識別します。<sidebarByValInfo>パラメーターに含まれる特定のサイドバーインスタンスの更新操作は、セクションで詳述されているように、コンフレクエストメッセージに含まれる<confInfo>パラメーターに反映されているように、会議インスタンスの更新操作と同じ方法で会議サーバーによって処理されます。5.3.4。sidebarByValResponseメッセージは、リクエストの<sonfobjid>フィールドに識別子が含まれているサイドバーの現在のバージョンに関連するクライアントA <バージョン>要素に戻さなければなりません (MUST)。
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.
<operation>パラメーターが「delete」であるものがsidebarByVal要求に含まれている場合、<sidebarByValInfo>パラメーターを要求に含めてはなりません (MUST NOT)。要求に含まれる<sidebarByValInfo>は、会議サーバーによって無視されなければなりません (MUST)。サイドバーに関連付けられた会議オブジェクトのURIは、要求の<confObjID>パラメーターに含めなければなりません (MUST)。要求の<confUserID>パラメーターに反映されている特定の会議ユーザーが会議を削除する権限を持つ場合、会議サーバーは<confObjID>パラメーターで示される会議オブジェクトを削除し、サイドバーのクローン元となった会議オブジェクトのデータを更新します。会議サーバーは、会議イベントパッケージを購読しており、会議からのサイドバー削除の通知を受信する権限を持つ会議クライアントに通知できます。
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.
「取得」、「更新」、または「削除」の<portions>パラメーターを備えたsidebarByValRequestには、既存のサイドバーに関連付けられていない<confObjID>パラメーターが含まれている場合、A <Response-Codeを含むfenSponseメッセージが含まれます。>「404」がサーバー側に生成されます。これは、言及された<confObjID>パラメーターがサーバーに保存されている既存の会議オブジェクトに関連しているが、青写真または実際の会議、またはサイドバーではなくサイドバーごとに関連する場合にも当てはまります。-val。
<!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByValRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType" />
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByValResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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と同様に、<confObjID>パラメーターで識別される会議オブジェクトの<sidebars-by-ref>要素を取得するために、sidebarsByRefRequestを呼び出すことができます。sidebarsByRefRequestメッセージは取得専用タイプであるため、<operation>パラメーターをsidebarsByRefRequestメッセージに含めてはなりません (MUST NOT)。<response-code>が「200」の場合、会議オブジェクトの<sidebars-by-ref>要素を含む<sidebarsByRefInfo>パラメーターを、応答に含めなければなりません (MUST)。<sidebars-by-ref>要素は、メイン会議に関連付けられたサイドバーのURIの集合を表し、その記述（標準的なXCON会議ドキュメントの形式）はメイン会議自体の外部にあります。取得したURIを通じて、セクション5.3.10で説明するsidebarByRefRequestメッセージを使用して、個々のサイドバーにアクセスできます。sidebarsByRefResponseメッセージは、対象のサイドバーが関連付けられているメイン会議オブジェクト（つまり、識別子が要求の<confObjID>フィールドに含まれているもの）の現在のバージョンに関する<version>要素を、クライアントに返さなければなりません (MUST)。
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByref-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence>
<xs:element name="sidebarsByRefInfo"
type="info:uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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メッセージは、リクエストの<sonfobjid>フィールドに識別子が含まれているサイドバーの現在のバージョンに関連するクライアントA <バージョン>要素に戻さなければなりません (MUST)。
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.
作成操作の場合、<confObjID>パラメーターをsidebyRefRequestメッセージに含めなければなりません (MUST)。この場合、<confObjID>パラメーターには、サイドバーを作成する必要があるメインカンファレンスのxcon-uriが含まれています。 XCONフレームワーク[RFC5239]に従って、<sidebarByRefInfo>パラメーターが含まれていない場合、サイドバーはメイン会議のクローニングによって作成され、実装固有のクローニングルールを観察します。それ以外の場合、直接作成の場合と同様に、サイドバーカンファレンスオブジェクトは、要求者が提供する<sidebarByRefInfo>パラメーターに基づいて構築されます。サイドバーの作成が成功した場合、会議サーバーは、サイドバーが作成された会議オブジェクトの<sidebar-by-ref>要素を更新しなければなりません (MUST)（つまり、元のsidebarByRefRequestの<confObjID>で識別されます）、新しく作成されたサイドバーのURI。新しく作成されたカンファレンスオブジェクトは、「200」の<応答コード>を含む<sidebarByRefInfo>パラメーターの応答に含めることができます (MAY)。新しく作成されたサイドバーオブジェクトに関連付けられた会議オブジェクトのURIは、応答の<sonfobjid>パラメーターに表示しなければなりません (MUST)。会議サーバーは、会議イベントパッケージを購読し、会議へのサイドバーの追加の通知を受け取ることが許可されている会議クライアントに通知できます。
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.
「取得」の<操作>パラメーターを備えたサイドバルビレフレクエストメッセージの場合、サイドバー用に作成されたカンファレンスオブジェクトのURIは、リクエストの<confObjID>パラメーターに含めなければなりません (MUST)。<sidebarByRefInfo>の取得操作は、セクション5.3.4で詳述されているように、conprequestメッセージに含まれているconfInfoの取得操作と同じ方法で会議サーバーによって処理されます。
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.
「update」の<操作>パラメーターを備えたサイドバルビレフレクエストメッセージの場合、サイドバー用に作成されたカンファレンスオブジェクトのURIは、リクエストの<confObjID>パラメーターに含めなければなりません (MUST)。<sidebarByRefInfo>は、「更新」操作の場合にもリクエストに含めなければなりません (MUST)。<sidebarByRefInfo>の更新操作は、セクション5.3.4で詳述されているように、<confInfo>の更新操作と同じ方法で会議サーバーによって処理されます。sidebarByRefResponseメッセージは、識別子がリクエストの<confObjID>フィールドに含まれているサイドバーの現在のバージョンに関連するクライアントA <バージョン>要素に戻さなければなりません (MUST)。
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.
<operation>パラメーターが「delete」であるものがsidebarByRefRequestに含まれている場合、<sidebarByRefInfo>パラメーターを要求に含めてはなりません (MUST NOT)。要求に含まれる<sidebarByRefInfo>は、会議サーバーによって無視されなければなりません (MUST)。サイドバーの会議オブジェクトのURIは、要求の<confObjID>パラメーターに含めなければなりません (MUST)。要求の<confUserID>パラメーターに反映されている特定の会議ユーザーが会議を削除する権限を持つ場合、会議サーバーは、<confObjID>パラメーターで示される会議オブジェクトを削除すべきであり (SHOULD)、サイドバーの元のクローン元となった会議オブジェクトの<sidebars-by-ref>要素を更新すべきです (SHOULD)。会議サーバーは、会議イベントパッケージを購読しており、サイドバー削除の通知を受信する権限を持つ会議クライアントに通知できます。
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.
「取得」、「更新」、または「削除」の<操作>パラメーターを備えたサイドバルビレフレクエストには、既存のサイドバーごとに関連付けられていない<confObjID>パラメーターが含まれている場合、<response-codeを含むconfResponseメッセージ>「404」がサーバー側に生成されます。これは、言及された<confObjID>パラメーターの値がサーバーに保存されている既存の会議オブジェクトに関連しているが、青写真または実際の会議、またはではなくサイドバーごとに関連する場合にも当てはまります。サイドバーごと。
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
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仕様で明示的に想定されていない会議制御メカニズムを実現するのに必要な情報を運ぶことができます。これらのメカニズムを、この文脈では「拡張」と呼びます。各拡張は適切な名前によって特徴付けられるものとし、その名前は、extendedRequest/extendedResponseのペアの<extensionName>フィールドで運ばなければなりません (MUST)。拡張固有の情報は、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サーバーでサポートされている拡張機能を決定し、optionsRequest/ optionsResponse CCMPトランザクションを使用して関連する特定の要素を定義するXMLスキーマを回復できるべきです (SHOULD)（セクション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.
基本的なCCMPリクエストと応答メッセージから拡張レクエストと拡張機能によって継承される一般的なCCMPパラメーターの意味は、拡張機能を定義しながら適切に保存および悪用すべきです (SHOULD)。
<!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string"
minOccurs="1"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
Figure 17: Structure of the extendedRequest and extendedResponse Messages
図17：拡張レクエストと拡張レスポンスメッセージの構造
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.
optionsRequestメッセージ（図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:
optionsResponseは、適切な<options>フィールドで、この仕様で定義されているサポートされているCCMPメッセージペアのリストを返します。これらのメッセージは、<standard-message>要素に反映されるサポートされている各メッセージを含むリストの形式です。optionsResponseメッセージでは、<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> 必須 (REQUIRED)：標準メッセージの場合、本ドキュメントで定義されている10個の標準メッセージ名（つまり「blueprintsRequest」、「confsRequest」など）のいずれかになります。拡張の場合、この要素は、対応するextendedRequest/ extendedResponseメッセージペアに挿入された<extension-name>と同じ値を運ばなければなりません (MUST)。
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> 任意 (OPTIONAL)：このフィールドは<operation>エントリのリストであり、各エントリは、そのメッセージについてサーバーがサポートする作成、読み取り、更新、削除（CRUD）操作を表します。この要素がない場合、クライアントは、サーバーが次のことができると想定すべきです (SHOULD)
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> 任意 (OPTIONAL)：すべてのCCMPメッセージは、（<any>要素および属性の存在により）CCMPスキーマで想定されていないXML要素を含む可能性があるため、そのような新しい要素/属性を指定する適切なスキーマ定義への参照も、このフィールドによってクライアントに返送できます。この要素がない場合、CCMP仕様で明示的に定義されているもの以外の新しい要素は、メッセージに導入されません。
o <description> (OPTIONAL): human-readable information about the related message.
o <description> 任意 (OPTIONAL)：関連するメッセージに関する人間が読める情報。
The only parameter needed in the optionsRequest is the sender confUserID, which is mirrored in the same parameter of the corresponding optionsResponse.
optionsRequestで必要な唯一のパラメーターは、Sender confUserIDです。これは、対応するoptionsResponseの同じパラメーターにミラーリングされます。
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サーバーは、少なくとも1つの操作について要求メッセージと応答メッセージの両方を処理できることが必須である (REQUIRED)ため、optionsResponseに、少なくとも1つの<operation>要素を含む<standard-message-list>を含めなければなりません (MUST)。
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type"/>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message"
type="standard-message-type"
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name"
type="standard-message-name-type"
minOccurs="1"/>
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def"
type="xs:string" minOccurs="0"/>
<xs:element name="description"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<!-- operations-type -->
<xs:complexType name="operations-type">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
Figure 18: Structure of the optionsRequest and optionsResponse Messages
図18：optionsRequestとoptionsResponseメッセージの構造
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応答メッセージには、<応答コード>を含めなければなりません (MUST)。このドキュメントでは、セクション12.5.2で説明されているように、CCMP応答コードのIANAレジストリを定義します。以下は、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).
サーバーで欠落しているターゲットユーザー（userRequestsに含まれている場合、<userinInfo>パラメーターの「エンティティ」属性の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.
「Conference-Password」は、パスワードで保護された会議オブジェクトにアクセスするリクエストにありません。
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.
ConferenceオブジェクトのAUTO_GENERATE_Xインスタンスのドメイン名は、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」の<応答コード>の処理は、特殊なメッセージ応答の特定の操作にのみ適用できます。詳細については、セクション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 | |
+----------+-------------+--------------+-------------+-------------+
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.
(*) "userRequest/create" 操作に対する応答としての "420": サードパーティによる招待の場合、追加対象ユーザーの <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"は、userRequestへの回答で送信されません/「null」confUserIDを持つメッセージを作成します。このケースは、自分の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」の<応答コード>の場合、会議クライアントは、会議クライアントまたは会議サーバーに固有の期間内にリクエストを再取り付けすることができます (MAY)。
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>は、会議クライアントが不正な形式の要求を送信したことを示しており、これは会議クライアントまたは会議サーバーのエラーを示唆しています。その処理は会議クライアントの実装に固有です（たとえば、ログの生成、エラーメッセージの表示など）。この場合、クライアントが要求を再試行することは推奨されません (NOT RECOMMENDED)。
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>は、クライアントが適切な権限を持っていないか、権限にエラーがあることを示します。要求を再試行しても成功する可能性は低いため、再試行は推奨されません (NOT RECOMMENDED)。
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.
予期しないまたは不明な<応答コード>は、「500」の<応答コード>と同じ方法でクライアントによって扱われるべきです (SHOULD)。
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. アリスは、サーバーから利用可能な青写真のリストを取得します（セクション6.1）。
2. Alice asks for detailed information about a specific blueprint (Section 6.2);
2. アリスは、特定の青写真に関する詳細情報を求めています（セクション6.2）。
3. Alice decides to create a new conference by cloning the retrieved blueprint (Section 6.3);
3. アリスは、検索された青写真をクローン化することにより、新しい会議を作成することにしました（セクション6.3）。
4. Alice modifies information (e.g., XCON-URI, name, and description) associated with the newly created blueprint (Section 6.4);
4. アリスは、新しく作成された青写真（セクション6.4）に関連付けられた情報（XCON-URI、名前、説明など）を変更します。
5. Alice specifies a list of users to be contacted when the conference is activated (Section 6.5);
5. アリスは、会議がアクティブ化されたときに連絡するユーザーのリストを指定します（セクション6.5）。
6. Alice joins the conference (Section 6.6);
6. アリスが会議に参加します（セクション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. アリスは、CCMPサーバー機能を要求します（セクション6.8）。
9. Alice exploits an extension of the CCMP server (Section 6.9).
9. アリスは、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.
このセクションでは、青写真の取得に関連するトランザクションと、交換された2つのメッセージのダンプ（blueprintsRequestとblueprintsResponse）を示しています。図に示すように、blueprintsResponseメッセージには、<blueprintsInfo>パラメーターに、利用可能な青写真に関する情報が含まれています。と目的。
Alice retrieves from the server the list of available blueprints:
アリスは、利用可能な青写真のリストをサーバーから取得します。
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. BluePrintsリクエストメッセージ：
<?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. サーバーからのblueprints応答メッセージ：
<?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>
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.
このセクションでは、全体的なフローの2番目のトランザクションを示しています。この場合、サーバーで利用可能な青写真のXcon-urisを知っているアリスは、CCMP blueprintRequestメッセージの形でドリルダウンクエリを作成し、そのうちの1つに関する詳細情報を取得します（xcon-uri "xcon：audioroom@example.com"）。写真はそのようなトランザクションを示しています。応答には、<blueprintInfo>パラメーターに、標準のXCONデータモデルに準拠したドキュメントが含まれていることに注意してください。
Alice retrieves detailed information about a specified blueprint:
アリスは、指定された青写真に関する詳細情報を取得します。
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>
2. blueprintResponse message from the server:
2. サーバーからのblueprintResponseメッセージ：
<?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>
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
このセクションでは、全体的なフローの3番目のトランザクションを示しています。アリスは、XCon-URI「XCON：audioroom@example.com」を含む青写真をクローン化することにより、新しい会議を作成することを決定しました。これは、<confObjID>パラメーターにblueprintのURIを持つconfRequest/createメッセージを送信することによって達成されます。写真はそのようなトランザクションを示しています。応答には、<conponfo>パラメーターに、標準の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>要素の「エンティティ」属性の値に等しいことに注意してください。
Alice creates a new conference by cloning the "xcon:AudioRoom@example.com" blueprint:
アリスは、「xcon：audioroom@example.com」BluePrintをクローン化することにより、新しい会議を作成します。
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. confRequestメッセージ：
<?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. サーバーからのfensponseメッセージ：
<?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.
このセクションでは、全体的なフローの4番目のトランザクションを示しています。アリスは、彼女が作成したばかりの会議に関連する詳細のいくつかを変更することにしました。より正確には、彼女は会議を表すドキュメントの<Conference-Description>要素の下で<ディスプレイテキスト>要素を変更します。これは、必要な変更を適用する必要がある会議文書の断片を運ぶconfRequest/updateメッセージを通じて達成されます。写真に示すように、応答には「200」のコードが含まれており、クライアントが要求した変更を認め、「バージョン」パラメーターに反映されているように、1〜2の会議バージョン番号を更新します。
Alice updates information about the conference she just created:
アリスは、彼女が作成したばかりの会議に関する情報を更新します。
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. confRequestメッセージ：
<?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>
2. confResponse message from the server:
2. サーバーからのfensponseメッセージ：
<?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.
このセクションでは、全体的なフローの5番目のトランザクションを示しています。アリスは、彼女が作成した会議に関連付けられているドキュメントの<ユーザー>要素の下で<Aldaup-users-list>を変更します。これを達成するために、彼女はCCMPが提供するユーザーRequestメッセージを利用します。
Alice updates information about the list of users to whom access to the conference is permitted:
アリスは、会議へのアクセスが許可されているユーザーのリストに関する情報を更新します。
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. usersRequestメッセージ：
<?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. サーバーからのusersResponseメッセージ：
<?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.
本節では、全体フローにおける第6のトランザクションを示します。AliceはCCMPを使用して、新しく作成された会議に自身を追加します。これは、<userInfo> パラメータ内にXCONデータモデル表現に準拠した <user> 要素を含む userRequest/create メッセージを通じて実現されます。このような要素には、ユーザーのアドレスオブレコードおよび現在のエンドポイントに関する情報が含まれている点に注意してください。下図はこのトランザクションを示しています。<confUserID> パラメータが <userInfo> 要素の「entity」属性と等しくなっており、クライアントによって発行されたリクエストがファーストパーティのものであることを示している点に注目してください。
Alice joins the conference by issuing a userRequest/create message with her own ID to the server:
Aliceは、ユーザーRequest/Createメッセージを自分のIDでサーバーに発行することにより、会議に参加します。
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. userRequestメッセージ：
<?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>
Figure 24: Alice Joins the Conference through CCMP
図24：アリスは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.
本節では、全体フローにおける第7かつ最後のトランザクションを示します。AliceはCCMPを使用して、新しい会議システムユーザーであるCiccioを会議に追加します。この「サードパーティ」リクエストは、<userInfo> パラメータ内にXCONデータモデル表現に準拠した <user> 要素を含む userRequest/create メッセージを通じて実現されます。このような要素にはCiccioのアドレスオブレコードおよび現在のエンドポイントに関する情報が含まれますが、Aliceは最初CiccioのXCON-USERIDを知らないため、4.3節で論じたように「entity」属性にはプレースホルダーである "AUTO_GENERATE_1@example.com" が設定される点に注意してください。したがって、会議サーバーは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 |
| |
|<------------------------------------------------------|
| |
. .
. .
1. "third-party" userRequest message from Alice:
1. Aliceからの「サードパーティ」userRequestメッセージ:
<?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>
2. "third-party" userResponse message from the server:
2. サーバーからの「サードパーティ」userResponseメッセージ:
<?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：アリスは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メッセージと、optionsRequest/optionsResponseトランザクションを介して相互作用するCCMPサーバーによってどの拡張機能がサポートされているかを発見する方法を示します。
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:
optionsRequestを準備するために、AliceはXCON-USERIDを<confUserID>パラメーターに入れます。受信したoptionsResponseの<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 サーバーは、<standard-message-list>に表示されないため、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メッセージの唯一の実装された操作は「取得」です。これは、関連する<操作>フィールドに他の<OPERTION>エントリが含まれていないためです。
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.
<extended-message-list>を分析することにより、アリスは、この例では「confSummaryRequest」と呼ばれる青写真拡張機能を実装するサーバーを発見します。この拡張により、アリスは特定の会議の簡単な説明を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 Serverの間のoptionsRequest/optionsResponseメッセージ交換を示しています。
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>
</ccmpRequest>
</ccmp:ccmpRequest>
2. optionsResponse (the server returns the list of its conference control capabilities)
2. optionsResponse（サーバーは、会議制御機能のリストを返します）
<?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>
Figure 26: Alice Asks for the Server Control Capabilities
図26：アリスはサーバー制御機能を求めています
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">
<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:sequence>
</xs:complexType>
</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 参加モダリティ（全員が参加を許可されている場合、boolean <public>要素は「真」に設定されています）
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.
彼女が参加している会議に関連する会議の概要を取得するために、アリスはCCMPサーバーに「confSummaryRequest」<extensionName>で拡張レクエストを送信し、下の図に描かれているように、confObjIDリクエストパラメーターで会議xcon-uriを指定します。。
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>
2. extendedResponse (the server provides Alice with a brief description of the desired conference)
2. ExtendEdendResponse（サーバーはアリスに目的の会議の簡単な説明を提供します）
<?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：アリスは「conpsummaryrequest」拡張機能を活用しています
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.
会議クライアントがリクエストに特定の会議サーバーを使用するように事前に構成されていない場合、クライアントは最初に会議サーバーがリクエストを送信する前に発見しなければなりません (MUST)。発見プロセスの結果は、会議をサポートするサーバーのアドレスです。このドキュメントでは、結果は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を使用することが推奨されます (RECOMMENDED)。会議向けの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
)
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は次の4つのプロトコルの1つであり、XCONフレームワーク内で正式に識別されています。
Conference Control Protocol:
会議制御プロトコル：
mediates between conference and media control client (conferencing client) and conference server. This document describes such a protocol.
ConferenceとMedia Controlクライアント（会議クライアント）とConference Serverの間で仲介します。このドキュメントでは、そのようなプロトコルについて説明しています。
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]を、以下に説明するように、会議データの変更の通知にクライアントが使用しなければなりません (MUST)。
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].
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を提供します。これは、eコマースの一般的な実装メカニズムです。これは、会議クライアントがグラフィカルなHTMLユーザーインターフェイスを提供し、CCMPをカンファレンスサーバーへのバックエンドインターフェイスとして使用するWebサーバーであるシナリオでうまく機能します。このモデルは、SIPイベント通知モデルと共存できます。NATSの背後にあるPCベースのクライアントは、SIPイベントURIを提供できますが、バックエンドでCCMPを使用するWebベースのクライアントは、おそらくHTTPコールバックアプローチがはるかに簡単になるでしょう。このアプローチの詳細は、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.
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リクエストの本文で送られます。会議クライアントには、リクエストにホストヘッダーを含めなければなりません (MUST)。
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のContent-TypeおよびAcceptヘッダーフィールドで指定しなければなりません (MUST)。会議サーバーが適切なContent-TypeおよびAcceptヘッダーフィールドを受信しなかった場合、会議サーバーは要求を失敗させ、406 (Not Acceptable)応答を返すべきです (SHOULD)。CCMP応答は、Content-Lengthヘッダーを含めるべきです (SHOULD)。
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リクエストで予想ヘッダーまたはレンジヘッダーを使用してはなりません (MUST NOT)。会議サーバーは、これらのHTTP機能のいずれかが使用されている場合、501（実装されていない）エラーを返す場合があります (MAY)。IF-*（条件付き）ヘッダーを含む会議サーバーが会議クライアントからリクエストを受信する場合、会議サーバーは412（前提条件に失敗した）応答を返すべきです (SHOULD)。
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で必須 (REQUIRED) とされる唯一のメソッドです。会議サーバーがGETまたはHEADのサポートを選択する場合、GETを行っているアプリケーションの種類を考慮すべきです (SHOULD)。会議クライアントはPOSTメソッドのみを使用するため、GETまたはHEADは、通常のコンテキストの外で見つかったURL（たとえば、誰かがプロトコルトレースやログファイルでURLを見つけ、それをブラウザーに入力した場合）であるか、誰かがシステムをテストまたはデバッグしているかのいずれかでなければなりません (MUST)。会議サーバーは、そのURLが会議サーバーに対応しており、CCMPのPOST要求にのみ応答することを示す情報をCCMP応答で提供することもできますし、代わりに、405 (Method Not Allowed)のような非常に汎用的なHTTPエラーメッセージを返すことで、情報の漏えいを避けようとすることもできます。
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仲介者による会議情報のキャッシュを無効にするように設定すべきです (SHOULD)。それ以外の場合、古い情報や情報の不正な開示のリスクがあります。HTTPステータスコードは、すべてのCCMP応答とエラーメッセージの2xxシリーズ応答を示さなければなりません (MUST)。
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要求をリダイレクトしてもよいです (MAY)。会議サーバーは、3xx応答にCCMP応答を含めてはなりません (MUST NOT)。会議クライアントは、サーバーが3xx応答で提供するLocationヘッダーを使用してリダイレクトを処理しなければなりません (MUST)。リダイレクトする際、会議クライアントは、Retry-Afterヘッダーで示される遅延を守らなければなりません (MUST)。会議クライアントは、リダイレクトに従う前に、リダイレクト応答を返したサーバーを認証しなければなりません (MUST)。会議クライアントは、リダイレクトで示された会議サーバーを認証すべきです (SHOULD)。
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.
会議サーバーは、永続的な接続をサポートし、パイプラインを要求すべきです (SHOULD)。パイプラインがサポートされていない場合、会議サーバーは永続的な接続を許可してはなりません (MUST NOT)。会議サーバーは、接続を閉じることにより、応答の終了をサポートしなければなりません (MUST)。
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]上のトランスポートを実装しなければなりません (MUST)。TLSは、会議クライアントと会議サーバーの間でメッセージの完全性と機密性を提供します。会議クライアントは、HTTPS [RFC2818]で説明されているサーバー認証方式を実装しなければなりません (MUST)。デバイスは、会議サーバーの検出中に取得したURIを使用してサーバーを認証します。この認証方式の詳細は、HTTPS [RFC2818]のセクション3.1に記載されています。TLSを使用している場合、サーバー認証に失敗したときは、会議クライアントは要求を失敗させるべきです (SHOULD)。
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. クライアントは、適切な会議サーバーを決定しなければなりません (MUST)。会議サーバーの発見については、セクション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. クライアントは、適切な会議サーバーに接続しなければなりません (MUST)。このセキュリティの考慮に対処するためのメカニズムは、セクション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. プロトコルは、機密性と整合性メカニズムをサポートしなければなりません (MUST)。セクション9で説明したように、CCMPの実装は、TLS [RFC2818]を介してHTTP輸送を実装しなければなりません (MUST)。
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. 特定の機能を呼び出すために会議システム上で操作を実行する権限に関連するセキュリティ上の問題があります。会議サーバーは、認可されたエンティティのみが会議データを操作できるようにすべきです (SHOULD)。このセキュリティ上の考慮事項に対処するためのメカニズムはセクション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. 会議におけるユーザーの識別情報のプライバシーとセキュリティは保証されなければなりません (MUST)。識別情報のセキュリティとプライバシーを確保するためのメカニズムについては、セクション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）攻撃に関連しています。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サーバーから有効な応答を受信することを保証するために、DNSセキュリティ（DNSSEC）の使用が推奨されます (RECOMMENDED)。
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
CCMPトランザクションがTLS [RFC5246]を使用して実行される場合、会議サーバーは、その識別子を件名として含む証明書を提示することにより、ドメイン名またはIPアドレスとしてのIDをクライアントに認証できます（すなわち、。それぞれiPaddressまたはdnsname）。CCMPの実装は、クライアントができるようにTLSを介して取引できなければなりません (MUST)
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]の手順に従って証明書を検証できなければならない (MUST)ことに注意してください。特に、証明書の検証パスは、その信頼アンカーが会議サーバー証明書自体であっても、クライアントの信頼アンカーの1つで終了する必要があります。クライアントが、適切な会議サーバーの予想されるIDまたは資格情報に関する外部情報を持っている場合、上記の認証チェックは省略できます (MAY)。
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.
多くのポリシー認可の決定は、ユーザーの身元、またはユーザーが持つ可能性のある役割に基づいています。会議サーバーは、ユーザーの身元を検証するために、ユーザー認証のメカニズムを実装しなければなりません (MUST)。ユーザーがシステムに対して自身の身元を認証する方法はいくつかあります。コールシグナリングプロトコルのいずれかを使用して会議に参加するユーザーの場合、その特定のプロトコルのユーザー認証メカニズムを使用できます。たとえば、SIPシグナリングを使用して会議に参加するユーザーの場合、[RFC3261]で定義されているユーザー認証を使用しなければなりません (MUST)。CCMPを使用して会議に参加するユーザーの場合、CCMP要求メッセージには、認証に使用できるユーザー名とパスワードを含むsubjectフィールドがあります。CCMPメッセージはTLS上で運ばれることが推奨されている (RECOMMENDED)ため、この情報は安全に送信できます。
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インターフェイスの認可を他の認可メカニズムと関連付けることが推奨されます (RECOMMENDED)。たとえば、PINで参加し、CCMPを使用して会議を制御する公衆交換電話網（PSTN）のユーザーなどです。会議サーバーが認可されたユーザーの身元を提示する際、システムがその身元をどのように証明または検証したかに関する情報を提供してもよいです (MAY)。会議サーバーは、完全に未認証のユーザーをシステムに入れることもできます。この情報も、関係者に通知されるべきです (SHOULD)。
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）を割り当てなければならず (MUST)、そのXCON-USERIDを、認証と認可に使用されたシグナリング固有のユーザー識別子に関連付けるべきです (SHOULD)。このXCON-USERIDは、会議通知インターフェイスを通じて特定のユーザーに提供でき、CCMPを使用して会議システムと対話するユーザーには（つまり、適切なCCMP応答メッセージで）提供しなければなりません (MUST)。各ユーザーのXCON-USERID/
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は、会議オブジェクトに対するユーザーによるその後のあらゆる操作に必須であり (REQUIRED)、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）の範囲外であることに注意してください。ただし、ポリシー管理フレームワークの指定は、特にロールベースのアクセス制御（RBAC）アプローチに関して、XCONアーキテクチャ全体で実現できます。RBACでは、次の要素が識別されます。（i）ユーザー。（ii）役割;（iii）オブジェクト;（iv）操作;（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モデルのユーザーは、カンファレンスオブジェクトの<ユーザー>要素に直接関係しています。<ユーザー>要素は、会議システムの特定のユーザーを表す<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.
各<ユーザー>要素には、XCON-USERIDおよびA <ロール>要素を含む「エンティティ」属性が含まれます。したがって、[XCON-USERIDで表される]認定ユーザー（XCON-USERIDで表される）は、<ロール>要素に関連付けられます。
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]に記載されています。XCON-USERIDの形式でのIDのセキュリティは、TLSを使用してCCMPで提供されます。
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のプライバシーを確保するためのメカニズムをサポートすべきです (SHOULD)。会議クライアントは、XCONデータモデル[RFC6501]で定義されている<Proves-Anonymity>要素の操作により、目的のレベルのプライバシーを示します。<sultion-anonymity>要素は、ユーザーが自分の身元を明らかにする程度を制御します。以下は、クライアントがリクエストに含める<sultion-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).
「Hidden」：他の参加者が、会議に追加の参加者（つまり、リクエストを発行しているユーザー）があることを認識していないことを保証します。これは、会議で特別な役割で許可されているユーザーの場合（例えば、コールセンター環境の監督者）に使用できます。
"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.
クライアントがプライバシーを希望する場合、会議クライアントは、「update」または「create」または<userininfo>パラメーターの<操作>パラメーターを含むccmp confRequestメッセージの<confInfo>パラメーターに<sulting-anonymity>要素を含めるべきです (SHOULD)。「update」または「create」の<操作>パラメーターを備えたccmp userRequestメッセージ。<sultion-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攻撃の可能性を最小限に抑えるため、会議システムは、会議に参加するすべてのクライアントに対してユーザー認証と認可を要求することが推奨されます (RECOMMENDED)。これは、セクション10.2で説明されているメカニズムを使用することで、また、特定のシグナリング（たとえばSession Initiation Protocol Secure (SIPS)）やメディアプロトコル（たとえばSecure Realtime Transport Protocol (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-20041028]を示します。これは、「application/ccmp+xml」形式の正式な定義として提示されます。新しいXMLネームスペース、新しいXMLスキーマ、およびこのスキーマのMIMEタイプは、セクション12で説明されているようにIANAに登録されています。資料。ドキュメントの読みやすさにマイナスの影響を与えることなく、RFC形式のライン長制限に準拠するために、セマにホワイトスペースが含まれています。適合プロセッサは、リーディングとトレーリングの白いスペースを削除する必要があります。
<?xml version="1.0" encoding="utf-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:tns="urn:ietf:params:xml:ns:xcon-ccmp"
xmlns:dm="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="urn:ietf:params:xml:ns:xcon-conference-info"
schemaLocation="DataModel.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info"
schemaLocation="rfc4575.xsd"/>
<xs:element name="ccmpRequest" type="ccmp-request-type" />
<xs:element name="ccmpResponse" type="ccmp-response-type" />
<!-- CCMP request definition -->
<xs:complexType name="ccmp-request-type">
<xs:sequence>
<xs:element name="ccmpRequest"
type="ccmp-request-message-type" />
</xs:sequence>
</xs:complexType>
<!-- ccmp-request-message-type -->
<xs:complexType abstract="true"
name="ccmp-request-message-type">
<xs:sequence>
<xs:element name="subject" type="subject-type"
minOccurs="0" maxOccurs="1" />
<xs:element name="confUserID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0" maxOccurs="1" />
<xs:element name="conference-password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP response definition -->
<xs:complexType name="ccmp-response-type">
<xs:sequence>
<xs:element name="ccmpResponse"
type="ccmp-response-message-type" />
</xs:sequence>
</xs:complexType>
<!-- ccmp-response-message-type -->
<xs:complexType abstract="true" name="ccmp-response-message-type">
<xs:sequence>
<xs:element name="confUserID" type="xs:string"
minOccurs="1" maxOccurs="1" />
<xs:element name="confObjID" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="operation" type="operationType"
minOccurs="0"
maxOccurs="1" />
<xs:element name="response-code"
type="response-codeType"
minOccurs="1" maxOccurs="1" />
<xs:element name="response-string" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="version" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP REQUESTS -->
<!-- blueprintsRequest -->
<xs:complexType name="ccmp-blueprints-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsRequestType -->
<xs:element name="blueprintsRequest" type="blueprintsRequestType"/>
<xs:complexType name="blueprintsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintRequest -->
<xs:complexType name="ccmp-blueprint-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="blueprintRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintRequestType -->
<xs:element name="blueprintRequest" type="blueprintRequestType" />
<xs:complexType name="blueprintRequestType">
<xs:sequence>
<xs:element name="blueprintInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsRequest -->
<xs:complexType name="ccmp-confs-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confsRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsRequestType -->
<xs:element name="confsRequest" type="confsRequestType" />
<xs:complexType name="confsRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confRequest -->
<xs:complexType name="ccmp-conf-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="confRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confRequestType -->
<xs:element name="confRequest" type="confRequestType" />
<xs:complexType name="confRequestType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersRequest -->
<xs:complexType name="ccmp-users-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="usersRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersRequestType -->
<xs:element name="usersRequest" type="usersRequestType" />
<xs:complexType name="usersRequestType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userRequest -->
<xs:complexType name="ccmp-user-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="userRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userRequestType -->
<xs:element name="userRequest" type="userRequestType" />
<xs:complexType name="userRequestType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValRequest -->
<xs:complexType name="ccmp-sidebarsByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValRequestType -->
<xs:element name="sidebarsByValRequest"
type="sidebarsByValRequestType" />
<xs:complexType name="sidebarsByValRequestType">
<xs:sequence>
<xs:element name="xpathFilter"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefRequest -->
<xs:complexType name="ccmp-sidebarsByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefRequestType -->
<xs:element name="sidebarsByRefRequest"
type="sidebarsByRefRequestType" />
<xs:complexType name="sidebarsByRefRequestType">
<xs:sequence>
<xs:element name="xpathFilter" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValRequest -->
<xs:complexType name="ccmp-sidebarByVal-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByValRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValRequestType -->
<xs:element name="sidebarByValRequest"
type="sidebarByValRequestType"/>
<xs:complexType name="sidebarByValRequestType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefRequest -->
<xs:complexType name="ccmp-sidebarByRef-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefRequest" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefRequestType -->
<xs:element name="sidebarByRefRequest"
type="sidebarByRefRequestType" />
<xs:complexType name="sidebarByRefRequestType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedRequest -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedRequestType -->
<xs:element name="extendedRequest" type="extendedRequestType"/>
<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsRequest -->
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- CCMP RESPONSES -->
<!-- blueprintsResponse -->
<xs:complexType name="ccmp-blueprints-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintsResponseType -->
<xs:element name="blueprintsResponse" type="blueprintsResponseType"/>
<xs:complexType name="blueprintsResponseType">
<xs:sequence>
<xs:element name="blueprintsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- blueprintResponse -->
<xs:complexType name="ccmp-blueprint-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="blueprintResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- blueprintResponseType -->
<xs:element name="blueprintResponse" type="blueprintResponseType"/>
<xs:complexType name="blueprintResponseType">
<xs:sequence>
<xs:element name="blueprintInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confsResponse -->
<xs:complexType name="ccmp-confs-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confsResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confsResponseType -->
<xs:element name="confsResponse" type="confsResponseType" />
<xs:complexType name="confsResponseType">
<xs:sequence>
<xs:element name="confsInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- confResponse -->
<xs:complexType name="ccmp-conf-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="confResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- confResponseType -->
<xs:element name="confResponse" type="confResponseType" />
<xs:complexType name="confResponseType">
<xs:sequence>
<xs:element name="confInfo" type="info:conference-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- usersResponse -->
<xs:complexType name="ccmp-users-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="usersResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- usersResponseType -->
<xs:element name="usersResponse" type="usersResponseType" />
<xs:complexType name="usersResponseType">
<xs:sequence>
<xs:element name="usersInfo" type="info:users-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- userResponse -->
<xs:complexType name="ccmp-user-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="userResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- userResponseType -->
<xs:element name="userResponse" type="userResponseType" />
<xs:complexType name="userResponseType">
<xs:sequence>
<xs:element name="userInfo" type="info:user-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByValResponse -->
<xs:complexType name="ccmp-sidebarsByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByValResponseType -->
<xs:element name="sidebarsByValResponse"
type="sidebarsByValResponseType" />
<xs:complexType name="sidebarsByValResponseType">
<xs:sequence>
<xs:element name="sidebarsByValInfo"
type="info:sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarsByRefResponse -->
<xs:complexType name="ccmp-sidebarsByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarsByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarsByRefResponseType -->
<xs:element name="sidebarsByRefResponse"
type="sidebarsByRefResponseType" />
<xs:complexType name="sidebarsByRefResponseType">
<xs:sequence>
<xs:element name="sidebarsByRefInfo" type="info:uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByValResponse -->
<xs:complexType name="ccmp-sidebarByVal-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByValResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByValResponseType -->
<xs:element name="sidebarByValResponse"
type="sidebarByValResponseType" />
<xs:complexType name="sidebarByValResponseType">
<xs:sequence>
<xs:element name="sidebarByValInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- sidebarByRefResponse -->
<xs:complexType name="ccmp-sidebarByRef-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="sidebarByRefResponse" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- sidebarByRefResponseType -->
<xs:element name="sidebarByRefResponse"
type="sidebarByRefResponseType" />
<xs:complexType name="sidebarByRefResponseType">
<xs:sequence>
<xs:element name="sidebarByRefInfo"
type="info:conference-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extendedResponse -->
<xs:complexType name="ccmp-extended-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="extendedResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- extendedResponseType -->
<xs:element name="extendedResponse" type="extendedResponseType"/>
<xs:complexType name="extendedResponseType">
<xs:sequence>
<xs:element name="extensionName"
type="xs:string" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- optionsResponse -->
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- optionsResponseType -->
<xs:element name="optionsResponse"
type="optionsResponseType" />
<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CCMP ELEMENT TYPES -->
<!-- response-codeType-->
<xs:simpleType name="response-codeType">
<xs:restriction base="xs:positiveInteger">
<xs:pattern value="[0-9][0-9][0-9]" />
</xs:restriction>
</xs:simpleType>
<!-- operationType -->
<xs:simpleType name="operationType">
<xs:restriction base="xs:token">
<xs:enumeration value="retrieve"/>
<xs:enumeration value="create"/>
<xs:enumeration value="update"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<!-- subject-type -->
<xs:complexType name="subject-type">
<xs:sequence>
<xs:element name="username" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:element name="password" type="xs:string"
minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- options-type -->
<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list"
type="standard-message-list-type"
minOccurs="1"/>
<xs:element name="extended-message-list"
type="extended-message-list-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-list-type -->
<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message"
type="standard-message-type"
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-type -->
<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name"
type="standard-message-name-type"
minOccurs="1"/>
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- standard-message-name-type -->
<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>
<!-- operations-type -->
<xs:complexType name="operations-type">
<xs:sequence>
<xs:element name="operation" type="operationType"
minOccurs="1" maxOccurs="4"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extended-message-list-type -->
<xs:complexType name="extended-message-list-type">
<xs:sequence>
<xs:element name="extended-message"
type="extended-message-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- extended-message-type -->
<xs:complexType name="extended-message-type">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="operations"
type="operations-type"
minOccurs="0"/>
<xs:element name="schema-def" type="xs:string" />
<xs:element name="description"
type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
Figure 30: CCMP XML Schema
図30：CCMP XMLスキーマ
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
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者の連絡先：IETF XCONワーキンググループ（xcon@ietf.org）、Mary Barnes（mary.ietf.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
This section registers an XML schema per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
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）、Mary Barnes（mary.ietf.barnes@gmail.com）。
Schema: The XML for this schema can be found as the entirety of Section 11 of this document.
スキーマ：このスキーマの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
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]で指定されている「application/xml」のCharSetパラメーターと同じCharSet、セクション3.2。
Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC3023], Section 3.2.
エンコーディングの考慮事項：[RFC3023]で指定されている「アプリケーション/XML」のエンコーディングに関する考慮事項と同じ、セクション3.2。
Security considerations: This content type is designed to carry protocol data related to conference control. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 10 are required to protect the data. This media type does not contain executable content.
セキュリティ上の考慮事項：このコンテンツタイプは、会議制御に関連するプロトコルデータを運ぶように設計されています。一部のデータはプライベートと見なすことができます。このメディアタイプは保護を提供していないため、データを保護するためにセクション10に記載されているような他のメカニズムが必要です。このメディアタイプには、実行可能なコンテンツが含まれていません。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Published specification: RFC 6503.
公開された仕様：RFC 6503。
Applications that use this media type: Centralized Conferencing control clients and servers.
このメディアタイプを使用するアプリケーション：中央会議を制御するクライアントとサーバー。
Additional Information: Magic Number(s): (none)
File extension(s): .ccmp
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: Mary
Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller: The IETF
著者/変更コントローラー：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
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の定義：RFC 6503。
Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the CCMP message types for CCMP is Specification Required.
登録/割り当て手順：[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）、Mary Barnes（mary.ietf.barnes@gmail.com）。
This specification establishes the Message sub-registry under http://www.iana.org/assignments/ccmp-messages. The initial Message table is populated using the CCMP messages described in Section 4.1 and defined in the XML schema in Section 11.
この仕様は、http://www.iana.org/assignments/ccmp-messagesに基づいてメッセージサブレジストリを確立します。最初のメッセージテーブルは、セクション4.1で説明され、セクション11のXMLスキーマで定義されているCCMPメッセージを使用して入力されます。
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.
optionsResponse特定の会議サーバーによってサポートされているCCMPメッセージ[RFC6503]のリストを返します。
blueprintsRequest Used by a conferencing client [RFC6503] to query a conference server for its capabilities, in terms of available conference blueprints.
会議クライアント[RFC6503]が使用できる会議サーバーをクエリするために、利用可能な会議の青写真の観点から、会議サーバーを照会するために使用されるblueprintsRequest。
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.
特定の青写真に関連付けられた会議オブジェクト[RFC6503]を取得するために送信されたblueprintRequest。
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.
会議クライアント[RFC6503]が使用しているconfsRequestは、スケジュール/アクティブな会議のために会議サーバーを照会します。
confsResponse Returns the list of the currently [RFC6503] activated/scheduled conferences at the server.
conpsResponseは、サーバーで現在[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.
fensponseは、会議オブジェクト全体で操作[RFC6503]の結果を示します。
userRequest Used to request an operation on the [RFC6503] <user> element in the conference object.
Conferenceオブジェクトの[RFC6503] <ユーザー>要素の操作を要求するために使用されるuserRequest。
userResponse Indicates the result of the requested [RFC6503] operation on the <user> element in the conference object.
userResponseは、会議オブジェクトの<ユーザー>要素で要求された[RFC6503]操作の結果を示します。
usersRequest Used to manipulate the <users> element [RFC6503] in the conference object, including parameters such as the <allowed-users-list>, <join-handling>, etc.
<Aldaup-users-list>、<joinhandling>などのパラメーターを含む、会議オブジェクトの<ユーザー>要素[rfc6503]を操作するために使用されるusersRequest。
usersResponse Indicates the result of the request [RFC6503] to manipulate the <users> element in the conference object.
usersResponseは、会議オブジェクトの<ユーザー>要素を操作する要求[RFC6503]の結果を示します。
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ターゲット会議オブジェクト内のサイドバーバイバル[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ターゲット会議オブジェクトに関連するSideBar-by-Ref [RFC6503]会議のリストを返します。
sidebarByValRequest Used to request an operation on a [RFC6503] sidebar-by-val conference.
sidebarByValRequest [RFC6503] SideBar-by-Valの会議で操作を要求するために使用されました。
sidebarByValResponse Indicates the result of the request to [RFC6503] manipulate a sidebar-by-val conference.
sidebarByValResponse [RFC6503]への要求の結果が、サイドバーごとの会議を操作します。
sidebarByRefRequest Used to request an operation on a [RFC6503] sideber-by-ref conference.
[RFC6503] Sideber by-Ref会議で操作を要求するために使用されるsidebarByRefRequest。
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の定義：RFC 6503。
Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the Response codes for CCMP shall be Specification Required.
登録/割り当て手順：[RFC5226]で概説されているポリシーに従って、CCMPの応答コードの新しい値を割り当てるためのIANAポリシーが必要な仕様です。
Registrant Contact: IETF XCON working group (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者の連絡先：IETF XCONワーキンググループ（xcon@ietf.org）、Mary Barnes（mary.ietf.barnes@gmail.com）。
This specification establishes the Response-code sub-registry under http://www.iana.org/assignments/ccmp-parameters. The initial Response-code table is populated using the Response codes defined in Section 5.4 as follows:
この仕様は、http://www.iana.org/assignments/ccmp-parametersに基づいて応答コードサブレジストリを確立します。初期応答コードテーブルは、次のようにセクション5.4で定義されている応答コードを使用して入力されます。
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禁止特定の操作は、ターゲット会議オブジェクトに有効ではありません。
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競合要求された操作は、サーバーによって正常に完了することはできません。たとえば、オブジェクトのクライアントバージョンが時代遅れであり、要求された変更がサーバーに保存されているオブジェクトの最新の状態と衝突するため、オブジェクトの変更は適用できません。
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.
423 Conference Password A request to access/manipulate [RFC6503] Required a password-protected conference object did not contain a <conference-password> parameter.
424 Authentication The server wants to authenticate [RFC6503] Required the request through the <subject> parameter but the parameter is not provided in the request.
425 Forbidden Delete The conferencing system cannot [RFC6503] Parent delete the specific conference object because it is a parent for another conference object.
426 Forbidden Change The target conference object [RFC6503] Protected cannot be changed (e.g., due to policies, roles or privileges).
427 Invalid Domain Name The domain name in an [RFC6503] AUTO_GENERATE_X instance in the conference object is not within the conference server's domain of responsibility.
427無効なドメイン名[RFC6503]のドメイン名は、会議オブジェクトのAUTO_GENERATE_Xインスタンスのインスタンスは、会議サーバーの責任ドメイン内にありません。
500 Server Internal The conference server experienced [RFC6503] Error some sort of internal error.
501 Not Implemented The specific operation is not [RFC6503] implemented on the conferencing system.
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.
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 Reisner、Tony Lindstrom、Seephen Kent（Secdir Review）によって提供されたフィードバックに感謝しています。ブライアン・カーペンター（Genart Review）、Mykyta Yevstifeev（IANAの考慮事項）。この文書への彼女の貴重な貢献について、ロベルタ・プレスタに感謝します。ロベルタは、ナポリ大学で修士論文の準備のために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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee、「HyperText Transfer Protocol-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., Luotonen, A., and L. Stewart、「HTTP認証：基本およびダイジェストアクセス認証」、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla, E.、「TLS上のHTTP」、RFC 2818、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., and 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. and E. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265] Barth, A.、「HTTP状態管理メカニズム」、RFC 6265、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., and J. Urpalainen、「集中会議のための会議情報データモデル（XCON）」、RFC 6501、2012年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., and M. Maloney、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortiumの推奨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. and A. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-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., and D. Kohn、「XML Media Types」、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., and E. Schooler、「SIP：SESSION INTIANIATION Protocol」、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. and A. Newton、「SRV RRSおよびThe Dynamic Deligation Discovery Service（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., and 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., and 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. and 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., and J. Urpalainen、「集中会議（XCON）の会議イベントパッケージデータ形式拡張」、RFC 6502、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] Nielsen, H., Mendelsohn, N., Moreau, J., Gudgin, M., Hadley, M., Lafon, Y., and A. Karmarkar, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
[W3C.REC-soap12-part2-20070427] Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N., Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
[W3C.REC-SOAP12-PART2-20070427] Moreau、J.、Gudgin、M.、Karmarkar、A.、Mendelsohn、N.、Hadley、M.、Lafon、Y.、およびH. Nielsen、SOAPバージョン1.2パート2：付属品（第2版）」、ワールドワイドウェブコンソーシアムの推奨REC-SOAP12-PART2-20070427、2007年4月、<http://www.w3.org/TR/2007/REC-soap12-part2-20070427>。
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.
このセクションでは、CCMPリクエスト/応答のトランスポートとしてのHTTPの選択に関する背景を説明します。HTTPに加えて、オブジェクトの操作は、少なくとも2つの異なる方法、つまりリモートプロシージャコールとして実装できます - 付録A.1で説明したSOAPを使用し、Restful Architecture Appendix A.2に従ってリソースを定義することにより。
In both the SOAP and RESTFUL approaches, servers will have to recreate their internal state representation of the object with each update request, checking parameters and triggering function invocations. In the SOAP approach, it would be possible to describe a separate operation for each atomic element, but that would greatly increase the complexity of the protocol. A coarser-grained approach to CCMP does require that the server process XML elements in updates that have not changed and that there can be multiple changes in one update. For CCMP, the resource (REST) model might appear more attractive, since the conference operations fit the CRUD approach.
SOAPとRESTFULアプローチの両方で、サーバーは、各更新リクエスト、パラメーターをチェックし、関数の呼び出しをトリガーするたびに、オブジェクトの内部状態表現を再現する必要があります。SOAPアプローチでは、各原子要素の個別の操作を記述することが可能ですが、それはプロトコルの複雑さを大幅に増加させるでしょう。CCMPへの粗い粒度のアプローチでは、変更されていない更新でサーバーを処理し、1つの更新に複数の変更がある可能性があることが必要です。CCMPの場合、会議操作はCRUDアプローチに適合するため、リソース（REST）モデルがより魅力的に見える場合があります。
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は、追加のオーバーヘッドをもたらすと考えられていました。CCMPには、サーバーとクライアントの両方でデータを維持するために、より複雑な要求/応答プロトコルが必要なため、安らかなアプローチを適用するのは非常に厄介です。これは、基本的な要求/応答モデルにそれほどエレガントにマッピングされません。これにより、応答は通常、クライアントデータとサーバーデータ間の同期を維持するための追加データを提供するのではなく、リクエストが成功したかどうかを示します。さらに、CCMPクライアントは通知でデータを受信することもできます。一部の会議クライアントが使用する通知方法またはプロトコルはCCMPとは独立している可能性がありますが、サーバー内の同じデータがCCMPと通知の両方に使用されます。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動詞」を使用します（つまり、各リクエスト/応答ペアの単一のトランザクションタイプ）。これにより、HTTPメッセージからのCCMPメッセージを切り離すことができます。同様に、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（Simple Object Access Protocol [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動詞を使用します。安定したアプローチでは、各オブジェクトに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.
カンファレンスオブジェクトは、URISによって識別されたリソースとしてモデル化することもできます。基本的なCRUD操作は、オブジェクトの作成のためにhttpメソッドポスト/putにマッピングされ、オブジェクトの読み取りの取得、パッチ/post/put for chandingオブジェクト、削除のために削除することもできます。会議などの多くのオブジェクトには、すでに自然なウリがあります。
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 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]に従うことができます。CCMPは、リソースURI、リソース形式、各URIでサポートされているメソッド、および特定の方法が特定のURIで呼び出されたときに返される必要があるステータスコードを指定することにより、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.
取得：HTTP GETをXCON-URISで使用できるため、クライアントはXMLデータモデルドキュメントの形で会議オブジェクトに関するデータを取得できます。
Create: HTTP PUT could be used to create a new object as identified by the XCON-URI or XCON-USERID.
create：http putを使用して、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投稿のいずれかを使用して、XCON-URIによって識別される会議オブジェクトを変更できます。
Delete: HTTP DELETE could be used to delete conference objects and parameters within conference objects identified by the XCON-URI.
削除：HTTP削除を使用して、XCON-URIによって識別された会議オブジェクト内の会議オブジェクトとパラメーターを削除できます。
Authors' Addresses
著者のアドレス
Mary Barnes Polycom TX USA
メアリーバーンズポリコムテキサスUSA
EMail: mary.ietf.barnes@gmail.com
Chris Boulton NS-Technologies
クリス・ボールトンNS-Technologies
EMail: chris@ns-technologies.com
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
サイモンピエトロロマーノナポリ大学クラウディオ21ナポリ80125イタリア
EMail: spromano@unina.it
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027
EMail: hgs+xcon@cs.columbia.edu