Network Working Group P. Koskelainen
Request for Comments: 4376 Nokia
Category: Informational J. Ott
Helsinki University of Technology
H. Schulzrinne
X. Wu
Columbia University
February 2006
Requirements for Floor Control Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.
フロア制御（マルチパーティ）会議環境内の共有リソースへの関節や排他的アクセスを管理するための手段です。そのような会議やメディアセッションのセットアップ、会議ポリシー操作、およびメディア制御など - - 他のプロトコルによって実現されている。これにより、フロア制御は、他の機能を補完します。この文書では、既存のフレームワークの文脈におけるマルチパーティ会議のフロア制御プロトコルのための要件を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Model ...........................................................4
5. Integration with Conferencing ...................................5
6. Assumptions about a Conference Policy ...........................6
7. Floor Control Protocol Requirements .............................7
7.1. Communication between Participant and Server ...............7
7.2. Communication between Chair and Server .....................9
7.3. General Protocol Requirements ..............................9
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Conference applications often have shared resources such as the right to talk, input access to a limited-bandwidth video channel, or a pointer or input focus in a shared application.
会議アプリケーションでは、多くの場合、そのような話をする権利、限られた帯域幅のビデオチャネルへの入力アクセス、または共有アプリケーション内のポインタや入力フォーカスなどのリソースを共有しています。
In many cases, it is desirable to be able to control who can provide input (send/write/control, depending on the application) to the shared resource.
多くの場合、共有リソースへの入力（送信/書き込み/制御、アプリケーションに依存して）提供することができるユーザーを制御できることが望ましいです。
Floor control enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. The floor is an individual temporary access or manipulation permission for a specific shared resource (or group of resources) [6].
フロア制御は、アプリケーションまたはユーザーが共有オブジェクトまたはリソースへの安全かつ相互に排他的又は非排他的な入力へのアクセスを得ることが可能となります。床は、[6]（リソースのグループ）特定の共有リソースに対する個々の一時的なアクセスまたは操作許可です。
Floor control is an optional feature for conferencing applications. SIP [2] conferencing applications may also decide not to support this feature at all. Two-party applications may use floor control outside conferencing, although the usefulness of this kind of scenario is limited. Floor control may be used together with the conference policy control protocol (CPCP) [7], or it may be used as an independent stand-alone protocol, e.g., with SIP but without CPCP.
フロア制御は、会議アプリケーションのためのオプション機能です。 SIPは、[2]会議アプリケーションはまた、すべてこの機能をサポートしないことを決定してもよいです。シナリオのこの種の有用性が限られているが、二つのパーティ製のアプリケーションは、会議の外にフロア制御を使用することができます。フロア制御は、[7]の会議ポリシー・コントロール・プロトコル（CPCP）と一緒に使用することができる、またはそれはSIPでなくCPCPことなく、例えば、独立したスタンドアロンプロトコルとして使用してもよいです。
Floor control has been studied extensively over the years (e.g., [8], [6], and [5]); therefore, earlier work can be leveraged here.
フロア制御は、長年にわたって広く研究されている（例えば、[8]、[6]、及び[5]）。そのため、以前の仕事はここに活用することができます。
The present document describes the requirements for a floor control protocol. As a requirements specification, the document makes no assumptions about the later implementation of the respective requirements as parts of one or more protocols or about the entities implementing them and their roles.
本書は、フロア制御プロトコルのための要件について説明します。要求仕様として、文書は、1つまたは複数のプロトコルの一部として、またはそれらとその役割を実装するエンティティに関するそれぞれの要件の後に実装を想定していません。
This document may be used in conjunction with other documents, such as the conferencing framework document [3]. In particular, when speaking about a floor control server, this entity may be identical to or co-located with the focus or a conference policy server defined in the framework document, while participants and floor chairs referred to in this specification may be regular participants as introduced in the conferencing framework document. In this specification, the term "floor control protocol" is used in an abstract sense and may ultimately be mapped to any of the existing conference control or other signaling protocols (including CPCP and SIP). However, defining those relationships is left to a concrete floor control protocol specification.
この文書では、そのような会議フレームワーク文献[3]のような他の文書と併せて使用することができます。フロア制御サーバについて話すとき、特に、このエンティティは、同一であってもよいし、フォーカスまたはフレームワーク文書で定義された会議ポリシーサーバと同じ場所に、本明細書で言及参加者とフロアチェアのような規則的な参加者であり得るが会議の枠組み文書に導入しました。本明細書において、用語「フロア制御プロトコルは、」抽象的意味で使用され、最終的に既存の会議制御又は（CPCPおよびSIPを含む）他のシグナリングプロトコルのいずれかにマッピングされてもよいです。しかし、それらの関係を定義する具体的なフロア制御プロトコル仕様に任されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
This document uses the definitions from [3].
この文書では、[3]から定義を使用しています。
The following additional definitions apply:
以下の追加の定義が適用されます。
Floor: A permission to access or manipulate a specific shared resource or set of resources temporarily.
床：特定の共有リソースまたは一時的にリソースのセットにアクセスしたり、操作する権限。
Conference owner: A privileged user who controls the conference, creates floors, and assigns and deassigns floor chairs. The conference owner does not have to be a member in a conference.
会議の所有者：会議を制御特権ユーザは、床、および譲受人との割り当てを解除階の椅子を作成します。会議の所有者は、会議のメンバーである必要はありません。
Floor chair: A user (or an entity) who manages one floor (grants, denies, or revokes a floor). The floor chair does not have to be a member in a conference.
フロアチェア：1階（助成金、拒否し、または床を取り消し）を管理するユーザ（またはエンティティ）。フロアの椅子は、会議のメンバーである必要はありません。
Floor control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource.
フロア制御：共有オブジェクトまたはリソースへの安全かつ相互に排他的又は非排他的な入力アクセスするアプリケーションまたはユーザを可能にするメカニズム。
Floor control server: A logical entity that maintains the state of the floor(s) including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server.
フロア制御サーバ：床を保持する床椅子が誰であるか、存在するフロアを含む床の状態を維持する論理エンティティ（単数または複数）、等の床を操作するための要求は、フロア制御サーバに向けられています。
Floor request set: A logical data structure holding all requests for a particular floor at a given point in time.
フロア要求セット：特定の時点で特定の床のためのすべての要求を保持する論理データ構造。
Floor holder set: A logical data structure identifying all participants who currently hold the floor.
フロアホルダーセット：現在の床を保持するすべての参加者を特定する論理データ構造。
The model for floor control is composed of three logical entities: a single floor control server, one or more floor chairs (moderators), and any number of regular conference participants.
単一フロア制御サーバ、一つ以上のフロアチェア（モデレーター）、および定期的な会議参加者の任意の数：フロア制御のためのモデルは、3つの論理エンティティで構成されています。
A floor control protocol is used to convey the floor control messages among the floor chairs (moderators) of the conference, the floor control server, and the participants of the conference. A centralized architecture is assumed in which all messages go via one point, the floor control server. Processing (granting or rejecting) floor control requests is done by the one or more floor chairs or by the server itself, depending on the policy.
フロア制御プロトコルは、会議のフロアチェア（モデレーター）、フロア制御サーバ、および会議の参加者の間でフロア制御メッセージを伝えるために使用されます。集中型アーキテクチャは、すべてのメッセージが一点、フロア制御サーバを経由すると想定されます。処理フロア制御要求を（許可または拒否）がポリシーに応じて、1つのまたは複数のフロアチェアまたはサーバー自体によって行われます。
Floor requests from the participants are received by the floor control server and kept (at the level of the floor control protocol) in a floor request set (i.e., are not ordered in any particular fashion). The current floor holders are reflected in a current floor holder set. Floor chairs are capable of manipulating both sets to grant, revoke, reject, and pass the floor (for example).
参加者からフロア要求がフロア要求セット内（フロア制御プロトコルのレベルで）フロア制御サーバによって受信され、維持される（すなわち、任意の特定の方法で順序付けられていません）。現在フロアホルダーは、現在のフロアホルダーセットに反映されます。フロアチェアは、許可取り消し、拒否、および（例えば）床を通過させるように両方のセットを操作することが可能です。
The order in which requests are processed, whether they are granted or rejected, and how many participants obtain a floor simultaneously are determined by a higher-layer application operating on these sets and are not confined by the floor control protocol.
要求は、それらが許可または拒否されるかどうか、処理され、そしてどのように多くの参加者が同時に発言権を得るが、これらのセット上で動作し、フロア制御プロトコルによって制限されていない上位層のアプリケーションによって決定される順序。
A floor is associated with one or more media sessions. The centralized conference server manages the floors and thus controls access to the media sessions. There are two aspects to this: 1) The server maintains and distributes consistent state information about who has a certain floor at a certain point in time and does so following some rule set. This provides all participants with the necessary information about who is allowed to speak (for example), but relies on a cooperative behavior among all participants. 2) In addition, to prevent individuals from ignoring the "hints" given by the floor control server, the latter may (e.g., in cooperation with other functional entities) enforce compliance with floor status, e.g., by blocking media streams from participants not entitled to speak. The floor control server controls the floors at least at the signaling level. In addition, actively controlling the actual (physical) media resources is highly recommended, but beyond the scope of this document.
床は、1つまたは複数のメディアセッションに関連付けられています。集中型の会議サーバは、床を管理し、したがって、メディアセッションへのアクセスを制御します。これには2つの側面があります：1）サーバーは、ある時点で一定の床を持っているので、いくつかのルールセットを、次のない者について一貫性のある状態情報を維持し、配布しています。これは、（例えば）話すことが許されるかについて、必要な情報をすべての参加者を提供していますが、すべての参加者間の協調行動に依存しています。 2）また、フロア制御サーバによって与えられた「ヒント」を無視してから、後者月の個人を防ぐために（例えば、他の機能エンティティと協力して）資格がない参加者からメディアストリームをブロックすることにより、床面の状態、例えば遵守を徹底話します。フロア制御サーバはシグナリング・レベルで少なくともフロアの制御を行います。また、積極的に実際の（物理的な）メディアリソースを制御することを強くお勧めしますが、この文書の範囲を超えています。
As noted in the introduction, an actual protocol specification fulfilling the requirements defined in this memo may map the components of the above model onto the conferencing components defined in the conferencing framework document. Some of these aspects are discussed briefly in the next section.
冒頭で述べたように、このメモで定義された要件を満たす実際のプロトコル仕様は、会議フレームワーク文書で定義された会議コンポーネントに上記のモデルの要素をマッピングすることができます。これらの側面のいくつかは、次のセクションで簡単に説明されています。
Floor control itself does not support privileges such as creating floors and appointing floor chairs and handing over chair privileges to other users (or taking them away). Instead, some external mechanism, such as conference management (e.g., CPCP or web interface for policy manipulation) is used for that.
フロアコントロール自体は、このような床を作成し、他のユーザーに椅子権限上階の椅子とハンドリングを任命（またはそれらを奪うこと）などの特権をサポートしていません。代わりに、そのような会議の管理（例えば、CPCPまたはポリシー操作のためのウェブインターフェース）のようないくつかの外部機構は、そのために使用されます。
The conference policy (and thus the conference owner or creator) defines whether floor control is in use or not. Actually enforcing conference media distribution in line with the respective media's floor status (e.g., controlling an audio bridge) is beyond the scope of this document. Floor control itself does not define media enforcement. It is up to the conference and media policies to define which media streams may be used in a conference and which ones are floor controlled.
会議ポリシー（したがって、会議の所有者または作成者）がフロア制御が使用中であるか否かを定義します。実際に（例えば、オーディオブリッジを制御する）各メディアのフロア状態に沿った会議メディア配信を強制することは、この文書の範囲外です。フロアコントロール自体は、メディアの執行を定義していません。これは、メディアストリームは、会議で使用されたものを床に制御されていることも定義するための会議やメディア政策次第です。
Typically, the conference owner creates the floor(s) using the conference policy control protocol (or some other mechanism) and appoints the floor chair. The conference owner can remove the floor anytime (so that a media session is not floor-controlled anymore) or change the floor chair or floor parameters.
典型的には、会議の所有者は、会議ポリシー・コントロール・プロトコル（またはいくつかの他のメカニズム）を使用して床（単数または複数）を作成し、床、椅子を任命します。会議の所有者は、（メディアセッションが床制御もはやないように）いつでも床を削除したり、床、椅子や床のパラメータを変更することができます。
The floor chair just controls the access to the floor(s), according to the conference policy.
フロアチェアはちょうど会議の方針によると、床（S）へのアクセスを制御します。
A floor control server is a separate logical entity, typically co-located with focus and/or conference policy server. Therefore, the floor control server can interact with the focus and conference policy server and media servers as needed. Communication mechanisms between the floor control server and other central conferencing entities are not within the scope of the floor control protocol requirements described in this document.
フロア制御サーバは、典型的には、フォーカス及び/又は会議ポリシーサーバと同じ場所に別の論理エンティティです。必要に応じてそのため、フロア制御サーバは、フォーカスと会議ポリシーサーバーとメディアサーバーとやり取りすることができます。フロア制御サーバや他の中央会議エンティティ間の通信メカニズムは、このドキュメントで説明するフロア制御プロトコル要件の範囲内ではありません。
Conferences may be cascaded, and hence a single participant in one conference may represent a second conference (called subconference). From a floor control perspective, there is no difference between a participant (identified by its URI) representing a single person or another (set of) subconference(s).
会議はカスケード接続することができ、したがって1回の会議中の単一の参加者は、（サブ会議と呼ばれる）第2の会議を表すことができます。フロア制御の観点から、一人又はサブ会議（S）他（のセット）を表す（そのURIによって識別された）参加者との間の違いはありません。
Note: In the latter case, it is the responsibility of the subconference to negotiate floor requests internally before passing on a request to the conference and to assign a floor internally upon receiving a floor grant. This may be done recursively by employing the floor control protocol with a different floor control server in the subconference.
注意：後者の場合、それは内部会議に要求を渡す前に、フロアの要求を交渉するために、床の助成金を受けて、内部の床を割り当てるためにサブ会議の責任です。これは、サブ会議における異なるフロア制御サーバとフロア制御プロトコルを使用することによって再帰的に行われてもよいです。
The floor control protocol is supposed to be used to manage access to shared resources in the context of a conference. It is up to this conference -- more precisely, its conference policy [4] -- to define the rules for the operation of the floor control protocol. Furthermore, a conference policy control protocol [4] may define mechanisms that alter those rules during the course of a conference. This section briefly outlines the assumptions made by a floor control protocol about the conference policy and means for its modification.
フロア制御プロトコルは、会議のコンテキストで共有リソースへのアクセスを管理するために使用されることを想定しています。この会議までである - より正確には、その会議ポリシー[4] - フロア制御プロトコルの動作のための規則を定義します。また、会議ポリシー制御プロトコル[4]会議の過程中にこれらのルールを変更する機構を定義することができます。このセクションでは、簡単にその修正のための会議ポリシーおよび手段に関するフロア制御プロトコルによって行われた仮定の概要を説明します。
The conference policy is expected to define the rules for floor control, which implies in particular that it is not the responsibility of the floor control protocol to establish or communicate those rules.
会議ポリシーは、これらの規則を確立したり通信するフロア制御プロトコルの責任ではないことを特に意味フロア制御、のルールを定義することが期待されます。
In general, it is assumed that the conference policy also defines who is allowed to create, change, and remove a floor in a conference.
一般的には、会議ポリシーはまた、作成、変更、および会議に床を削除するために許可されているユーザーを定義するものとします。
Conference participants and floor chairs should be able to get and set floor-related parameters. The conference policy may restrict who may access or alter which parameters. Note that not all parameters maintained for a floor are also interpreted by the floor control protocol (e.g., floor policy descriptions may be stored associated with a floor but may be interpreted by a higher-layer application). Note also that changes to the floor control policy are outside the scope of the floor control protocol and are (for example) to be carried out by a conference policy control protocol.
会議の参加者とフロアの椅子は床に関連するパラメータを取得および設定することができるはずです。会議ポリシーは、どのパラメータにアクセスしたり、変更することがあり、誰制限することができます。床のために維持されていないすべてのパラメータはまた、フロア制御プロトコルによって解釈されることに留意されたい（例えば、床ポリシー記述は、床に関連付けられた格納されてもよいが、上位層のアプリケーションによって解釈することができます）。フロア制御ポリシーの変更にも注意がフロア制御プロトコルの範囲外であり、会議ポリシー・コントロール・プロトコルにより実行させる（例えば、）です。
(For example, it may be useful to see who the floor chair is, what kind of policy is in use, time limits, number of simultaneous floor holders, and current floor holder.)
（例えば、それは床の椅子が誰であるかを確認するために有用である可能性がある、同時フロア所有者の使用、時間制限、番号、および現在の床ホルダーにどのような政策のです。）
The following requirements on a conference policy related to floor control are identified in [4]:
フロア制御に関連する会議ポリシーに関する以下の要件は、[4]において同定されます。
REQ-F1: It MUST be possible to define whether floor control is in use or not.
REQ-F1：フロア制御が使用中であるか否かを定義することが可能でなければなりません。
REQ-F2: It MUST be possible to define the algorithm to be used in granting the floor. (Note: Examples of algorithms are moderator-controlled, FCFS, or random.)
REQ-F2：それは床を付与に使用されるアルゴリズムを定義することが可能でなければなりません。 （注：アルゴリズムの例は、モデレータ制御、FCFS、又はランダムです。）
Note: It must be possible to use an automated floor policy where the floor control server decides autonomously about granting and rejecting floor requests as well as revoking the floor. It must also be possible to use a chair-controlled floor policy in which the floor control server notifies the floor chair and waits for the chair to make a decision. This enables the chair to fully control who has the floor. The server MAY forward all requests immediately to the floor chair, or it may do filtering and send only occasional notifications to the chair.
注意：フロア制御サーバが付与およびフロア要求を拒否だけでなく、床を取り消すについて自律的に決定し、自動床ポリシーを使用することが可能でなければなりません。また、フロア制御サーバは、フロアチェアを通知し、意思決定を行うために椅子を待っている椅子制御床ポリシーを使用することが可能でなければなりません。これは完全に床を持っているユーザーを制御するために椅子を可能にします。サーバーは、床、椅子にすぐにすべての要求を転送することができる、またはそれは、フィルタリングを行うと、椅子にのみ不定期の通知を送信することができます。
REQ-F3: It MUST be possible to define how many users can have the floor at the same time.
REQ-F3：それは多くのユーザーが同時に床を持つことができる方法を定義することは可能でなければなりません。
REQ-F4: It MUST be possible to have one floor for one or more media types.
REQ-F4：それは、1つまたは複数のメディアタイプのための1階を持つことが可能でなければなりません。
REQ-F5: It MUST be possible to have multiple floors in a conference.
REQ-F5：会議に複数のフロアを持つことが可能でなければなりません。
REQ-F6: It MUST be possible to define whether a floor is moderator-controlled or not.
REQ-F6：それは床がモデレータ制御であるかどうかを定義することが可能でなければなりません。
REQ-F7: If the floor is moderator-controlled, it MUST be possible to assign and replace the floor moderator.
REQ-F7：床が司会制御されている場合、床のモデレータを割り当てると交換することが可能でなければなりません。
This section covers the requirements on a floor control protocol. The requirements are grouped as follows: 1) floor control protocol between participant and server; 2) floor control protocol between floor chairs and server; 3) floor control server management; and 4) general protocol requirements.
このセクションでは、フロア制御プロトコル上の要件をカバーしています。次のような要件は、グループ化されている：参加者とサーバとの間の1）フロア制御プロトコル。フロアチェアとサーバとの間の2）フロア制御プロトコル。 3）フロア制御サーバ管理。 4）一般的なプロトコル要件。
REQ-PS-1: Participants MUST be able to request (claim) a floor.
REQ-PS-1：参加者（請求項）フロアを要求することができなければなりません。
REQ-PS-2: It SHOULD be possible for a participant requesting a floor to give additional information about the request, such as the topic of the question for an audio floor. Note: In some scenarios, the floor control server or the floor chair may use this information when granting the floor to the user, or when manipulating the floor sets at the server.
REQ-PS-2：それは、このようなオーディオ床のための質問のトピックとして要求に関する追加情報を提供するためにフロアを要求参加者のために可能なはずです。注：ユーザーに床を付与する場合、またはサーバーで床セットを操作するときにいくつかのシナリオでは、フロア制御サーバや床の椅子は、この情報を使用することができます。
REQ-PS-3: It MUST be possible for a participant to modify (e.g., cancel) a previously placed floor request.
REQ-PS-3：参加者が変更することが可能でなければなりません（例えば、キャンセル）以前に配置されたフロア要求を。
REQ-PS-4: It SHOULD be possible for a participant to initiate a floor control operation (e.g., floor request, release) on behalf of another participant (third-party floor control) provided that he is authorized to do so.
REQ-PS-4：それは別の参加者（サードパーティ製のフロア制御）に代わって、フロア制御動作（例えば、フロア要求、リリース）を開始する参加者のために可能なはずですが、彼がそうすることを許可されていることを提供します。
REQ-PS-5: A participant MUST be informed that she has been granted the floor.
REQ-PS-5：参加者は、彼女が床に付与されていることを知らされなければなりません。
REQ-PS-6: A participant MUST be informed that his floor request has been rejected.
REQ-PS-6：参加者は彼のフロア要求が拒否されたことを通知しなければなりません。
REQ-PS-7: A participant MUST be informed that the floor was revoked from her.
REQ-PS-7：参加者は、床が彼女から取り消されたことを通知しなければなりません。
REQ-PS-8: A participant SHOULD be informed that her floor request is pending and will be processed later.
REQ-PS-8：参加者は、彼女のフロア要求が保留され、後で処理されることを知らされるべきです。
REQ-PS-9: A floor holder MUST be able to release a floor.
REQ-PS-9：フロアホルダーが床を解放できなければなりません。
REQ-PS-10: It MUST be possible to notify conference participants of (changes to) the floor holder(s).
REQ-PS-10：これは、床ホルダー（S）（変更）の会議参加者に通知することができなければなりません。
REQ-PS-11: It MUST be possible to notify conference participants when a new floor request is being made.
REQ-PS-11：新しいフロア要求がなされているときの会議参加者を通知することが可能でなければなりません。
REQ-PS-12: It MUST be possible for a floor requester to request privacy for claiming the floor.
REQ-PS-12：フロア要求者が床を主張するために、プライバシーを要求することが可能でなければなりません。
anonymous: The participants (including the floor chair) cannot
see the floor requester's identity. The floor chairs grant the
floor based on the claim id and the topic of the claim.
known to the floor chair: Only the floor chair is able to see the floor requester's identity; all other participants do not obtain this information.
フロアの椅子に知られている：だけフロアチェアフロア要求者の身元を確認することができます。他のすべての参加者は、この情報を得ることはありません。
public: All the participants can see the floor requester's identity.
パブリック：すべての参加者は、フロア要求者の身元を確認することができます。
REQ-PS-13: It MUST be possible for a participant to request privacy for holding the floor along with a floor request. Note that identity information about the participant may become available to others through different means (e.g., application/media protocols or the media itself such as the voice).
REQ-PS-13：参加者がフロア要求と一緒に床を保持するため、プライバシーを要求することが可能でなければなりません。参加者について、その識別情報が異なる手段を介して（例えば、アプリケーション/メディアプロトコルや音声などのメディア自体）他人に利用可能になることがあります。
REQ-CS-1: It MUST be possible to inform the floor chairs, if present, about a participant's floor request.
REQ-CS-1：それが存在する場合、参加者のフロア要求について、フロアチェアを知らせることが可能でなければなりません。
It SHOULD be possible to convey additional information the participant may have provided along with her request.
参加者が自分の要求に沿って設けられていることがあり、追加の情報を伝えることが可能であるべきです。
It MUST be possible to hide the requesting participant's identity from the chair, i.e., not to include this identity information in the floor request.
すなわち、フロア要求では、この識別情報を含まない、椅子から要求する参加者の身元を隠すことができなければなりません。
REQ-CS-2: It MUST be possible to grant a floor to a participant.
REQ-CS-2：それは参加者に床を付与することは可能でなければなりません。
REQ-CS-3: It MUST be possible to reject a participant's floor request.
REQ-CS-3：それは参加者のフロア要求を拒否することも可能でなければなりません。
REQ-CS-4: The floor chair MUST be able to revoke a floor from (one of) its current holder(s). Note that the floor chair may also remove pending floor requests from the request set (by rejecting them).
REQ-CS-4：フロアの椅子は、その現在の所有者（の1つ）（S）からフロアを取り消すことができなければなりません。フロアチェアも（それらを拒否することによって）要求セットからの保留床の要求を削除することがあります。
REQ-CS-5: It MUST be possible to notify floor chairs about changes to the floor holder(s).
REQ-CS-5：それは、床ホルダー（S）への変更については、フロアチェアを通知することが可能でなければなりません。
REQ-CS-6: There SHOULD be operations to manipulate the request set available for floor chair(s). Such a request set SHOULD at least include creating, maintaining, and re-ordering floor requests in a queue and clearing the floor control queue.
REQ-CS-6：フロアチェア（S）のために利用できる設定要求を操作するための操作がなければなりません。このような要求セットは、少なくとも、作成、保守、およびキューで再注文フロア要求とフロア制御キューをクリア含むべきです。
REQ-CS-7: It MUST be possible to hide the identity of a floor chair from a subset or all participants of a conference.
REQ-CS-7：それはサブセットから床椅子のアイデンティティや会議のすべての参加者を非表示にすることも可能でなければなりません。
REQ-CS-8: It MUST be possible for a newly assigned floor chair to learn (e.g., inquire) about the existing floor request set.
REQ-CS-8：新しく割り当てられたフロアチェア（例えば、問い合わせ）は、既存のフロア要求セットについて学ぶすることが可能でなければなりません。
REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments.
REQ-GEN-1：帯域幅と端末制限を効率的にモバイル環境で使用することができるフロア制御を確保するために考慮されるべきです。
Note that efficient communication by means of minimal-sized messages may contradict the desire to express reasons for requesting a floor along with other information. Therefore, a floor control protocol SHOULD be designed in a way that it allows for expressive as well as minimal messaging, as a (negotiable) configuration option and/or selectable on a per-message basis.
最小サイズのメッセージを用いて効率的な通信を他の情報と一緒にフロアを要求する理由を表現したいという要望と矛盾してもよいことに留意されたいです。したがって、フロア制御プロトコルは、メッセージごとに（交渉）設定オプションおよび/または選択可能なように、表現だけでなく、最小のメッセージングを可能にするような方法で設計されるべきです。
REQ-GEN-2: The floor control MUST be a reliable client-server protocol. Hence, it MUST provide a positive response indicating that a request has been received or an error response if an error has occurred.
REQ-GEN-2：フロア制御は、信頼性の高いクライアントサーバプロトコルでなければなりません。したがって、要求が受信されたことを示す肯定応答またはエラーが発生した場合、エラー応答を提供しなければなりません。
REQ-GEN-3: It MUST be possible for the floor control server to authenticate participants and chairs.
REQ-GEN-3：フロア制御サーバは、参加者と椅子を認証することが可能でなければなりません。
REQ-GEN-4: It MUST be possible for the participants and chairs to authenticate the server.
REQ-GEN-4：参加者と椅子がサーバを認証することが可能でなければなりません。
REQ-GEN-5: It MUST be possible to ensure message integrity between participants and chairs and the floor control server.
REQ-GEN-5：それは、参加者と椅子や床の制御サーバ間のメッセージの整合性を確保することが可能でなければなりません。
REQ-GEN-6: It MUST be possible to ensure the privacy of messages exchanged between participants and chairs and the floor control server.
REQ-GEN-6：参加者と椅子や床の制御サーバ間で交換されるメッセージのプライバシーを確保することが可能でなければなりません。
Floor control messages are exchanged on one hand between regular participants and the floor control server and on the other hand between the floor control server and the floor chair(s).
フロア制御メッセージは、通常の参加者とフロア制御サーバ間やフロア制御サーバとフロアチェア（S）との間に他方で交換されます。
If enabled, floor control mechanisms are used to control who may contribute to a conference in arbitrary ways (speak, be seen, write, etc., as supported by the conferencing applications). It is important that floor control messages be protected because otherwise an attacker could prevent participants from being "heard" in the conference (e.g., in scenarios where silence is considered consent) or make participants be heard in a conference without their knowledge (e.g., eavesdropping on the participant's microphone). Such considerations are particularly relevant when floor control is used in conjunction with one or more (central) entities (e.g., a media mixer) controlled by the floor control server to enforce floor control decisions that may allow an attacker to "mute" a participant completely.
有効にした場合、フロア制御機構は、任意の方法（会議アプリケーションでサポートされているように、など、書く、見ること、話す）での会議に寄与することができるユーザーを制御するために使用されています。そうでない場合、攻撃者は（沈黙は同意とみなされているシナリオでは、例えば）の会議で、「聞いた」されることから、参加者を防ぐか、参加者が自分の知識がなくても会議に聞くことが作ることができるので、例えば、盗聴（フロア制御メッセージを保護することが重要です参加者のマイクに）。フロア制御は、攻撃者が、完全参加者を「ミュート」することを可能にし得るフロア制御決定を強制するフロア制御サーバによって制御される1つ又はそれ以上の（中央）のエンティティ（例えば、メディアミキサ）と組み合わせて使用される場合、このような考慮事項は特に関連しています。
Communications between a conference participant and the floor control server are vulnerable to all kinds of masquerading attacks. If an attacker can spoof the identity of the participant or inject messages on his behalf, it may generate floor requests (e.g., floor release) and prevent proper participation of the participant. If an attacker can inject messages to the participant, it may generate arbitrary responses and false status information. If an attacker can impersonate the floor control server, a participant's requests may never reach the actual floor control server. If an attacker can intercept either side's messages (and hence become a man in the middle (MITM)), it may suppress, alter, or inject messages and thus manipulate a participant's view of the conference floor status as well as the floor control server's view of a participant.
会議参加者とフロア制御サーバ間の通信は、マスカレード攻撃のすべての種類に対して脆弱です。攻撃者は、参加者の身元を詐称や彼の代わりにメッセージを注入することができた場合、それは床の要求（例えば、床のリリース）を生成し、参加者の適切な参加を妨げることがあります。攻撃者は、参加者にメッセージを注入することができた場合、それは任意回答と偽のステータス情報を生成してもよいです。攻撃者は、フロア制御サーバを偽装することができた場合は、参加者の要求は、実際のフロア制御サーバに到達しないことがあります。攻撃者がいずれかの側のメッセージを傍受（ひいては中間（MITM）で人になる）ことができれば、それは、抑制変更、またはメッセージを注入し、従って会議床状態の参加者のビューと同様にフロア制御サーバのビューを操作することができます参加者の。
Similar considerations apply to the communications between the floor control server and the floor chair(s). If an attacker can intercept messages from either side, it may defer or prevent responses to floor control requests (from a particular floor chair). If it can inject messages (particularly in the direction from the floor chair to the floor control server), it may steer the assignment of conference floors. If interception and injection is possible (man-in-the-middle scenario), an attacker can create an arbitrary image of the conference for the floor chair. If an attacker can impersonate a floor chair, it may rule the conference floor assignment (if there is only a single chair) or disrupt the conference course by means of arbitrary and potentially conflicting requests/responses/assignments (if there are multiple floor chairs). In the latter case, the amount of damage a single attacker can do depends on the floor control policy.
同様の考察は、フロア制御サーバとフロアチェア（S）との間の通信に適用されます。攻撃者はどちらの側からのメッセージを傍受することができれば、それは延期したり（特に床椅子から）フロア制御要求に対する応答を防ぎます。それは（特にフロア制御サーバへ、フロア椅子から離れる方向に）メッセージを注入することができれば、それは、会議フロアの割り当てを操縦することができます。傍受や注射は（のman-in-the-middleシナリオ）が可能である場合、攻撃者は、フロアチェアのために会議の任意の画像を作成することができます。攻撃者は、フロアチェアを偽装することができた場合（つだけの椅子があれば）、それは会議の床の割り当てを支配するか（複数階の椅子がある場合）は、任意の、潜在的に相反する要求/応答/割り当てによる会議のコースを混乱させる。後者の場合、単一の攻撃者が行うことができるダメージの量は、フロア制御ポリシーに依存します。
Finally, attackers may eavesdrop on the floor control communications and learn which participants are present, how active they are, who are the floor chairs, etc.
最後に、攻撃者は、フロア制御通信を盗聴し、彼らはなど、フロアチェア、誰であるか、どのようにアクティブに、存在している参加者を学ぶこと
To mitigate the above threats, conference participants, floor control servers, and floor chairs SHOULD be authenticated upon initial contact. All floor control messages SHOULD be authenticated and integrity-protected to prevent third-party intervention and MITM attacks. Floor control messages SHOULD be encrypted to prevent eavesdropping.
上記の脅威、会議参加者、フロア制御サーバを緩和するために、床の椅子は、最初の接触時に認証されるべきです。すべてのフロア制御メッセージは、サードパーティの介入とMITM攻撃を防止するために、認証および整合性保護されなければなりません。フロア制御メッセージは、盗聴を防ぐために暗号化されるべきです。
The authors would like to thank IETF conferencing design team and Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, and Nermeen Ismail for their feedback.
著者は彼らのフィードバックのためのIETF会議デザインチームとキース糖剤、マーカスブルンナー、サンジョイセン、エリック・バーガー、ブライアン・ローゼン、およびNermeenイスマイルに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997.
[1]ブラドナーのは、S.は、RFC 2119、BCD 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[3]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[4] Koskelainen, P. and H. Khartabil, "Additional Requirements to Conferencing", Work in Progress, August 2004.
[4] Koskelainen、P.とH. Khartabil、 "会議への追加要件"、進歩、2004年8月での作業。
[5] Koskelainen, P., Schulzrinne, H., and X. Wu, "A SIP-based conference control framework", NOSSDAV 2002, Miami Beach, May 2002.
[5] Koskelainen、P.、Schulzrinneと、H.、およびX.呉、 "SIPベースの会議制御フレームワーク"、NOSSDAV 2002、マイアミビーチ、2002年5月。
[6] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for activity coordination in networked multimedia applications", Proc. of 2nd Asian-pacific Conference on Communications APPC, Osaka Japan, June 1995.
[6] Dommel、H.及びJ.ガルシア - ルナ - ACEVES、「ネットワークマルチメディアアプリケーションにおけるアクティビティの調整のためのフロア制御」、PROC。コミュニケーションAPPC、大阪、日本、1995年6月に第2回アジア太平洋会議の。
[7] Koskelainen, P., Khartabil, H., and A. Niemi, "The Conference Policy Control Protocol (CPCP)", Work in Progress, October 2004.
[7] Koskelainen、P.、Khartabil、H.、およびA.ニエミ、 "会議ポリシー制御プロトコル（CPCP）"、進歩、2004年10月に作業。
[8] Borman, C., Kutscher, D., Ott, J., and D. Trossen, "Simple conference control protocol service specification", Work in Progress, March 2001.
進歩、2001年3月[8]ボーマン、C.、Kutscher、D.、オット、J.、およびD. Trossen、 "単純な会議制御プロトコルサービス仕様"、ワーク。
Authors' Addresses
著者のアドレス
Petri Koskelainen Nokia 102 Corporate Park Drive White Plains, NY 10604 USA
ペトリKoskelainenノキア102コーポレートパークドライブホワイトプレーンズ、NY 10604 USA
EMail: petri.koskelainen@nokia.com
メールアドレス：petri.koskelainen@nokia.com
Joerg Ott Helsinki University of Technology Networking Laboratory Otakaari 5A 02150 Espoo Finland
テクノロジーのイェルクオットヘルシンキ大学・ネットワーキング研究所Otakaari 5A 02150エスポーフィンランド
EMail: jo@netlab.hut.fi
メールアドレス：jo@netlab.hut.fi
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York 10027 USA
ヘニングSchulzrinneとコロンビア大学1214アムステルダムアベニューニューヨーク10027 USA
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu
Xiaotao Wu Columbia University 1214 Amsterdam Avenue New York 10027 USA
ξAOディアンW Uコロンビア大学1214年アムステルダムアベニューニューヨーク10027 USA
EMail: xiaotaow@cs.columbia.edu
メールアドレス：xiaotaow@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。