[要約] RFC 6503は、中央集権型の会議操作プロトコルに関するものであり、会議の制御と操作を効率化することを目的としています。要約： - RFC 6503は中央集権型の会議操作プロトコルに関するものです。 - 目的は会議の制御と操作を効率化することです。
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)".
CCMPは、XCONフレームワーク内のクライアントサーバーモデルを実装し、それぞれクライアントと会議サーバーをクライアントとサーバーとして機能させます。CCMPは、[RFC6501]で定義されたドメイン固有のXMLエンコードデータオブジェクトを含む要求と応答を転送するプロトコルとしてHTTP [RFC2616]を使用します。
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" 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を使用して会議システムに関連するクライアントに対処および管理するために必要な識別子の詳細を説明します。
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に要約されているように、プロトコルモデルの各操作は原子であり、全体として成功または失敗します。会議サーバーは、特定の会議クライアントによって呼び出された操作が、同じ会議のオブジェクトでの別のクライアントの操作の前に完了するという点で、操作が原子的であることを確認する必要があります。このデータロック機能の詳細は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応答メッセージには、<バージョン>パラメーターを含める必要があります。クライアントがカンファレンスオブジェクトの変更を含む更新メッセージをサーバーに送信すると、変更がすべて正常に適用された場合、サーバーはバージョン番号を含む<応答コード>の「200」で応答を返す必要があります。変更されたオブジェクトの。このアプローチを使用すると、「x 1」のバージョン番号がある<応答コード>を備えた応答を受信する会議オブジェクトのバージョン「x」に取り組んでいます。操作が最も最新でした。ただし、応答に少なくとも「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.
「バージョン」パラメーターはリクエストに対してオプションです。サーバーが必要としないため、必要な変更を競合なしにターゲット会議オブジェクトに適用できる限り、サーバーはクライアントが最新の保存をしているかどうかを気にしません - 情報のビュー。さらに、データの整合性を確保するために、会議サーバーは最初にすべてのパラメーターをチェックし、カンファレンスオブジェクトの内部表現を変更します。たとえば、会議の<persument>を変更することは望ましくありませんが、<Service-uris>の1つで無効な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値は、属性または要素の値部分内にある必要があります（例：<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の悪い要求」の<応答コード>を送信する必要があります。 auto_generate_xがURIのユーザー部分（つまり、xcon-useridsまたはxcon-urisの場合）にのみ表示される場合、サーバーはドメイン名がサーバーの責任ドメイン内にあるものであることを確認する必要があります。ドメイン名がサーバーの責任ドメイン内にない場合、サーバーは「427無効なドメイン名」の<応答コード>を送信する必要があります。サーバーは、特定のワイルドカードフィールド（auto_generate_1など）の各インスタンスを同じ識別子に置き換える必要があります。識別子は、リクエストで受信したのと同じXMLドキュメント内のauto_generate_xの各インスタンスに対して一意でなければなりません。たとえば、auto_generate_1を置き換える値は、auto_generate_2を置き換える値と同じである必要があります。 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」の<応答コード>を保留中のリクエストに返す必要があります。さらに、状況を軽減するために、クライアントは無期限に応答を待ってはならず、クライアントが有効期限が切れると、クライアントが接続を閉じる必要があるようにタイマーを実装する必要があります。このタイマーのデフォルト値として30秒をお勧めします。60秒は、合理的な上部範囲と見なされます。応答メッセージが失われ、リクエストが成功した場合に注意してください（たとえば、ユーザーが会議に追加されました）。しかし、クライアントは気づかず、接続を閉じます。ただし、セクション4.2で説明したように、会議オブジェクトにはバージョン化メカニズムがあります。したがって、クライアントが保存した会議オブジェクトが最新の状態に保たれるメカニズムがあります。
CCMP messages have a MIME-type of "application/ccmp+xml", which appears inside the Content-Type and Accept header fields of HTTP requests and responses. The XML documents in the CCMP messages MUST be encoded in UTF-8. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. The 'charset' parameter MUST be included with the XML document. Section 9 provides the complete requirements for an HTTP implementation to support CCMP.
CCMPメッセージには、コンテンツタイプ内に表示され、HTTPリクエストと応答のヘッダーフィールドを受け入れる「アプリケーション/CCMP XML」のMIMEタイプがあります。CCMPメッセージのXMLドキュメントは、UTF-8でエンコードする必要があります。この仕様は、[RFC3023]に記載されている推奨事項と規則に従って、タイプの命名規則（ 'xml'接尾辞）や「charset」パラメーターの使用法を含めます。「charset」パラメーターはXMLドキュメントに含める必要があります。セクション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.
件名：会議システムに登録されているクライアントのユーザー名とパスワードを含むオプションのパラメーター。会議システムを購読する各ユーザーは、それらの資格情報を装備していると想定されており、各CCMPリクエストにそれらを同封する必要があります。これらのフィールドを使用して、CCMPリクエストを送信するユーザーが要求された操作を実行する権限を持っていることを制御できます。同じフィールドは、他の承認および認証手順にも使用できます。
confUserID: An OPTIONAL parameter containing the XCON-USERID of the client. The XCON-USERID is used to identify any conferencing client within the context of the conferencing system and it is assigned by the conference server for each conferencing client who interacts with it. The <confUserID> parameter is REQUIRED in the CCMP request and response messages with the exception of the case of a user who has no XCON-USERID and who wants to enter, via CCMP, a conference whose identifier is known. In such case, a side effect of the request is that the user is provided with an appropriate XCON-USERID. An example of the aforementioned case will be provided in Section 5.3.6.
confuserid：クライアントのxcon-useridを含むオプションのパラメーター。XCON-USERIDは、会議システムのコンテキスト内で会議クライアントを識別するために使用され、それと対話する会議クライアントごとに会議サーバーによって割り当てられます。<consuserid>パラメーターは、XCON-USERIDがないユーザーと入力を希望するユーザーのケースを除き、CCMPリクエストと応答メッセージで必要です。そのような場合、リクエストの副作用は、ユーザーに適切なXCON-USERIDが提供されることです。前述のケースの例は、セクション5.3.6で提供されます。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confobjid：ターゲット会議オブジェクトのxcon-uriを含むオプションのパラメーター。
operation: An OPTIONAL parameter refining the type of specialized request message. The <operation> parameter is REQUIRED in all requests except for the blueprintsRequest and confsRequest specialized messages.
操作：特殊な要求メッセージのタイプを改良するオプションのパラメーター。BluePrintsRequestおよびConfsRequest専門メッセージを除くすべてのリクエストで<操作>パラメーターが必要です。
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：パラメーターは、ターゲット会議オブジェクトがパスワードで保護されているすべてのリクエストに挿入する必要があることを除いてオプションです。必要に応じて、会議のパスワードがリクエストに含まれていない場合、「423」のCCMP <応答コード>を返す必要があります。
specialized request message: This is a specialization of the generic request message (e.g., blueprintsRequest), containing parameters that are dependent on the specific request sent to the server. A specialized request message MUST be included in the CCMP request message. The details for the specialized messages and associated parameters are provided in Section 5.3.
専門的な要求メッセージ：これは、サーバーに送信された特定の要求に依存するパラメーターを含む、一般的なリクエストメッセージ（例：BluePrintsRequest）の専門化です。特殊な要求メッセージをCCMPリクエストメッセージに含める必要があります。特殊なメッセージと関連するパラメーターの詳細は、セクション5.3に記載されています。
<!-- Definition of CCMP Request -->
<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応答メッセージの必要なパラメーター。
confObjID: An OPTIONAL parameter containing the XCON-URI of the target conference object.
confobjid：ターゲット会議オブジェクトのxcon-uriを含むオプションのパラメーター。
operation: An OPTIONAL parameter for CCMP response messages. This parameter is REQUIRED in all responses except for the "blueprintsResponse" and "confsResponse" specialized messages.
操作：CCMP応答メッセージのオプションパラメーター。このパラメーターは、「blueprintsResponse」および「conpsResponse」専門メッセージを除くすべての応答で必要です。
response-code: A REQUIRED parameter containing the response code associated with the request. The response code MUST be chosen from the codes listed in Section 5.4.
応答コード：リクエストに関連付けられた応答コードを含む必要なパラメーター。応答コードは、セクション5.4にリストされているコードから選択する必要があります。
response-string: An OPTIONAL reason string associated with the response. In case of an error, in particular, this string can be used to provide the client with detailed information about the error itself.
応答ストリング：応答に関連付けられたオプションの理由文字列。特にエラーの場合、この文字列を使用して、クライアントにエラー自体に関する詳細情報を提供できます。
version: An OPTIONAL parameter reflecting the current version number of the conference object referred by the confObjID. This number is contained in the 'version' attribute of the <conference-info> element related to that conference. This parameter is REQUIRED in CCMP response messages and SHOULD NOT be included in CCMP request messages.
バージョン：confobjidが紹介した会議オブジェクトの現在のバージョン番号を反映するオプションのパラメーター。この数値は、その会議に関連する<Conference-info>要素の「バージョン」属性に含まれています。このパラメーターはCCMP応答メッセージで必要であり、CCMPリクエストメッセージに含めるべきではありません。
specialized response message: This is specialization of the generic response message, containing parameters that are dependent on the specific request sent to the server (e.g., "blueprintsResponse"). A specialized response message SHOULD be included in the CCMP response message, except in an error situation where the CCMP request message did not contain a valid specialized message. In this case, the conference server MUST return a <response-code> of "400". The details for the specialized messages and associated parameters are provided in Section 5.3.
専門的な応答メッセージ：これは、サーバーに送信された特定の要求に依存するパラメーターを含む一般的な応答メッセージの専門化です（例：「BluePrintsResponse」）。CCMPリクエストメッセージに有効な専門メッセージが含まれていないエラー状況を除き、特殊な応答メッセージをCCMP応答メッセージに含める必要があります。この場合、会議サーバーは「400」の<応答コード>を返す必要があります。特殊なメッセージと関連するパラメーターの詳細は、セクション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も<操作>パラメーターを必要としないことに注意してください。エンティティは、サポートされている各リクエストメッセージの応答メッセージをサポートする必要があります。対応する応答メッセージには、同じ<操作>パラメーターを含める必要があります。一部のエントリには「n/a」というラベルが付いていることに注意してください。これは、操作がその要求タイプに対して無効であることを示しています。「n/a*」ラベルの場合、操作は特定の特権ユーザーまたはシステム管理者に許可される場合がありますが、このドキュメントに含まれる機能の一部ではありません。
+---------------+------------+------------+------------+------------+
| Operation | Retrieve | Create | Update | Delete |
| ------------- | | | | |
| Request Type | | | | |
+---------------+------------+------------+------------+------------+
| blueprints | Get list | N/A | N/A | N/A |
| Request | of | | | |
| | blueprints | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| blueprint | Get | N/A* | N/A* | N/A* |
| Request | blueprint | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confsRequest | Get list | N/A | N/A | N/A |
| | of confs | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| confRequest | Get | Create | Change | Delete |
| | conference | conference | conference | conference |
| | object | object | object | object |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| usersRequest | Get | N/A(**) | Change | N/A(**) |
| | <users> | | <users> | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| userRequest | Get | Add a | Change | Delete |
| | specified | <user> to | specified | specified |
| | <user> | a conf | <user> | <user> |
| | | (***) | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByVal | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-val> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarsByRef | Get | N/A | N/A | N/A |
| Request | <sidebars- | | | |
| | by-ref> | | | |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByValR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-val | by-val | by-val | by-val |
| ------------- | ---------- | ---------- | ---------- | ---------- |
| sidebarByRefR | Get | Create | Change | Delete |
| equest | sidebar- | sidebar- | sidebar- | sidebar- |
| | by-ref | by-ref | by-ref | by-ref |
+---------------+------------+------------+------------+------------+
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」の<応答コード>を返す必要があります。
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を反映する必要があります。BluePrintsRequestメッセージは特定の会議インスタンスをターゲットにされておらず、「取得のみの」リクエストであるため、<confobjid>および<操作>パラメーターをBluePrintsRequest/Responseメッセージに含めてはなりません。
In order to obtain a specific subset of the available blueprints, a client may specify a selection filter providing an appropriate xpath query in the OPTIONAL "xpathFilter" parameter of the request. The information in the blueprints typically represents general capabilities and characteristics. For example, to select blueprints having both audio and video stream support, a possible xpathFilter value could be: "/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']". A conference server SHOULD NOT provide any sensitive information (e.g., passwords) in the blueprints.
利用可能な青写真の特定のサブセットを取得するために、クライアントは、リクエストのオプションの「XPathFilter」パラメーターに適切なXPathクエリを提供する選択フィルターを指定できます。青写真の情報は通常、一般的な能力と特性を表します。たとえば、オーディオとビデオストリームの両方のサポートを持つ青写真を選択するには、XpathFilterの値が次の場合があります。/entry/type = 'video'] "。会議サーバーは、青写真で機密情報（パスワードなど）を提供してはなりません。
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」パラメーターを含める必要があります。
<!-- 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>パラメーターは、すべてのconpsrequest/responseメッセージに含める必要があり、リクエストを発行する会議クライアントのxcon-useridを反映する必要があります。 <confobjid>パラメーターは、conpsrequestメッセージに含めてはなりません。 ConfsRequestメッセージは、Conference Serverで利用可能な情報を収集することが唯一の目的であるため、取得のみのタイプです。したがって、<操作>パラメーターをConpsRequestメッセージに含めてはなりません。利用可能な会議の特定のサブセットを取得するために、クライアントは、リクエストのオプションの「XPathFilter」パラメーターで適切なXPathクエリを提供する選択フィルターを指定できます。たとえば、登録された会議のみを選択するには、XpathFilterの値が「/ Conference-INFO [Conference-Description/ Conference-State/ Active = 'false']」です。関連するconpsResponseメッセージには、「confsinfo」パラメーターにxcon-urisのリストを含める必要があります。ユーザーは、応答メッセージを受信すると、さらに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>および<操作>パラメーターを含める必要があります。繰り返しますが、<confuserid>パラメーターは、すべてのBlueprintrequest/Responseメッセージに含める必要があり、リクエストを発行する会議クライアントのXCON-USERIDを反映する必要があります。<confobjid>パラメーターには、青写真の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メッセージには、「取得」以外の値を持つ<操作>パラメーターを含めてはなりません。「作成」、「更新」、または「削除」の値を持つ<Operation>パラメーターは、特権ユーザー（例：Conference Server Administration Staff）の場合を除き、BluePrintre -Equestメッセージに含めてはなりません。「サブジェクト」要求パラメーターの平均によって。
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メッセージに含める必要があります。<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.
CCMPクライアントは、CONFREQUESTメッセージを使用すると、アクティブまたは登録会議に関連付けられた会議オブジェクトを操作できます。<confuserid>パラメーターは、すべてのconfrequest/responseメッセージに含め、リクエストを発行する会議クライアントのxcon-useridを反映する必要があります。confrequestおよびconfResponseメッセージには、<操作>パラメーターも含める必要があります。confResponseメッセージは、requestor a <応答コード>に戻る必要があり、それを説明する<応答ストリング>を含む場合があります。操作の種類に応じて、<confobjid>および<confinfo>パラメーターがconprequestおよび応答に含まれる場合があります。操作の各タイプについて、以下のテキストでは、<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を含める必要がありますが、<conpinfo>パラメーターはconfrequestに含まれてはなりません。アクティブな会議のクローニングは、XCONフレームワークごとのサイドバー操作の場合とセクション5.3.8で説明されている場合にのみ行われることに注意してください。
2. Creation through implicit cloning (also known as "direct creation"): the <confObjID> parameter MUST NOT be included in the request and the CCMP client can describe the desired conference to be created using the <confInfo> parameter. If no <confInfo> parameter is provided in the request, the new conference will be created as a clone of the system default blueprint.
2. 暗黙的なクローニングによる作成（「直接的な作成」とも呼ばれます）：<confobjid>パラメーターはリクエストに含める必要はなく、CCMPクライアントは<confinfo>パラメーターを使用して作成する目的の会議を説明できます。リクエストで<confinfo>パラメーターが提供されていない場合、新しい会議はシステムデフォルトの青写真のクローンとして作成されます。
In both creation cases, the confResponse, for a successful completion of a "create" operation, contains a <response-code> of "200" and MUST contain the XCON-URI of the newly created conference in the <confObjID> parameter, in order to allow the conferencing client to manipulate that conference through following CCMP requests. In addition, the <confInfo> parameter containing the conference document created MAY be included, at the discretion of the conferencing system implementation, along with the REQUIRED <version> parameter initialized at "1", since, at creation time, the conference object is at its first version.
両方の作成の場合、「作成」操作を正常に完了するためのfenSponseは、「200」の<応答コード>を含み、<confobjid>パラメーターで新しく作成された会議のxcon-uriを含む必要があります。会議クライアントがCCMPのリクエストを通じてその会議を操作できるようにするため。さらに、作成された会議ドキュメントを含む<confinfo>パラメーターは、会議システムの実装の裁量で、「1」で初期化された必要な<バージョン>パラメーターとともに、作成時に会議オブジェクトは最初のバージョンで。
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>パラメーターを含める必要があり、<confinfo>パラメーターをリクエストに含めてはなりません。会議サーバーは、confRequestの「取得」操作で受信される<confinfo>パラメーターを無視する必要があります。取得操作のfonsponseに「200」の<応答コード>が含まれている場合、<conpinfo>パラメーターを応答に含める必要があります。<confinfo>パラメーターには、現在の状態のターゲット会議オブジェクトを説明する会議文書全体を含める必要があります。取得した会議オブジェクトの現在の状態も、適切な「バージョン」応答パラメーターで報告する必要があります。
In case of a confRequest with an <operation> parameter of "update", the <confInfo> and <confObjID> parameters MUST be included in the request. The <confInfo> represents an object of type "conference-type" containing all the changes to be applied to the conference whose identifier has the same value as the <confObjID> parameter. Note that, in such a case, though the <confInfo> parameter indeed has to follow the rules indicated in the XCON data model, it does not represent the entire updated version of the target conference, since it conveys just the modifications to apply to that conference. For example, in order to change the conference title, the <confInfo> parameter will be of the form:
「update」の<portion>パラメーターを使用したconfrequestの場合、<conpinfo>および<confobjid>パラメーターをリクエストに含める必要があります。<confinfo>は、識別子が<confobjid>パラメーターと同じ値を持つ会議に適用されるすべての変更を含む「会議タイプ」のオブジェクトを表します。そのような場合、<conpinfo>パラメーターは実際にXCONデータモデルに示されているルールに従わなければならないが、ターゲット会議の更新バージョン全体を表すものではないことに注意してください。会議。たとえば、会議のタイトルを変更するために、<conpinfo>パラメーターは次の形式になります。
<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.
「200」の<応答コード>を使用したconfresponse/updateの場合、応答メッセージには追加情報は必要ありません。つまり、<confinfo>パラメーターの返品はオプションです。その後のConfRequest/取得トランザクションは、CCMPクライアントに変更後の会議の現在のステータスを提供する場合があります。または、通知プロトコルもそのタスクに対処する場合があります。 「200」の<応答コード>は、会議サーバーのリクエストに従って会議オブジェクトが変更されたことを示しています。 <バージョン>パラメーターは、適用された変更時に、クライアントに現在の会議オブジェクトバージョンとは何かをクライアントに理解させるために、confresponse/updateメッセージに同封する必要があります。 「409」の<応答コード>は、リクエストの<Conponfo>パラメーターに反映されている変更が実行不可能であることを示しています。これは、会議システムとその構成に固有の理由で、ポリシー、要求者の役割、特定の特権、容認できない値などが原因である可能性があります。 「409」の<応答コード>とともに、<バージョン>パラメーターはfonsponse/updateに添付する必要があります。最も最新のもの。
In the case of a confRequest with an <operation> parameter of "delete", the <confObjID> parameter representing the XCON-URI of the target conference MUST be included while the <confInfo> parameter MUST NOT be included in the request. The conference server MUST ignore any <confInfo> parameter that is received within such a request. The confResponse MUST contain the same value for the <confObjID> parameter that was included in the confRequest. If the confResponse/delete operation contains a <response-code> of "200", the conference indicated in the <confObjID> parameter has been successfully deleted. A confResponse/delete with a <response-code> of "200" MUST NOT contain the <confInfo> parameter. The <version> parameter SHOULD NOT be returned in any confResponse/delete. If the conference server cannot delete the conference referenced by the <confObjID> parameter received in the confRequest because it is the parent of another conference object that is in use, the conference server MUST return a <response-code> of "425".
「delete」の<portions>パラメーターを使用したconfrequestの場合、ターゲット会議のxcon-uriを表す<confobjid>パラメーターを含める必要がありますが、<confinfo>パラメーターをリクエストに含めてはなりません。会議サーバーは、そのようなリクエスト内で受信される<confinfo>パラメーターを無視する必要があります。 fenSponseには、confrequestに含まれていた<confobjid>パラメーターと同じ値が含まれている必要があります。 confResponse/削除操作に「200」の<応答コード>が含まれている場合、<confobjid>パラメーターに示されている会議は削除されました。 「200」の<応答コード>を使用したconfResponse/削除には、<confinfo>パラメーターが含まれていないはずです。 <バージョン>パラメーターは、fonsponse/deleteで返されないでください。会議サーバーが、使用中の別の会議オブジェクトの親であるため、ConfRequestで受信した<confobjid>パラメーターで参照される会議を削除できない場合、会議サーバーは「425」の<応答コード>を返す必要があります。
A confRequest with an <operation> parameter of "retrieve", "update", or "delete" carrying a <confObjID> parameter which is not associated with one of the conferences (active or registered) that the system is holding will generate, on the server's side, a confResponse message containing a <response-code> of "404". This also holds for the case in which the mentioned <confObjID> parameter is related to an existing conference object stored at the server, but associated with a blueprint or with a sidebar rather than an actual conference.
「取得」、「更新」、または「削除」のパラメーターを含む<操作>パラメーターを含む<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メッセージを使用すると、クライアントは<sonfobjid>パラメーターで表される会議オブジェクトの<ユーザー>要素を操作できます。<users>要素には、会議参加者に関連付けられた<ユーザー>要素のリスト、会議へのアクセスが許可/拒否されるユーザーのリスト、会議参加ポリシーなどが含まれています。<confobjid>パラメーターは、usersrequestメッセージ。
A <usersInfo> parameter MAY be included in a usersRequest message depending upon the operation. If the <usersInfo> parameter is included in the usersRequest message, the parameter MUST be compliant with the <users> field of the XCON data model.
a <usersininfo>パラメーターは、操作に応じてユーザーリケストメッセージに含まれる場合があります。<usersInfo>パラメーターがusersrequestメッセージに含まれている場合、パラメーターはXCONデータモデルの<ユーザー>フィールドに準拠する必要があります。
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>パラメーターを無視する必要があります。
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>パラメーターには、示されている<ユーザー>要素に適用される変更を含める必要があります。<応答 - コード>の場合、「200」の場合、<usersInfo>パラメーターを返さないでください。返される<usersInfo>パラメーターは無視する必要があります。「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メッセージには適用されず、サーバーが考慮してはなりません。つまり、「403」の<応答コード>をusersResponseメッセージに含める必要があります。
<!-- 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>および<操作>パラメーターを含める必要があり、操作に応じて詳細なユーザー情報を含む<userininfo>パラメーターを含めることができます。ユーザーが必ずしも会議制御クライアントであるとは限らないことに注意してください（つまり、会議の参加者の中には「XCON認識」ではない）に注意してください。
An XCON-USERID SHOULD be assigned to each and every user subscribed to the system. In such a way, a user who is not a conference participant can make requests (provided she has successfully passed authorization and authentication checks), like creating a conference or retrieving conference information.
XCON-USERIDは、システムにサブスクライブされたすべてのユーザーに割り当てられる必要があります。このような方法では、会議参加者ではないユーザーは、会議の作成や会議情報の取得など、リクエストを行うことができます（承認と認証のチェックに成功した場合）。
Conference users can be created in a number of different ways. In each of these cases, the <operation> parameter MUST be set to "create" in the userRequest message. Each of the userResponse messages for these cases MUST include the <confObjID>, <confUserID>, <operation>, and <response-code> parameters. In the case of a <response-code> of "200", the userResponse message MAY include the <userInfo> parameter depending upon the manner in which the user was created:
会議ユーザーは、さまざまな方法で作成できます。これらの各ケースでは、<操作>パラメーターをユーザーリクエストメッセージで「作成」するように設定する必要があります。これらのケースの各userresponseメッセージには、<confobjid>、<confuserid>、<operation>、および<応答 - コード>パラメーターが含まれている必要があります。「200」の<応答コード>の場合、userresponseメッセージには、ユーザーの作成方法に応じて<userInfo>パラメーターを含めることができます。
o A conferencing client with an XCON-USERID adds itself to the conference: In this case, the <userInfo> parameter MAY be included in the userRequest. The <userInfo> parameter MUST contain a <user> element (compliant with the XCON data model) and the 'entity' attribute MUST be set to a value that represents the XCON-USERID of the user initiating the request. No additional parameters beyond those previously described are required in the userResponse message, in the case of a <response-code> of "200".
o XCON-USERIDを使用した会議クライアントは、会議に追加されます。この場合、<userInfo>パラメーターがuserRequestに含まれる場合があります。<userInfo>パラメーターには、<ユーザー>要素（XCONデータモデルに準拠している）を含める必要があり、「エンティティ」属性は、リクエストを開始するユーザーのXCON-USERIDを表す値に設定する必要があります。「200」の<応答コード>の場合、前述のパラメーターを超える追加のパラメーターはUSERRESPONSEメッセージでは必要ありません。
o A conferencing client acts on behalf of another user whose XCON-USERID is known: In this case, the <userInfo> parameter MUST be included in the userRequest. The <userInfo> parameter MUST contain a <user> element and the 'entity' attribute value MUST be set to the XCON-USERID of the other user in question. No additional parameters beyond those previously described are required in the userResponse message, in the case of a <response-code> of "200".
o 会議クライアントは、XCON-USERIDが知られている別のユーザーに代わって行動します。この場合、<userInfo>パラメーターをuserRequestに含める必要があります。<userInfo>パラメーターには<ユーザー>要素が含まれている必要があり、「エンティティ」属性値は、問題の他のユーザーのXCON-USERIDに設定する必要があります。「200」の<応答コード>の場合、前述のパラメーターを超える追加のパラメーターはUSERRESPONSEメッセージでは必要ありません。
o A conferencing client who has no XCON-USERID and who wants to enter, via CCMP, a conference whose identifier is known: In this case, a side effect of the request is that the user is provided with a new XCON-USERID (created by the server) carried inside the <confUserID> parameter of the response. This is the only case in which a CCMP request can be valid though carrying a void <confUserID> parameter. A <userInfo> parameter MUST be enclosed in the request, providing at least a contact URI of the joining client, in order to let the focus initiate the signaling phase needed to add her to the conference. The mandatory 'entity' attribute of the <userInfo> parameter in the request MUST be filled with a placeholder value with the user part of the XCON-USERID containing a value of AUTO_GENERATE_X as described in Section 4.3, to conform to the rules contained in the XCON data model XML schema. The messages (userRequest and userResponse) in this case should look like the following:
o XCON-USERIDがなく、CCMPを介して識別子が既知の会議を介して入力したい会議クライアント：この場合、リクエストの副作用は、ユーザーに新しいXCON-USERID（作成された）が提供されることです。サーバー）は、応答の<confuserid>パラメーター内に携帯されています。これは、void <confuserid>パラメーターを運ぶ場合にCCMPリクエストが有効である唯一のケースです。A <userininfo>パラメーターは、リクエストに囲まれ、少なくとも参加者のクライアントの連絡先を提供する必要があります。要求の<userininfo>パラメーターの必須の「エンティティ」属性は、セクション4.3に記載されているように、auto_generate_xの値を含むxcon-useridのユーザー部分でプレースホルダー値で満たされている必要があります。XCONデータモデルXMLスキーマ。この場合のメッセージ（userrequestとuserersponse）は次のようになります。
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>パラメーターの送信者と「エンティティ」属性が満たされています。プレースホルダー価値 "xcon-userid：auto_generate_1@example.com"。 3番目のユーザーのXCON-USERIDは、<応答コード>が「200」の場合、応答<UserINFO>パラメーターの「エンティティ」属性のリクエストを発行するクライアントに返品する必要があります。このシナリオは、真新しい会議システムユーザーがサードパーティ（つまり、まだXCON-USERIDが提供されていないユーザー）によって会議に追加される場合と、CCMPクライアントが発行する場合の両方をサポートすることを目的としています。リクエストでは、吸引されたユーザーのXCON-USERID（このような識別子がそのユーザーのサーバー側に既に存在する可能性があることを意味します）を知りません。この最後のケースでは、会議サーバーは、同じ会議クライアントのXCON-URIの重複を回避することを担当し、信号URIなどの要求が提供する<userInfo>パラメーターの重要なフィールドを調べます。参加者が真新しい場合、新しい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/取得に含める必要があります。取得操作のuserresponseに「200」の<応答コード>が含まれている場合、<userininfo>パラメーターを応答に含める必要があります。
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>パラメーターをリクエストに含める必要があります。 <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>を含める必要があります。 CCMPクライアントのXCON-USERIDを含む<Conduserid>パラメーターは、userRequestメッセージに含める必要があります。クライアントが指定された会議を終了したい場合は、削除要求に<userinfo>パラメーターが必要です。一方、クライアントが指定された会議から別の参加者を削除したい場合は、「エンティティ」属性がその参加者のXCON-USERIDを伝える「エンティティ」属性がその<userInfo>パラメーターをuserRequest/delete a <userInfo>パラメーターに含める必要があります。 USERRESPONSEには、userRequestの<confobjid>パラメーターに含まれていた<sonfobjid>パラメーターに対して同じ値を含める必要があります。ターゲット<ユーザー>要素が正常に削除されている場合、userresresponseには「200」の<応答コード>を含める必要があります。削除操作のUSERRESPONSEに「200」の<応答コード>が含まれている場合、USERRESPONSEには<userInfo>パラメーターが含まれてはなりません。
<!-- 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メッセージは取得のみのタイプであるため、<操作>パラメーターをSideBarsByValRequestメッセージに含めてはなりません。青写真や会議と同様に、CCMPは、サーバーの側で利用可能なサイドバーの選択したサブセットをクライアントが取得する必要がある場合、Xpathフィルターを使用できます。これは、参照によりサイドバーに適用され、サイドバーは値で適用されます。 「200」の<応答コード>を使用したSideBarsByValResponseメッセージには、目的の<sidebars-by-val>要素を含む<sidebarsbyvalinfo>パラメーターを含める必要があります。 sidebarsbyvalResponseメッセージは、メインカンファレンスオブジェクトの現在のバージョン（つまり、識別子がリクエストの<confobjid>フィールドに含まれているもの）に関連するクライアントA <バージョン>要素に戻る必要があります。 。 <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>パラメーターを含める必要があります。他の必要なパラメーターは、操作の種類によって異なります。
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.
「作成」操作の場合、<confobjid>パラメーターをsidebyvalRequestメッセージに含める必要があります。この場合、<confobjid>パラメーターには、サイドバーを作成する必要があるメインカンファレンスのxcon-uriが含まれています。 「SideBarbyValinfo」パラメーターが含まれていない場合、XCONフレームワーク[RFC5239]で想定されているように、実装固有のクローニングルールに従ってメイン会議をクローニングすることにより、サイドバーが作成されます。それ以外の場合、直接作成の場合と同様に、サイドバーカンファレンスオブジェクトは、リクエスターが提供する「サイドバルビバリンフォー」パラメーターに基づいて構築されます。サイドバーごとの作成の結果として、会議サーバーは、サイドバルビヴァルレクエストの<confobjid>パラメーターに反映されたメインカンファレンスオブジェクトを更新する必要があります。サイドバーごと>。新しく作成されたサイドバーカンファレンスオブジェクトは、<応答コード>が「200」の場合、<sidebarbyvalinfo>パラメーターのSideBarbyValResponseに含めることができます。新しく作成されたサイドバーのXCON-URIは、応答の<confobjid>パラメーターに表示する必要があります。会議サーバーは、会議イベントパッケージを購読し、会議へのサイドバーの追加の通知を受け取ることが許可されている会議クライアントに通知できます。
In the case of a sidebarByValRequest message with an <operation> parameter of "retrieve", the URI for the conference object created for the sidebar (received in response to a create operation or in a sidebarsByValResponse message) MUST be included in the <confObjID> parameter in the request. This retrieve operation is handled by the conference server in the same manner as in the case of an <operation> parameter of "retrieve" included in a confRequest message, as described in Section 5.3.4.
sidebarbyvalRequestメッセージの場合、「取得」の<操作>パラメーターを使用して、サイドバー向けに作成された会議オブジェクトのURI（作成操作またはサイドバージーヴァルレスポンスメッセージで受信）を<confobjid>に含める必要があります）リクエストのパラメーター。この取得操作は、セクション5.3.4で説明されているように、confrequestメッセージに含まれる「取得」の<操作>パラメーターの場合と同じ方法で会議サーバーによって処理されます。
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>もリクエストに含める必要があります。リクエストメッセージに含まれる<confobjid>パラメーターは、更新される特定のサイドバーインスタンスを識別します。<sidebarbyvalinfo>パラメーターに含まれる特定のサイドバーインスタンスの更新操作は、セクションで詳述されているように、コンフレクエストメッセージに含まれる<confinfo>パラメーターに反映されているように、会議インスタンスの更新操作と同じ方法で会議サーバーによって処理されます。5.3.4。SideBarbyValResponseメッセージは、リクエストの<sonfobjid>フィールドに識別子が含まれているサイドバーの現在のバージョンに関連するクライアントA <バージョン>要素に戻す必要があります。
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.
「delete」の<操作>パラメーターがSideBarbyvalリクエストに含まれている場合、<sidebarbyvalinfo>パラメーターをリクエストに含めてはなりません。リクエストに含まれる<sidebarbyvalinfo>は、会議サーバーで無視する必要があります。サイドバーに関連付けられている会議オブジェクトのURIは、リクエストの<confobjid>パラメーターに含める必要があります。<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>要素を取得するために、sidebarsbybyrefrequestを呼び出すことができます。 SideBarsByRefRequestメッセージは取得のみのタイプであるため、<操作>パラメーターをSideBarsByRefRequestメッセージに含めてはなりません。 「200」の<応答コード>の場合、会議オブジェクトの<sidebars-by-ref>要素を含む<sidebarsbyrefinfo>パラメーターを応答に含める必要があります。 <サイドバーバイレフ>要素は、メインカンファレンスに関連付けられたサイドバーのURIのセットを表します。取得されたURISを通じて、セクション5.3.10で説明するサイドバルビレフレクエストメッセージを使用して、単一のサイドバーにアクセスすることができます。 sidebarsbyRefresponseメッセージは、問題のサイドバーがあるメインカンファレンスオブジェクト（つまり、識別子がリクエストの<confobjid>フィールドに含まれているもの）に関連するクライアントA <バージョン>要素に戻す必要があります。関連する。
<!-- 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 <バージョン>要素に戻す必要があります。
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メッセージに含める必要があります。この場合、<confobjid>パラメーターには、サイドバーを作成する必要があるメインカンファレンスのxcon-uriが含まれています。 XCONフレームワーク[RFC5239]に従って、<sidebarbyrefinfo>パラメーターが含まれていない場合、サイドバーはメイン会議のクローニングによって作成され、実装固有のクローニングルールを観察します。それ以外の場合、直接作成の場合と同様に、サイドバーカンファレンスオブジェクトは、要求者が提供する<sidebarbyrefinfo>パラメーターに基づいて構築されます。サイドバーの作成が成功した場合、会議サーバーは、サイドバーが作成された会議オブジェクトの<sidebar-by-ref>要素を更新する必要があります（つまり、元のSideBarbyRefrequestの<confobjid>で識別されます）、新しく作成されたサイドバーのURI。新しく作成されたカンファレンスオブジェクトは、「200」の<応答コード>を含む<sidebarbyrefinfo>パラメーターの応答に含めることができます。新しく作成されたサイドバーオブジェクトに関連付けられた会議オブジェクトのURIは、応答の<sonfobjid>パラメーターに表示する必要があります。会議サーバーは、会議イベントパッケージを購読し、会議へのサイドバーの追加の通知を受け取ることが許可されている会議クライアントに通知できます。
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>パラメーターに含める必要があります。<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>パラメーターに含める必要があります。<sidebarbyrefinfo>は、「更新」操作の場合にもリクエストに含める必要があります。<sidebarbyrefinfo>の更新操作は、セクション5.3.4で詳述されているように、<confinfo>の更新操作と同じ方法で会議サーバーによって処理されます。SideBarbyRefresponseメッセージは、識別子がリクエストの<confobjid>フィールドに含まれているサイドバーの現在のバージョンに関連するクライアントA <バージョン>要素に戻す必要があります。
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.
「delete」の<porters>パラメーターがSideBarbyRefRequestに含まれている場合、<sidebarbyrefinfo>パラメーターをリクエストに含める必要はありません。リクエストに含まれる<sidebarbyrefinfo>は、会議サーバーで無視する必要があります。サイドバーのカンファレンスオブジェクトのURIは、リクエストの<confobjid>パラメーターに含める必要があります。リクエストの<confuserid>パラメーターに反映されている特定の会議ユーザーが会議を削除することが許可されている場合、会議サーバーは<confobjid>パラメーターに反映されたカンファレンスオブジェクトを削除し、<sidebars-by-ref>要素を更新する必要があります。サイドバーが元々クローン化された会議のオブジェクト。会議サーバーは、会議イベントパッケージを購読し、サイドバーの削除の通知を受け取ることが許可されている会議クライアントに通知できます。
If a sidebarByRefRequest with an <operation> parameter of "retrieve", "update", or "delete" carries a <confObjID> parameter that is not associated with any existing sidebar-by-ref, a confResponse message containing a <response-code> of "404" will be generated on the server's side. This also holds for the case in which the value of the mentioned <confObjID> parameter is related to an existing conference object stored at the server, but associated with a blueprint or with an actual conference or with a sidebar-by-val rather than a sidebar-by-ref.
「取得」、「更新」、または「削除」の<操作>パラメーターを備えたサイドバルビレフレクエストには、既存のサイドバーごとに関連付けられていない<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は拡張レクエストと拡張リスポンスメッセージを定義します。このようなメッセージは、CCMP仕様で明示的に想定されていない会議制御メカニズムを実現するために必要な情報を実装者が輸送できるCCMPスケルトンを構成します。これらのメカニズムは、この文脈で「拡張機能」と呼ばれます。各拡張機能は、提供された<拡張機能>フィールドの拡張レクエスト/拡張リスポンセペアに携帯する必要がある適切な名前によって特徴付けられると想定されています。拡張固有の情報は、拡張レクエストと拡張レスポンセの両方に存在する<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スキーマを回復できる必要があります（セクション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パラメーターの意味は、拡張機能を定義しながら適切に保存および悪用する必要があります。
<!-- 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>（必須）：標準メッセージの場合、このドキュメントで定義されている10の標準メッセージ名の1つになります（つまり、「BluePrintsRequest」、「ConfsRequest」など）。拡張機能の場合、この要素は、対応する拡張レクエスト/拡張リスポンスメッセージペアに挿入された<拡張機能>の同じ値を運ぶ必要があります。
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>（オプション）：このフィールドは<Operation>エントリのリストであり、それぞれがメッセージのためにサーバーがサポートする作成、読み取り、更新、削除（CRUD）操作を表しています。この要素がない場合、クライアントはサーバーができると想定する必要があります
handle the entire set of CRUD operations or, in case of standard messages, all the operations envisioned for that message in this document.
CRUD操作のセット全体、または標準メッセージの場合、このドキュメントのメッセージについて想定されているすべての操作を処理します。
o <schema-ref> (OPTIONAL): since all CCMP messages can potentially contain XML elements not envisioned in the CCMP schema (due to the presence of <any> elements and attributes), a reference to a proper schema definition specifying such new elements/attributes can also be sent back to the clients by means of such field. If this element is absent, no new elements are introduced in the messages other than those explicitly defined in the CCMP specification.
o <Schema-Ref>（オプション）：すべてのCCMPメッセージには、CCMPスキーマで想定されていないXML要素が含まれる可能性があるため（<Any>要素と属性の存在のため）、そのような新しい要素を指定する適切なスキーマ定義への参照/属性は、そのようなフィールドを使用してクライアントに送り返すこともできます。この要素がない場合、CCMP仕様で明示的に定義されているもの以外のメッセージに新しい要素は導入されていません。
o <description> (OPTIONAL): human-readable information about the related message.
o <説明>（オプション）：関連するメッセージに関する人間が読める情報。
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サーバーは、ccmpサーバーが少なくとも1つの操作の要求メッセージと応答メッセージの両方を処理できるようにする必要があるため、OptionsResponseに少なくとも1つの<操作>要素を含む<standard-message-list>を含む<standard-message-list>を含める必要があります。
<!-- 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応答メッセージには、<応答コード>を含める必要があります。このドキュメントでは、セクション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"操作への回答：サードパーティの招待状の場合、<confuserid>（<userinfo>の「エンティティ」属性に含まれる場合、このコードは返品できます。追加するユーザーのパラメーター）は不明です。上記の場合、代わりに、無効なリクエストの送信者の<confuserid>パラメーターである場合、「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」の<応答コード>の場合、会議クライアントは、会議クライアントまたは会議サーバーに固有の期間内にリクエストを再取り付けすることができます。
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」の<応答コード>は、会議クライアントが不正な要求を送信したことを示します。これは、会議クライアントまたは会議サーバーのエラーを示しています。ハンドリングは、クライアントの実装を会議に固有のものにします（例：ログを生成し、エラーメッセージを表示するなど）。この場合、クライアントがリクエストを再試行することはお勧めしません。
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」の<応答コード>は、クライアントが適切な権限を持っていないことを示します。または、許可にエラーがあります。リクエストの再取り付けは成功しない可能性が高いため、推奨されません。
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」の<応答コード>と同じ方法でクライアントによって扱われる必要があります。
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番目のトランザクションを示しています。アリスはCCMPを使用して、新しく作成された会議に自分自身を追加します。これは、<useriNfo>パラメーターに、xconデータモデルの表現に準拠した<ユーザー>要素を含むユーザーリクエスト/作成メッセージを介して達成されます。そのような要素には、ユーザーの記録アドレスに関する情報と現在のエンドポイントが含まれていることに注意してください。下の写真は、トランザクションを示しています。<confuserid>パラメーターが、クライアントが発行したリクエストがファーストパーティのリクエストであることを示す<userininfo>要素の「エンティティ」属性に等しい方法に注意してください。
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番目と最後のトランザクションを示しています。アリスはCCMPを使用して、新しい会議システムユーザーであるCICCIOを会議に追加します。この「サードパーティ」リクエストは、<useriNfo>パラメーターに、xconデータモデルの表現に準拠した<userin>要素を含むユーザーリクエスト/作成メッセージを介して実現されます。このような要素には、CICCIOの記録アドレスに関する情報と現在のエンドポイントが含まれているが、セクション4.3で説明したように、プレースホルダーの「エンティティ」属性「auto_generate_1@example.com」が含まれていることに注意してください。アリスに。したがって、カンファレンスサーバーは、ユーザーアリスの新しいXCON-USERIDの生成（つまり、CICCIO）を担当し、応答に掲載された<userinInfo>パラメーターの「エンティティ」属性でそれを返すだけでなく、追加するだけでなく、追加することを担当し、追加します。会議のユーザー。下の写真は、トランザクションを示しています。
Alice adds user "Ciccio" to the conference by issuing a third-party userRequest/create message to the server:
Aliceは、サードパーティのユーザーRequest/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. アリスからの「サードパーティ」ユーザーリクエストメッセージ：
<?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. サーバーからの「サードパーティ」ueserresponseメッセージ：
<?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.
会議クライアントがリクエストに特定の会議サーバーを使用するように事前に構成されていない場合、クライアントは最初に会議サーバーがリクエストを送信する前に発見する必要があります。発見プロセスの結果は、会議をサポートするサーバーのアドレスです。このドキュメントでは、結果はHTTP：またはHTTPS：URIで、会議サーバーを識別します。
DNS is RECOMMENDED to be used to locate a conference server in the case that the client is not pre-configured to use a specific conference server. URI-Enabled NAPTR (U-NAPTR) resolution for conferencing takes a domain name as input and produces a URI that identifies the conference server. This process also requires an Application Service tag and an Application Protocol tag, which differentiate conferencing-related NAPTR records from other records for that domain.
DNSは、クライアントが特定の会議サーバーを使用するために事前に構成されていない場合に会議サーバーを見つけるために使用することをお勧めします。会議用のURI対応NAPTR（U-NAPTR）解像度は、ドメイン名を入力として受け取り、会議サーバーを識別するURIを生成します。このプロセスには、アプリケーションサービスタグとアプリケーションプロトコルタグも必要です。これは、そのドメインの他のレコードから会議関連のNAPTRレコードを区別します。
Section 12.4.1 defines an Application Service tag of "XCON", which is used to identify the centralized conferencing (XCON) server for a particular domain. The Application Protocol tag "CCMP", defined in Section 12.4.2, is used to identify an XCON server that understands CCMP.
セクション12.4.1は、特定のドメインの集中会議（XCON）サーバーを識別するために使用される「XCON」のアプリケーションサービスタグを定義します。セクション12.4.2で定義されているアプリケーションプロトコルタグ「CCMP」は、CCMPを理解するXCONサーバーを識別するために使用されます。
The NAPTR records in the following example (Figure 29) demonstrate the use of the Application Service and Application Protocol tags. Iterative NAPTR resolution is used to delegate responsibility for the conferencing service from "zonea.example.com." and "zoneb.example.com." to "outsource.example.com.".
次の例（図29）のNAPTRレコードは、アプリケーションサービスとアプリケーションプロトコルタグの使用を示しています。反復NAPTR解像度は、「zonea.example.com」からの会議サービスの責任を委任するために使用されます。および「Zoneb.example.com」「outsource.example.com」に。
zonea.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.com.
;; order pref flags
IN NAPTR 100 10 "" "XCON-CCMP" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "XCON-CCMP" ( ; service
"!*.!https://confs.example.com/!" ; regex
. ; replacement
)
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]を、以下に説明するように、会議データの変更の通知にクライアントが使用する必要があります。
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].
Conferencing ControlクライアントがSIP [RFC3261]をシグナリングプロトコルとして使用して会議に参加する場合、SIPイベント通知を使用できます。そのような場合、会議制御クライアントは、XCON [RFC6502]の会議イベントパッケージを実装する必要があります。これは、XCONフレームワーク[RFC5239]ごとにシグナリングのSIPと同様に、クライアントを会議するためのデフォルトのメカニズムです。
In the case where the interface to the conference server is entirely web based, there is a common mechanism for web-based systems that could be used -- a "call back". With this mechanism, the conferencing client provides the conference server with an HTTP URL that is invoked when a change occurs. This is a common implementation mechanism for e-commerce. This works well in the scenarios whereby the conferencing client is a web server that provides the graphical HTML user interface and uses CCMP as the back-end interface to the conference server. This model can coexist with the SIP event notification model. PC-based clients behind NATs could provide a SIP event URI, whereas web-based clients using CCMP in the back end would probably find the HTTP call back approach much easier. The details of this approach are out of scope for CCMP; thus, we expect a future specification will document this solution.
会議サーバーへのインターフェイスが完全にWebベースである場合、使用できるWebベースのシステムには共通のメカニズムがあります - 「コールバック」。このメカニズムにより、会議クライアントは会議サーバーに、変更が発生したときに呼び出されるHTTP URLを提供します。これは、eコマースの一般的な実装メカニズムです。これは、会議クライアントがグラフィカルなHTMLユーザーインターフェイスを提供し、CCMPをカンファレンスサーバーへのバックエンドインターフェイスとして使用するWebサーバーであるシナリオでうまく機能します。このモデルは、SIPイベント通知モデルと共存できます。NATSの背後にあるPCベースのクライアントは、SIPイベントURIを提供できますが、バックエンドでCCMPを使用するWebベースのクライアントは、おそらくHTTPコールバックアプローチがはるかに簡単になるでしょう。このアプローチの詳細は、CCMPの範囲外です。したがって、将来の仕様がこのソリューションを文書化することを期待しています。
This section describes the use of HTTP [RFC2616] and HTTP over TLS [RFC2818] as transport mechanisms for CCMP, which a conforming conference server and conferencing client MUST support.
このセクションでは、CCMPの輸送メカニズムとして、TLS [RFC2818]を介したHTTP [RFC2616]およびHTTPの使用について説明します。
Although CCMP uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a conferencing server might not be a fully compliant HTTP server. It is intended that a conference server can easily be built using an HTTP server with extensibility mechanisms, and that a conferencing client can trivially use existing HTTP libraries. This subset of requirements helps implementers avoid ambiguity with the many options the full HTTP protocol offers.
CCMPはHTTPをトランスポートとして使用しますが、HTTP機能の厳格なサブセットを使用しており、一部の機能の制限により、会議サーバーは完全に準拠したHTTPサーバーではない場合があります。会議サーバーは、拡張性メカニズムを備えたHTTPサーバーを使用して簡単に構築でき、会議クライアントは既存のHTTPライブラリを簡単に使用できることを意図しています。この要件のサブセットは、実装者が完全なHTTPプロトコルが提供する多くのオプションで曖昧さを回避するのに役立ちます。
Support of HTTP authentication [RFC2617] and cookies [RFC6265] is OPTIONAL for a conferencing client that conforms to this specification. These mechanisms are unnecessary because CCMP requests carry their own authentication information (in the "subject" field; see Section 5.1). A conferencing client SHOULD include support for HTTP proxy authentication.
HTTP認証[RFC2617]およびCookie [RFC6265]のサポートは、この仕様に準拠する会議クライアントにとってオプションです。CCMP要求には独自の認証情報が含まれているため、これらのメカニズムは不要です（「サブジェクト」フィールド、セクション5.1を参照）。会議クライアントには、HTTPプロキシ認証のサポートを含める必要があります。
A CCMP request is carried in the body of an HTTP POST request. The conferencing client MUST include a Host header in the request.
CCMPリクエストは、HTTP POSTリクエストの本文で送られます。会議クライアントには、リクエストにホストヘッダーを含める必要があります。
The MIME type of CCMP request and response bodies is "application/ ccmp+xml". The conference server and conferencing client MUST provide this value in the HTTP Content-Type and Accept header fields. If the conference server does not receive the appropriate Content-Type and Accept header fields, the conference server SHOULD fail the request, returning a 406 (Not Acceptable) response. CCMP responses SHOULD include a Content-Length header.
CCMPリクエストと応答本体のMIMEタイプは「アプリケーション/ CCMP XML」です。会議サーバーと会議クライアントは、HTTPコンテンツタイプでこの値を提供し、ヘッダーフィールドを受け入れる必要があります。Conference Serverが適切なコンテンツタイプを受信せず、ヘッダーフィールドを受け入れる場合、会議サーバーは要求に失敗し、406（受け入れられない）応答を返します。CCMP応答には、コンテンツレングスヘッダーを含める必要があります。
Conferencing clients MUST NOT use the Expect header or the Range header in CCMP requests. The conference server MAY return 501 (Not Implemented) errors if either of these HTTP features are used. In the case that the conference server receives a request from the conferencing client containing an If-* (conditional) header, the conference server SHOULD return a 412 (precondition failed) response.
会議クライアントは、CCMPリクエストで予想ヘッダーまたはレンジヘッダーを使用してはなりません。会議サーバーは、これらのHTTP機能のいずれかが使用されている場合、501（実装されていない）エラーを返す場合があります。IF-*（条件付き）ヘッダーを含む会議サーバーが会議クライアントからリクエストを受信する場合、会議サーバーは412（前提条件に失敗した）応答を返す必要があります。
The POST method is the only method REQUIRED for CCMP. If a conference server chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a conferencing client only uses a POST method, the GET or HEAD MUST be either a URL that was found outside its normal context (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody is testing or debugging a system. The conference server could provide information in the CCMP response indicating that the URL corresponds to a conference server and only responds to CCMP POST requests or the conference server could instead try to avoid any leak of information by returning a very generic HTTP error message such as 405 (Method Not Allowed).
POSTメソッドは、CCMPに必要な唯一の方法です。会議サーバーがGetまたはHeadをサポートすることを選択した場合、アプリケーションの種類がGETを実行することを検討する必要があります。会議クライアントはPOSTメソッドのみを使用するため、GETまたはHEADは通常のコンテキストの外で見つかったURLでなければなりません（たとえば、誰かがプロトコルトレースまたはログファイルでURLを見つけてブラウザに供給します）または誰かがテストしていますまたはシステムのデバッグ。Conference Serverは、URLがConference Serverに対応し、CCMP Postリクエストにのみ応答することを示すCCMP応答に情報を提供できます。（許可されていない方法）。
The conference server populates the HTTP headers of responses so that they are consistent with the contents of the message. In particular, the CacheControl header SHOULD be set to disable caching of any conference information by HTTP intermediaries. Otherwise, there is the risk of stale information and/or the unauthorized disclosure of the information. The HTTP status code MUST indicate a 2xx series response for all CCMP Response and Error messages.
会議サーバーは、応答のHTTPヘッダーに浸透し、メッセージの内容と一致するようにします。特に、Cachecontrolヘッダーは、HTTP仲介者による会議情報のキャッシュを無効にするように設定する必要があります。それ以外の場合、古い情報や情報の不正な開示のリスクがあります。HTTPステータスコードは、すべてのCCMP応答とエラーメッセージの2xxシリーズ応答を示す必要があります。
The conference server MAY redirect a CCMP request. A conference server MUST NOT include CCMP responses in a 3xx response. A conferencing client MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the conferencing client MUST observe the delay indicated by the Retry-After header. The conferencing client MUST authenticate the server that returns the redirect response before following the redirect. A conferencing client SHOULD authenticate the conference server indicated in a redirect.
会議サーバーは、CCMPリクエストをリダイレクトする場合があります。会議サーバーは、3XX応答にCCMP応答を含めるべきではありません。会議クライアントは、サーバーが3XX応答で提供しているロケーションヘッダーを使用してリダイレクトを処理する必要があります。リダイレクトの場合、会議クライアントは、再試行後のヘッダーによって示される遅延を遵守する必要があります。会議クライアントは、リダイレクトに従う前にリダイレクト応答を返すサーバーを認証する必要があります。会議クライアントは、リダイレクトに示されている会議サーバーを認証する必要があります。
The conference server SHOULD support persistent connections and request pipelining. If pipelining is not supported, the conference server MUST NOT allow persistent connections. The conference server MUST support termination of a response by the closing of a connection.
会議サーバーは、永続的な接続をサポートし、パイプラインを要求する必要があります。パイプラインがサポートされていない場合、会議サーバーは永続的な接続を許可してはなりません。会議サーバーは、接続を閉じることにより、応答の終了をサポートする必要があります。
Implementations of CCMP that implement HTTP transport MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the conferencing client and the conference server. The conferencing client MUST implement the server authentication method described in HTTPS [RFC2818]. The device uses the URI obtained during conference server discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the conferencing client SHOULD fail a request if server authentication fails.
HTTP輸送を実装するCCMPの実装は、TLS [RFC2818]を介して輸送を実装する必要があります。TLSは、会議クライアントと会議サーバーの間でメッセージの整合性と機密性を提供します。会議クライアントは、HTTPS [RFC2818]で説明されているサーバー認証方法を実装する必要があります。デバイスは、会議サーバーの発見中に取得したURIを使用してサーバーを認証します。この認証方法の詳細は、HTTPS [RFC2818]のセクション3.1に記載されています。TLSを使用すると、サーバー認証が失敗した場合、会議クライアントはリクエストに失敗するはずです。
As identified in the XCON framework [RFC5239], there are a wide variety of potential attacks related to conferencing, due to the natural involvement of multiple endpoints and the capability to manipulate the data on the conference server using CCMP. Examples of attacks include the following: an endpoint attempting to listen to conferences in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and an endpoint theft of service in attempting to create conferences it is not allowed to create.
XCONフレームワーク[RFC5239]で特定されているように、複数のエンドポイントの自然な関与とCCMPを使用して会議サーバー上のデータを操作する機能により、会議に関連する潜在的な攻撃がさまざまに潜在的な攻撃があります。攻撃の例には、以下が含まれます。参加を許可されていない会議を聴こうとするエンドポイント、他のユーザーを切断またはミュートしようとするエンドポイント、および会議を作成しようとする際のサービスの盗難の盗難は、作成することはできません。。
The following summarizes the security considerations for CCMP:
以下は、CCMPのセキュリティ上の考慮事項をまとめたものです。
1. The client MUST determine the proper conference server. The conference server discovery is described in Section 7.
1. クライアントは、適切な会議サーバーを決定する必要があります。会議サーバーの発見については、セクション7で説明します。
2. The client MUST connect to the proper conference server. The mechanisms for addressing this security consideration are described in Section 10.1.
2. クライアントは、適切な会議サーバーに接続する必要があります。このセキュリティの考慮に対処するためのメカニズムは、セクション10.1で説明されています。
3. The protocol MUST support a confidentiality and integrity mechanism. As described in Section 9, implementations of CCMP MUST implement the HTTP transport over TLS [RFC2818].
3. プロトコルは、機密性と整合性メカニズムをサポートする必要があります。セクション9で説明したように、CCMPの実装は、TLS [RFC2818]を介してHTTP輸送を実装する必要があります。
4. There are security issues associated with the authorization to perform actions on the conferencing system to invoke specific capabilities. A conference server SHOULD ensure that only authorized entities can manipulate the conference data. The mechanisms for addressing this security consideration are described in Section 10.2.
4. 特定の機能を呼び出すために、会議システムでアクションを実行する許可に関連するセキュリティの問題があります。会議サーバーは、認可されたエンティティのみが会議データを操作できるようにする必要があります。このセキュリティの考慮に対処するためのメカニズムは、セクション10.2で説明されています。
5. The privacy and security of the identity of a user in the conference MUST be assured. The mechanisms to ensure the security and privacy of identity are discussed in Section 10.3.
5. 会議でユーザーのIDのプライバシーとセキュリティを保証する必要があります。アイデンティティのセキュリティとプライバシーを確保するためのメカニズムについては、セクション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）の使用が推奨されます。
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を介して取引できる必要があります
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]の手順に従って証明書を検証できる必要があることに注意してください。特に、証明書の検証パスは、その信頼アンカーが会議サーバー証明書自体であっても、クライアントの信頼アンカーの1つで終了する必要があります。クライアントが、適切な会議サーバーの予想されるIDまたは資格情報に関する外部情報を持っている場合、上記の認証チェックは省略できます。
Many policy authorization decisions are based on the identity of the user or the role that a user may have. The conference server MUST implement mechanisms for authentication of users to validate their identity. There are several ways that a user might authenticate its identity to the system. For users joining a conference using one of the call signaling protocols, the user authentication mechanisms for the specific protocol can be used. For example, in the case of a user joining the conference using SIP signaling, the user authentication as defined in [RFC3261] MUST be used. For the case of users joining the conference using CCMP, the CCMP Request messages provide a subject field that contains a username and password, which can be used for authentication. Since the CCMP messages are RECOMMENDED to be carried over TLS, this information can be sent securely.
多くのポリシー認可決定は、ユーザーの身元またはユーザーが持つ可能性のある役割に基づいています。会議サーバーは、ユーザーの認証のためのメカニズムを実装して、アイデンティティを検証する必要があります。ユーザーがシステムにアイデンティティを認証する方法はいくつかあります。通話信号プロトコルのいずれかを使用して会議に参加するユーザーの場合、特定のプロトコルのユーザー認証メカニズムを使用できます。たとえば、SIPシグナリングを使用して会議に参加しているユーザーの場合、[RFC3261]で定義されているユーザー認証を使用する必要があります。CCMPを使用して会議に参加するユーザーの場合、CCMPリクエストメッセージは、認証に使用できるユーザー名とパスワードを含む件名フィールドを提供します。CCMPメッセージはTLSに携帯することをお勧めします。この情報は安全に送信できます。
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インターフェイスの認可を他の認証メカニズムに関連付けることをお勧めします。たとえば、PINに参加し、CCMPを使用して会議を制御する公開された電話ネットワーク（PSTN）ユーザー。会議サーバーが認定ユーザーのIDを提示すると、システムによってIDが証明または検証された方法に関する情報を提供する場合があります。会議サーバーは、完全に認知されていないユーザーをシステムに入れることもできます。この情報は、利害関係者にも通知する必要があります。
Once a user is authenticated and authorized through the various mechanisms available on the conference server, the conference server MUST allocate a conference user identifier (XCON-USERID) and SHOULD associate the XCON-USERID with any signaling specific user identifiers that were used for authentication and authorization. This XCON-USERID can be provided to a specific user through the conference notification interface and MUST be provided to users that interact with the conferencing system using CCMP (i.e., in the appropriate CCMP response messages). The XCON-USERIDs for each user/
ユーザーが会議サーバーで利用可能なさまざまなメカニズムを通じて認証および承認されたら、会議サーバーは会議ユーザー識別子（XCON-USERID）を割り当てる必要があり、XCON-USERIDを認証に使用したシグナリング固有のユーザー識別子に関連付けなければなりません。許可。このXCON-USERIDは、会議通知インターフェイスを介して特定のユーザーに提供でき、CCMPを使用して会議システムと対話するユーザーに提供する必要があります（つまり、適切なCCMP応答メッセージ）。各ユーザーのXCON-USERIDS/
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.
会議の参加者は、会議オブジェクトの<ユーザー>要素の「エンティティ」属性に含まれています。XCON-USERIDは、カンファレンスオブジェクト上のユーザーによる後続の操作に必要であり、CCMPリクエストと応答のConfuserIDパラメーターに携帯されています。
Note that the policy management of an XCON-compliant conferencing system is out of the scope of this document, as well as of the XCON working group (WG). However, the specification of a policy management framework is realizable with the overall XCON architecture, in particular with regard to a Role-Based Access Control (RBAC) approach. In RBAC, the following elements are identified: (i) Users; (ii) Roles; (iii) Objects; (iv) Operations; (v) Permissions. For all of the above elements, a direct mapping exists onto the main XCON entities. As an example, RBAC objects map onto XCON data model objects and RBAC operations map onto CCMP operations.
XCON準拠の会議システムのポリシー管理は、XCONワーキンググループ（WG）の範囲外であることに注意してください。ただし、ポリシー管理フレームワークの指定は、特にロールベースのアクセス制御（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のプライバシーを確保するためのメカニズムをサポートする必要があります。会議クライアントは、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>要素を含める必要があります。「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攻撃の可能性を最小限に抑えるために、会議システムに参加しているクライアントのユーザー認証と承認が必要になることをお勧めします。これは、セクション10.2で説明されているメカニズムを使用して、および特定のシグナル伝達に関連するセキュリティメカニズム（例：セッション開始プロトコルセキュア（SIP））およびメディアプロトコル（たとえば、セキュアリアルタイムトランスポートプロトコル（例：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]を示します。これは、「アプリケーション/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.
このセクションでは、「アプリケーション/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.
その他の情報：このメディアタイプは、アプリケーション/XML [RFC3023]の専門化であり、そこに記載されている考慮事項の多くは、アプリケーション/CCMP XMLにも適用されます。
Section 12.4.1 defines an Application Service tag of "XCON", which is used to identify the centralized conferencing (XCON) server for a particular domain. The Application Protocol tag "CCMP", defined in Section 12.4.2, is used to identify an XCON server that understands CCMP.
セクション12.4.1は、特定のドメインの集中会議（XCON）サーバーを識別するために使用される「XCON」のアプリケーションサービスタグを定義します。セクション12.4.2で定義されているアプリケーションプロトコルタグ「CCMP」は、CCMPを理解するXCONサーバーを識別するために使用されます。
This section registers a new S-NAPTR/U-NAPTR Application Service tag for XCON, as mandated by [RFC3958].
このセクションでは、[RFC3958]で義務付けられているように、XCONの新しいS-NAPTR/U-NAPTRアプリケーションサービスタグを登録します。
Application Service Tag: XCON
アプリケーションサービスタグ：XCON
Intended usage: Identifies a server that supports centralized conferencing.
意図された使用法：集中会議をサポートするサーバーを識別します。
Defining publication: RFC 6503
出版物の定義：RFC 6503
Contact information: The authors of this document
連絡先情報：このドキュメントの著者
Author/Change controller: The IESG
著者/変更コントローラー：IESG
12.4.2. Registration of a Conference Server Application Protocol Tag for CCMP
12.4.2. CCMPの会議サーバーアプリケーションプロトコルタグの登録
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for CCMP, as mandated by [RFC3958].
このセクションでは、[RFC3958]で義務付けられているように、CCMPの新しいS-NAPTR/U-NAPTRアプリケーションプロトコルタグを登録します。
Application Service Tag: CCMP
アプリケーションサービスタグ：CCMP
Intended Usage: Identifies the Centralized Conferencing (XCON) Manipulation Protocol.
意図された使用法：集中会議（XCON）操作プロトコルを識別します。
Applicable Service Tag(s): XCON
該当するサービスタグ：XCON
Terminal NAPTR Record Type(s): U
ターミナルNAPTRレコードタイプ：u
Defining Publication: RFC 6503
出版物の定義：RFC 6503
Contact Information: The authors of this document
連絡先情報：このドキュメントの著者
Author/Change Controller: The IESG
著者/変更コントローラー：IESG
The IANA has created a new registry for CCMP: http://www.iana.org/assignments/ccmp-parameters. The document creates initial sub-registries for CCMP operation types and response codes.
IANAは、CCMPの新しいレジストリを作成しました：http：//www.iana.org/assignments/ccmp-parameters。このドキュメントでは、CCMP操作タイプと応答コードの初期サブレジストリを作成します。
The following summarizes the registry for CCMP messages:
以下は、CCMPメッセージのレジストリをまとめたものです。
Related Registry: CCMP Message Types Registry
関連レジストリ：CCMPメッセージタイプレジストリ
Defining RFC: RFC 6503.
RFCの定義：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.
422無効な会議にアクセス/操作するための要求[RFC6503]パスワードパスワードで保護された会議オブジェクトには、無効な<Conference-PassWord>パラメーターが含まれていました。
423 Conference Password A request to access/manipulate [RFC6503] Required a password-protected conference object did not contain a <conference-password> parameter.
423会議のパスワードアクセス/操作の要求[RFC6503]は、パスワードで保護された会議オブジェクトに<Conference-Password>パラメーターが含まれていなかった必要がありました。
424 Authentication The server wants to authenticate [RFC6503] Required the request through the <subject> parameter but the parameter is not provided in the request.
424認証サーバーは、[RFC6503]を認証したい[RFC6503] <taxper>パラメーターを介して要求を必要としますが、パラメーターはリクエストでは提供されていません。
425 Forbidden Delete The conferencing system cannot [RFC6503] Parent delete the specific conference object because it is a parent for another conference object.
425 FORBIDDINED削除会議システムは、別の会議オブジェクトの親であるため、特定の会議オブジェクトを削除することはできません。
426 Forbidden Change The target conference object [RFC6503] Protected cannot be changed (e.g., due to policies, roles or privileges).
426禁止された変更ターゲット会議オブジェクト[RFC6503]保護された変更は変更できません（たとえば、ポリシー、役割、または特権のため）。
427 Invalid Domain Name The domain name in an [RFC6503] AUTO_GENERATE_X instance in the conference object is not within the conference server's domain of responsibility.
427無効なドメイン名[RFC6503]のドメイン名は、会議オブジェクトのAuto_Generate_Xインスタンスのインスタンスは、会議サーバーの責任ドメイン内にありません。
500 Server Internal The conference server experienced [RFC6503] Error some sort of internal error.
500サーバー内部会議サーバーが発生した[RFC6503]何らかの内部エラーが発生しました。
501 Not Implemented The specific operation is not [RFC6503] implemented on the conferencing system.
501実装されていない特定の操作は、会議システムに実装されていない[RFC6503]ではありません。
510 Request Timeout The request could not be [RFC6503] processed within a reasonable time (as specified by the conferencing system).
510リクエストタイムアウト合理的な時間内に（会議システムで指定されているように）リクエストを[RFC6503]処理できませんでした。
511 Resources Not The conference server cannot [RFC6503] Available execute a command because of resource issues, e.g., it cannot create a conference because the system has reached its limits on the number of conferences.
511レソース会議サーバーではない[RFC6503]利用可能なリソースの問題のためにコマンドを実行できます。たとえば、システムが会議の数に制限に達したため、会議を作成することはできません。
The authors appreciate the feedback provided by Dave Morgan, Pierre Tane, Lorenzo Miniero, Tobia Castaldi, Theo Zourzouvillys, Sean Duddy, Oscar Novo, Richard Barnes, Simo Veikkolainen, Keith Drage, Peter Reissner, Tony Lindstrom, Stephen Kent (secdir review), Brian Carpenter (genart review), and Mykyta Yevstifeyev (IANA considerations). Special thanks go to Roberta Presta for her invaluable contribution to this document. Roberta has worked on the specification of CCMP at the University of Napoli for the preparation of her Master thesis. She has also implemented the CCMP prototype used for the trials and from which the dumps provided in Section 6 have been extracted.
著者は、Dave Morgan、Pierre Tane、Lorenzo Miniero、Tobia Castaldi、Theo Zourzouvillys、Sean Duddy、Oscar Novo、Richard Barnes、Simo Veikkolainen、Keith Drage、Peter 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。、および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。、および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。、およびO. Levin、「集中会議のためのフレームワーク」、RFC 5239、2008年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「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。、および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.、および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。および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]フィールディング、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、2000。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML 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。、および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。および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。、およびK. Drage、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 4582、2006年11月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネット拒否権に関する考慮事項」、RFC 4732、2006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.
[RFC6502] Camarillo、G.、Srinivasan、S.、Even、R。、およびJ. Urpalainen、「集中会議（XCON）の会議イベントパッケージデータ形式拡張」、RFC 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.、A。Karmarkar、Soapバージョン1.2パート1：メッセージングフレームワーク（第2版） "、World Wide Web Consortiumの推奨REC-SOAP12-PART1-20070427、2007年4月、<http://www.w3.org/tr/2007/REC-SOAP12-PART1-20070427>。
[W3C.REC-soap12-part2-20070427] Moreau, J., Gudgin, M., Karmarkar, A., Mendelsohn, N., Hadley, M., Lafon, Y., and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
[W3C.REC-SOAP12-PART2-20070427] Moreau、J.、Gudgin、M.、Karmarkar、A.、Mendelsohn、N.、Hadley、M.、Lafon、Y.、およびH. Nielsen、SOAPバージョン1.2パート2：付属品（第2版）」、ワールドワイドウェブコンソーシアムの推奨REC-SOAP12-PART2-20070427、2007年4月、<http://www.w3.org/tr/2007/REC-SOAP12-PART2-20070427>。
Appendix A. Evaluation of Other Protocol Models and Transports Considered for CCMP
付録A. CCMPで考慮される他のプロトコルモデルとトランスポートの評価
This section provides some background as to the selection of HTTP as the transport for the CCMP requests/responses. In addition to HTTP, the operations on the objects can be implemented in at least two different ways, namely as remote procedure calls -- using SOAP as described in Appendix A.1 and by defining resources following a RESTful architecture Appendix A.2.
このセクションでは、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.
ただし、これらのアプローチはどちらも理想的ではありませんでした。石鹸は、追加のオーバーヘッドをもたらすと考えられていました。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 the CRUD approach, CCMP could use a general-purpose protocol such as HTTP [RFC2616] to transfer domain-specific XML-encoded data objects defined in the "Conference Information Data Model for Centralized Conferencing" [RFC6501].
CRUDアプローチに続いて、CCMPは、HTTP [RFC2616]などの汎用プロトコルを使用して、「集中会議のための会議情報データモデル」[RFC6501]で定義されたドメイン固有のXMLエンコードデータオブジェクトを転送できます。
Following on the CRUD approach, CCMP could follow the well-known REST (REpresentational State Transfer) architectural style [REST]. CCMP could map onto the REST philosophy, by specifying resource URIs, resource formats, methods supported at each URI and status codes that have to be returned when a certain method is invoked on a specific URI. A REST-style approach must ensure sure that all operations can be mapped to HTTP operations.
CRUDアプローチに続いて、CCMPはよく知られている休息（表現状態移転）建築スタイル[REST]に従うことができます。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