Network Working Group G. Camarillo
Request for Comments: 4582 Ericsson
Category: Standards Track J. Ott
Helsinki University of Technology
K. Drage
Lucent Technologies
November 2006
The Binary Floor Control Protocol (BFCP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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 specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
この文書では、バイナリフロア制御プロトコル（BFCP）を指定します。 BFCPは、床の参加者とフロア制御サーバとの間の、及び床椅子（すなわち、モデレータ）とフロア制御サーバとの間で使用されています。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Scope ...........................................................5
3.1. Floor Creation .............................................7
3.2. Obtaining Information to Contact a Floor Control Server ....7
3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control ................................8
4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface ........8
4.2. Floor Chair to Floor Control Server Interface .............13
5. Packet Format ..................................................14
5.1. COMMON-HEADER Format ......................................15
5.2. Attribute Format ..........................................16
5.2.1. BENEFICIARY-ID .....................................18
5.2.2. FLOOR-ID ...........................................18
5.2.3. FLOOR-REQUEST-ID ...................................19
5.2.4. PRIORITY ...........................................19
5.2.5. REQUEST-STATUS .....................................20
5.2.6. ERROR-CODE .........................................21
5.2.6.1. Error-Specific Details for Error Code 4 ...22
5.2.7. ERROR-INFO .........................................22
5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
5.2.9. STATUS-INFO ........................................24
5.2.10. SUPPORTED-ATTRIBUTES ..............................24
5.2.11. SUPPORTED-PRIMITIVES ..............................25
5.2.12. USER-DISPLAY-NAME .................................26
5.2.13. USER-URI ..........................................26
5.2.14. BENEFICIARY-INFORMATION ...........................27
5.2.15. FLOOR-REQUEST-INFORMATION .........................27
5.2.16. REQUESTED-BY-INFORMATION ..........................28
5.2.17. FLOOR-REQUEST-STATUS .............................29
5.2.18. OVERALL-REQUEST-STATUS ...........................30
5.3. Message Format ............................................30
5.3.1. FloorRequest .......................................31
5.3.2. FloorRelease .......................................31
5.3.3. FloorRequestQuery ..................................31
5.3.4. FloorRequestStatus .................................31
5.3.5. UserQuery ..........................................32
5.3.6. UserStatus .........................................32
5.3.7. FloorQuery .........................................32
5.3.8. FloorStatus ........................................33
5.3.9. ChairAction ........................................33
5.3.10. ChairActionAck ....................................33
5.3.11. Hello .............................................33
5.3.12. HelloAck ..........................................34
5.3.13. Error .............................................34
6. Transport ......................................................34
7. Lower-Layer Security ...........................................35
8. Protocol Transactions ..........................................35
8.1. Client Behavior ...........................................36
8.2. Server Behavior ...........................................36
9. Authentication and Authorization ...............................36
9.1. TLS-Based Mutual Authentication ...........................37
10. Floor Participant Operations ..................................37
10.1. Requesting a Floor .......................................37
10.1.1. Sending a FloorRequest Message ....................38
10.1.2. Receiving a Response ..............................38
10.2. Cancelling a Floor Request and Releasing a Floor .........40
10.2.1. Sending a FloorRelease Message ....................40
10.2.2. Receiving a Response ..............................40
11. Chair Operations ..............................................41
11.1. Sending a ChairAction Message ............................41
11.2. Receiving a Response .....................................42
12. General Client Operations .....................................43
12.1. Requesting Information about Floors ......................43
12.1.1. Sending a FloorQuery Message ......................43
12.1.2. Receiving a Response ..............................43
12.2. Requesting Information about Floor Requests ..............44
12.2.1. Sending a FloorRequestQuery Message ...............45
12.2.2. Receiving a Response ..............................45
12.3. Requesting Information about a User ......................45
12.3.1. Sending a UserQuery Message .......................46
12.3.2. Receiving a Response ..............................46
12.4. Obtaining the Capabilities of a Floor Control Server .....46
12.4.1. Sending a Hello Message ...........................47
12.4.2. Receiving Responses ...............................47
13. Floor Control Server Operations ...............................47
13.1. Reception of a FloorRequest Message ......................48
13.1.1. Generating the First FloorRequestStatus Message ...48
13.1.2. Generation of Subsequent
FloorRequestStatus Messages .......................50
13.2. Reception of a FloorRequestQuery Message .................51
13.3. Reception of a UserQuery Message .........................52
13.4. Reception of a FloorRelease Message ......................53
13.5. Reception of a FloorQuery Message ........................54
13.5.1. Generation of the First FloorStatus Message .......55
13.5.2. Generation of Subsequent FloorStatus Messages .....56
13.6. Reception of a ChairAction Message .......................56
13.7. Reception of a Hello Message .............................57
13.8. Error Message Generation .................................58
14. Security Considerations .......................................58
15. IANA Considerations ...........................................59
15.1. Attribute Subregistry ....................................59
15.2. Primitive Subregistry ....................................60
15.3. Request Status Subregistry ...............................61
15.4. Error Code Subregistry ...................................62
16. Acknowledgements ..............................................62
17. References ....................................................63
17.1. Normative References .....................................63
17.2. Informational References .................................63
Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources.
会議の中で、いくつかのアプリケーションは、このような特定のメディアセッションにメディアを送信する権利などの共有リソースのセットへのアクセスを管理する必要があります。フロアコントロールは、これらのリソースへの協調（共有または排他）アクセスをユーザーに提供するために、このようなアプリケーションを可能にします。
The Requirements for Floor Control Protocol [9] list a set of requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements.
フロア制御プロトコルのための要件は、[9]フロア制御プロトコルによって満たされる必要がある一連の要件をリストします。この文書で指定されたバイナリフロア制御プロトコル（BFCP）は、これらの要件を満たしています。
In addition, BFCP has been designed so that it can be used in low-bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way.
それは、低帯域幅の環境で使用することができるように加えて、BFCPは設計されています。 BFCPによって使用されるバイナリエンコーディングは、それが最小に遅延に敏感BFCPメッセージを送信するのに要する時間を保持する（メッセージの署名が使用されていない）小さなメッセージサイズを達成します。遅延に敏感なBFCPメッセージはFloorRequest、FloorRelease、FloorRequestStatus、およびChairActionが含まれます。これらのメッセージへの将来の拡張は重要な方法でこれらのメッセージのサイズを大きくしないことが予想されます。
The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation, and subsequent sections provide the normative specification of BFCP.
第2節では、第4、第3 BFCPの範囲（すなわち、タスクはBFCPの範囲内に入るとそのものは、異なるメカニズムを使用して行われる）を説明し、本文書全体を通して使用される用語を定義する：以下のように、この文書の残りの部分は、編成されBFCP動作の非規範的な概要を提供し、それ以降のセクションでは、BFCPの規範的な仕様を提供します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor-controlled conferences, a given media participant is typically colocated with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. The protocol between a floor participant and a media participant (that are not colocated) is outside the scope of this document.
メディア参加者：会議のメディアリソースへのアクセスがあるエンティティ（例えば、それがメディアストリームを受信することができます）。フロア制御の会議では、与えられたメディアの参加者は、一般的に、フロアの参加者と同じ場所に配置されたが、それはする必要はありません。サードパーティ製のフロア要求は、彼らが同じ場所に配置されないときに、メディアの参加者のためのフロア参加要求の床を持つから構成されています。フロア参加者と（同じ場所に配置されていない）メディア参加者間のプロトコルは、この文書の範囲外です。
Client: A floor participant or a floor chair that communicates with a floor control server using BFCP.
クライアント：フロア参加者やBFCPを使用して、フロア制御サーバと通信し、フロアチェア。
Floor: A temporary permission to access or manipulate a specific shared resource or set of resources.
床：特定の共有リソースまたはリソースのセットにアクセスしたり、操作するための一時的な許可。
Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8.
フロアチェア：1階（助成金、拒否し、または床を取り消し）を管理する論理エンティティ。特定のトランザクションのためのフロアチェアの論理的な役割を担っているエンティティは、別のトランザクションのためのさまざまな役割（例えば、フロア参加者を）取ることができます。フロアチェアとフロア参加者の役割は、トランザクションごとに定義されています。 BFCP取引はセクション8で定義されています。
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. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference.
フロア制御サーバ：床を保持する床椅子が誰であるか、存在するフロアを含む、床（S）の状態を維持する論理エンティティ、など床を操作するための要求は、フロア制御サーバに向けられています。会議のフロア制御サーバは、別の会議に他の論理ロール（例えば、フロア参加者）を実行してもよいです。
Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically colocated with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated.
フロアの参加者：フロア制御サーバから、それらについておそらく情報を床を要求し、論理的なエンティティ。特定のトランザクションのためのフロア参加者の論理的な役割を担っているエンティティは、別のトランザクションのためのさまざまな役割（例えば、フロアチェア）を仮定してもよいです。フロアの参加者とフロアチェアの役割は、トランザクションごとに定義されています。 BFCP取引は、フロア制御の会議では、第8章で定義されている、与えられたフロアの参加者は、一般的に、メディアの参加者と同じ場所に配置されたが、それはする必要はありません。サードパーティ製のフロア要求は、彼らが同じ場所に配置されないときに、メディアの参加者のためのフロア参加要求の床を持つから構成されています。
Participant: An entity that acts as a floor participant, as a media participant, or as both.
参加者：メディア参加者として、あるいは両方として、フロアの参加者として動作するエンティティ。
As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [9]. Floor control complements other functions defined in the XCON conferencing framework [10]. The floor control protocol BFCP defined in this document only specifies a means to arbitrate access to floors. The rules and constraints for floor arbitration and the results of floor assignments are outside the scope of this document and are defined by other protocols [10].
先に述べたように、BFCP [9]で定義された要件を、以下の会議に共有リソースへのアクセスを調整するためのプロトコルです。フロア制御はXCON会議フレームワーク[10]で定義された他の機能を補完します。この文書で定義されたフロア制御プロトコルBFCPは唯一の階へのアクセスを調停するための手段を指定します。フロア調停と床割り当ての結果のための規則及び制約は、この文書の範囲外であり、他のプロトコル[10]によって定義されます。
Figure 1 shows the tasks that BFCP can perform.
図1は、BFCPが実行できるタスクを示しています。
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
Figure 1: Functionality provided by BFCP
図1：機能BFCPによって提供さ
BFCP provides a means:
BFCPは手段を提供します。
o for floor participants to send floor requests to floor control servers.
フロアの参加者のためのoはフロア制御サーバへのフロア要求を送信します。
o for floor control servers to grant or deny requests to access a given resource from floor participants.
フロア制御サーバは、フロアの参加者から与えられたリソースにアクセスするための要求を許可または拒否するためのO。
o for floor chairs to send floor control servers decisions regarding floor requests.
フロアチェアフロア要求に関するフロア制御サーバの決定を送信するために、O。
o for floor control servers to keep floor participants and floor chairs informed about the status of a given floor or a given floor request.
フロア制御サーバ用のOは、与えられた床の状態や与えられたフロア要求について知らさフロア参加者とフロアの椅子を維持します。
Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them.
前のリストに属していないタスクがBFCPの範囲外であるにもかかわらず、これらの範囲外のタスクの一部は、フロア制御に関連し、床を作成し、異なるエンティティ間のBFCP接続を確立するために不可欠です。以下のサブセクションでは、我々はそれらを実行するために、これらのタスクとメカニズムのいくつかを議論します。
The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [10]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created).
[10]に記載されているようにリソースまたはリソースのセット（例えば、メディア・ストリーム）を有する所与のフロアの関連はBFCPの範囲外です。床の作成と終了はBFCPの範囲外でもあります。これらの側面は、会議オブジェクトを操作するための会議制御プロトコルを使用して処理されます。その結果、フロア制御サーバは、会議のオブジェクト（例えば、新しい床が作成されたとき）への変更日まで滞在する必要があります。
A client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and a user identifier.
クライアントは、フロア制御サーバへBFCP接続を確立するために、データのセットを必要とします。これらのデータは、サーバーのトランスポート・アドレス、会議識別子、及びユーザ識別子が含まれます。
Clients can obtain this information in different ways. One is to use an SDP offer/answer [8] exchange, which is described in [7]. Other mechanisms are described in the XCON framework [10] (and other related documents).
クライアントは、さまざまな方法でこの情報を取得することができます。一つは、[7]に記載されているSDPオファー/アンサー[8]の交換を使用することです。他の機構は、XCONフレームワーク[10]（及び他の関連文書）に記載されています。
Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object.
床には、リソースに関連付けられています。例えば、特定の時間に話を誰制御し、床は、関連するリソースなど、特定のオーディオセッションを持っています。床やリソース間の関連付けは、会議オブジェクトの一部です。
Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [8] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [7].
フロアの参加者とフロアの椅子は床に関連付けられているリソースを知っている必要があります。それらは、SDPオファー/アンサーのような異なるメカニズム、[8]の交換を使用してこの情報を取得することができます。これらの関連付けを得るために、SDPオファー/アンサー交換を使用する方法、[7]に記載されています。
Note that floor participants perform SDP offer/answer exchanges with the conference focus of the conference. So, the conference focus needs to obtain information about associations between floors and resources in order to be able to provide this information to a floor participant in an SDP offer/answer exchange.
フロア参加者が会議の会議中心としたSDPオファー/アンサー交換を行うことに注意してください。だから、会議の焦点は、SDPオファー/アンサー交換の床の参加者にこの情報を提供することができるようにするために、床やリソース間の関連付けに関する情報を取得する必要があります。
Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) Focus, are described in the XCON framework [10] (and other related documents).
この情報を取得する情報は、（SIP）フォーカスに利用可能にする方法の説明を含めるための他の機構は、XCONフレームワーク[10]（及び他の関連文書）に記載されています。
A participant whose floor request is granted has the right to use (in a certain way) the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream.
そのフロア要求許可された参加者は、（特定の方法で）要求された床に関連したリソースまたはリソースを使用する権利を有します。例えば、参加者は、特定のオーディオストリームを介してメディアを送信する権利を有することができます。
Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [10].
それにも関わらず、他の人が、彼らはそうする権利を持っていない場合でも、同時にそれに関連付けられたリソースを使用することができなくなることを意味するものではありません床を保持しています。参加者が実際に会議にリソースを使用できるメディアの決意をXCONフレームワーク[10]に記載されています。
This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants and floor control servers, and Section 4.2 describes the interface between floor chairs and floor control servers.
このセクションでは、BFCP操作の非規範的な説明を提供します。 4.1節では、フロアの参加者とフロア制御サーバ間のインタフェースを記述し、4.2節では、フロアチェア、フロア制御サーバ間のインタフェースについて説明します。
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a common header followed by a set of attributes. The common header contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers.
TLV（タイプ - 長さ - 値）のバイナリエンコーディングを使用BFCPメッセージは、属性のセットに続く共通ヘッダから成ります。共通ヘッダは、他の情報のうち、32ビットの会議識別子を含みます。フロアの参加者、メディア関係者、および床の椅子は、16ビットのユーザ識別子によって識別されます。
BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes.
BFCPは、ネストされた属性（属性が含まれている、すなわち、属性）をサポートしています。これらは、グループ化された属性と呼ばれています。
There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a message from a client to the floor control server and a response from the floor control server to the client. Both messages can be related because they carry the same Transaction ID value in their common headers. Server-initiated transactions consist of a single message, whose Transaction ID is 0, from the floor control server to a client.
クライアントが開始したトランザクションおよびサーバー開始の取引：BFCPのトランザクションの2種類があります。クライアント開始されたトランザクションは、フロア制御サーバとクライアントへのフロア制御サーバからの応答に、クライアントからのメッセージで構成されています。彼らは彼らの共通のヘッダ内の同じトランザクションID値を運ぶので、両方のメッセージを関連させることができます。サーバ起動トランザクションは、フロア制御サーバからクライアントに、そのトランザクションIDが0である単一のメッセージ、で構成されています。
Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third-party floor requests) in a BENEFICIARY-ID attribute.
フロアの参加者は、フロア制御サーバにFloorRequestメッセージを送信することにより、フロアを要求します。 BFCPは、サードパーティ製のフロア要求をサポートしています。それは、フロア要求を送信するフロア参加者は、フロア要求が許可された後、床を取得するメディアの参加者と同じ場所に配置する必要はありませんされています。 FloorRequestメッセージは、受益-ID属性で（サードパーティ製のフロア要求で）共通ヘッダのユーザーIDフィールドに要求者の身元を運び、そして床の受益者の身元。
Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media).
サードパーティ製のフロア要求は、例えば、フロア制御サーバへBFCP接続を持っていますが、それはメディアの参加者（すなわち、彼らは任意のメディアを処理していない）ではない床の参加者によって、送信することができます。
FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message.
FloorRequestメッセージは、床やFLOOR-ID属性にその16ビットの床識別子を実施することによって要求されている床を識別します。 FloorRequestメッセージは複数のフロア識別子を搬送する場合、フロア制御サーバは、原子パッケージとして全フロア要求を処理します。それは、フロア制御サーバのいずれかの助成金であるかFloorRequestメッセージ内のすべてのフロアを拒否します。
Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest.
フロア制御サーバは、フロア要求のステータスに関する情報を提供FloorRequestStatusメッセージでFloorRequestメッセージに応答します。第FloorRequestStatusメッセージは、クライアントからFloorRequestメッセージに対する応答であり、したがってFloorRequest同じトランザクションIDを有しています。
Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request.
また、第1 FloorRequestStatusメッセージはFLOOR要求情報属性にフロア要求IDを運びます。同じフロア要求に関連する後続のFloorRequestStatusメッセージは同じフロア要求IDを運ぶでしょう。このように、床の参加者は、適切なフロア要求に関連付けることができます。
Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus Message from the floor control server.
特定のフロア要求に関連するフロア参加者からのメッセージは、フロア制御サーバから第FloorRequestStatusメッセージと同じフロア要求IDを使用します。
Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute.
図2は、床の参加者が、床を要求し、それを取得し、そして、後で、それを解放する方法を示しています。この図は、トランザクションIDとFLOOR-REQUEST-ID属性の、とりわけ、使用することを示しています。
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(5) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(6) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 2: Requesting and releasing a floor
図2：フロアを要求し、解放します
Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message.
図3は、フロア参加者のリクエストが床の状態に通知する方法を示しています。フロア制御サーバから第FloorStatusメッセージのような、FloorQueryメッセージと同じトランザクションIDを有し、FloorQueryメッセージに対する応答であると。
Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted.
後続FloorStatusメッセージはサーバによって開始トランザクションから成り、したがってそれらのトランザクションIDが0 FloorStatusメッセージである（2）フロアID 543 FloorStatusメッセージである床のための2つのフロア要求が現在存在することを示している（3）フロア要求することを示し床とリクエストID 764が付与されており、フロア要求ID 635とフロア要求は、キュー内の最初のものです。 FloorStatusメッセージ（4）は、フロア要求ID 635を有するフロア要求が許可されたことを示します。
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
Figure 3: Obtaining status information about a floor
図3：床程度の取得ステータス情報
FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request.
FloorStatusメッセージは、彼らが運ぶフロア要求に関する情報が含まれています。例えば、FloorStatusメッセージ（4）は、フロア要求ID 635を有するフロア要求が受益者として有していることを示している（すなわち、特定のフロア要求が許可されているフロア保持者）は、そのユーザIDフロア要求154である参加者をのみがフロアID 543であるということです、これはマルチ階フロア要求でない床面に適用されます。
A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors.
マルチフロアフロア要求が複数の階にも適用される（例えば、参加者が話すと同時にホワイトボードに書くことができるようにしたいです）。フロア制御サーバは、原子パッケージとしてマルチ床フロア要求を処理します。それは、フロア制御サーバであり、いずれかの全フロアの要求を許可するか、すべての階の要求を拒否します。
Figure 4 shows a floor chair instructing a floor control server to grant a floor.
図4は、床を付与するために、フロア制御サーバに指示フロアチェアを示しています。
Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
フロア制御サーバを考慮に（例えば、床を付与）ChairActionメッセージで受信した命令を実行する必要があるものの、フロアチェアが要求したとして、それは必ずしも正確にそれらを実行する必要がないこと、しかし、注意してください。フロア制御サーバが実行する動作はChairActionメッセージに、フロア制御サーバの内部状態に依存します。
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant.
例えば、床、椅子は、いくつかの床を含ん原子フロア要求操作の一部として要求された床を付与ChairActionメッセージを送信することができます。フロアの1の責任の椅子が床を付与するために、フロア制御サーバに指示した場合でも他の階を担当する椅子は、同様にそれらを許可することに同意するまで、フロア制御サーバは、それを許可しません。別の例では、フロア議長は、参加者に床を付与するために、フロア制御サーバに指示することができます。フロア制御サーバは、新しい参加者にそれを許可する前に、現在の所有者から床を取り消す必要があります。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
だから、フロア制御サーバはこの状態への入力として、フロアの椅子からの命令を使用してコヒーレント床状態を維持するための最終的な責任です。
Floor Chair Floor Control
Server
|(1) ChairAction |
|Transaction ID: 769 |
|User ID: 357 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| Request Status: Granted |
|---------------------------------------------->|
| |
|(2) ChairActionAck |
|Transaction ID: 769 |
|User ID: 357 |
|<----------------------------------------------|
Figure 4: Chair instructing the floor control server
図4：議長は、フロア制御サーバに指示
BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order.
BFCPパケットは、属性に続く12オクテット共通ヘッダから成ります。すべてのプロトコル値は、ネットワークバイトオーダーで送らなければなりません。
The following is the format of the common header.
以下は、共通ヘッダのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format
図5：共通ヘッダフォーマット
Ver: The 3-bit version field MUST be set to 1 to indicate this version of BFCP.
版：3ビットのバージョンフィールドはBFCPのこのバージョンを示すために1に設定しなければなりません。
Reserved: At this point, the 5 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
予約：この時点で、予約フィールドの5ビットは、メッセージの送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined:
プリミティブ：この8ビットフィールドは、メッセージの主な目的を識別する。以下のプリミティブ値が定義されています。
+-------+--------------------+------------------+
| Value | Primitive | Direction |
+-------+--------------------+------------------+
| 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S |
| 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S |
+-------+--------------------+------------------+
S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
Table 1: BFCP primitives
表1：BFCPプリミティブ
Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the common header.
ペイロード長：この16ビットのフィールドは、共通ヘッダを除く、4オクテット単位でのメッセージの長さを含みます。
Conference ID: This 32-bit field identifies the conference the message belongs to.
会議ID：この32ビットのフィールドは、メッセージが属する会議を識別します。
Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response. The value of the Transaction ID in server-initiated transactions is 0 (see Section 8).
トランザクションID：このフィールドは、ユーザーがその応答で指定されたメッセージと一致することを可能にする16ビットの値を含みます。サーバー開始のトランザクションでのトランザクションIDの値が0（セクション8を参照）です。
User ID: This field contains a 16-bit value that uniquely identifies a participant within a conference.
ユーザID：このフィールドは、一意の会議内の参加者を識別する16ビット値を含みます。
The identity used by a participant in BFCP, which is carried in the User ID field, is generally mapped to the identity used by the same participant in the session establishment protocol (e.g., in SIP). The way this mapping is performed is outside the scope of this specification.
ユーザIDフィールドに運ばれるBFCPの参加者によって使用される同一性は、一般的に（SIPで、例えば）セッション確立プロトコルで同じ参加者によって使用されるIDにマッピングされます。このマッピングが実行される方法は、本明細書の範囲外です。
BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned.
BFCP属性は、TLV（Type-Length-Value）フォーマットで符号化されます。属性は32ビット整列されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Attribute Contents /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Attribute format
図6：属性の形式
Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are:
タイプ：この7ビットのフィールドは、属性の種類が含まれています。そのタイプによって識別される各属性は、特定の形式を持っています。定義された属性の形式は次のとおりです。
Unsigned16: The contents of the attribute consist of a 16-bit unsigned integer.
UNSIGNED16：属性の内容は、16ビットの符号なし整数から成ります。
OctetString16: The contents of the attribute consist of 16 bits of arbitrary data.
OctetString16：属性の内容は、任意の16ビットのデータで構成されています。
OctetString: The contents of the attribute consist of arbitrary data of variable length.
OCTETSTRING：属性の内容が可変長の任意のデータから成ります。
Grouped: The contents of the attribute consist of a sequence of attributes.
グループ化された：属性の内容は、属性の配列からなります。
Note that extension attributes defined in the future may define new attribute formats.
将来的に定義された拡張属性が新しい属性フォーマットを定義することがあります。
The following attribute types are defined:
次の属性タイプが定義されています。
+------+---------------------------+---------------+
| Type | Attribute | Format |
+------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | PRIORITY | OctetString16 |
| 5 | REQUEST-STATUS | OctetString16 |
| 6 | ERROR-CODE | OctetString |
| 7 | ERROR-INFO | OctetString |
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 9 | STATUS-INFO | OctetString |
| 10 | SUPPORTED-ATTRIBUTES | OctetString |
| 11 | SUPPORTED-PRIMITIVES | OctetString |
| 12 | USER-DISPLAY-NAME | OctetString |
| 13 | USER-URI | OctetString |
| 14 | BENEFICIARY-INFORMATION | Grouped |
| 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+
Table 2: BFCP attributes
表2：BFCP属性
M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If an unrecognized attribute with the 'M' bit set is received, the message is rejected. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. In all other cases, the unrecognised attribute is ignored but the message is processed.
M：必須ビットとして知られている「M」ビットは、属性のサポートが必要かどうかを示します。 「M」ビットがセットされた認識されていない属性を受信した場合、メッセージは拒否されます。 「M」ビットは他のドキュメントで定義された拡張属性の重要です。 「M」ビットの設定はこれらには無関係であるように、この文書で指定されたすべての属性は、受信機で理解されなければなりません。他のすべてのケースでは、認識されない属性は無視されますが、メッセージが処理されます。
Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes.
長さ：この8ビットのフィールドは、特定の属性のために定義された任意のパディングを除いて、オクテット内の属性の長さが含まれています。グループ化されていない属性の長さは、タイプ、「M」ビット、および長さフィールドを含みます。グループ化された属性の長さが全て含まれている属性のプラス（パディングを含む）全体の長さ（タイプ、「M」ビット、および長さフィールドを含む）をグループ化属性自体の長さです。
Attribute Contents: The contents of the different attributes are defined in the following sections.
内容属性：異なる属性の内容は、次のセクションで定義されています。
The following is the format of the BENEFICIARY-ID attribute.
以下は、受益-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format
図7：受益-IDフォーマット
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者ID：このフィールドは、一意の会議内のユーザを識別する16ビット値を含みます。
Note that although the formats of the Beneficiary ID and of the User ID field in the common header are similar, their semantics are different. The Beneficiary ID is used in third-party floor requests and to request information about a particular participant.
共通ヘッダ内の受益IDおよびユーザIDフィールドのフォーマットが類似しているが、その意味が異なることに注意してください。受益IDは、サードパーティ製の床のリクエストで使用されており、特定の参加者についての情報を要求します。
The following is the format of the FLOOR-ID attribute.
以下は、FLOOR-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID format
図8：FLOOR-IDフォーマット
Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference.
フロアID：このフィールドは、一意の会議内のフロアを識別する16ビット値を含みます。
The following is the format of the FLOOR-REQUEST-ID attribute.
以下は、FLOOR-REQUEST-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID format
図9：FLOOR-REQUEST-IDフォーマット
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
フロア要求ID：このフィールドは、フロア制御サーバにおけるフロア要求を識別する16ビット値を含みます。
The following is the format of the PRIORITY attribute.
以下は、PRIORITY属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY format
図10：PRIORITYフォーマット
Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal).
PRIO：このフィールドに4よりも高い値を使用しません表3送信者に示すように、このフィールドは、3ビットの優先値を含みます。受信された値は4（最高）であるかのように受信機は、4よりも高い値を処理しなければなりません。 PRIORITY属性が欠落しているデフォルトのプライオリティ値は、2（ノーマル）です。
+-------+----------+
| Value | Priority |
+-------+----------+
| 0 | Lowest |
| 1 | Low |
| 2 | Normal |
| 3 | High |
| 4 | Highest |
+-------+----------+
Table 3: Priority values
表3：優先順位値
Reserved: At this point, the 13 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
予約：この時点で、予約フィールド13個のビットは、メッセージの送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
The following is the format of the REQUEST-STATUS attribute.
以下は、REQUEST-STATUS属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS format
図11：REQUEST-STATUSフォーマット
Request Status: This 8-bit field contains the status of the request, as described in the following table.
要求ステータスは、次の表に示すように、この8ビットのフィールドは、リクエストのステータスが含まれています。
+-------+-----------+
| Value | Status |
+-------+-----------+
| 1 | Pending |
| 2 | Accepted |
| 3 | Granted |
| 4 | Denied |
| 5 | Cancelled |
| 6 | Released |
| 7 | Revoked |
+-------+-----------+
Table 4: Request Status values
表4：リクエストステータス値
Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero.
キュー位置：この8ビットのフィールドが含まれている、適用可能な場合、サーバーのフロア要求キュー内のフロア要求の位置。リクエストステータス値が受け入れられたから異なる場合、フロア制御サーバは、フロア要求キューを実装していない場合、またはフロア制御サーバは、この情報をクライアントに提供したくない場合は、このフィールドのすべてのビットを次のように設定しますゼロ。
A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state.
フロア制御サーバは、フロア要求を受け入れるために、フロアチェアに連絡する必要がありますが、まだそれを行っていない場合、フロア要求が保留状態になっています。フロア制御椅子が床要求を受け付けた後、フロア要求が受け入れられた状態に移動されます。
The following is the format of the ERROR-CODE attribute.
以下は、ERROR-CODE属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Error Specific Details |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format
図12：ERROR-CODEフォーマット
Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognised by the receiver, then the receiver MUST assume that an error exists, and therefore that the message is processed, but the nature of the error is unclear.
エラーコード：この8ビットのフィールドは、次の表からのエラーコードが含まれています。エラーコードが受信機によって認識されない場合、受信機は、エラーが存在すると仮定しなければならないので、メッセージが処理されることが、エラーの性質は不明です。
+-------+-----------------------------------------------------------+
| Value | Meaning |
+-------+-----------------------------------------------------------+
| 1 | Conference does not Exist |
| 2 | User does not Exist |
| 3 | Unknown Primitive |
| 4 | Unknown Mandatory Attribute |
| 5 | Unauthorized Operation |
| 6 | Invalid Floor ID |
| 7 | Floor Request ID Does Not Exist |
| 8 | You have Already Reached the Maximum Number of Ongoing |
| | Floor Requests for this Floor |
| 9 | Use TLS |
+-------+-----------------------------------------------------------+
Table 5: Error Code meaning
表5：エラーコードの意味
Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition.
エラー固有の詳細：のみ、特定のエラーコードのためのプレゼント。この文書では、唯一のエラーコード4（不明必須の属性）のために。その定義については、セクション5.2.6.1を参照してください。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
パディング：ERROR-CODE属性の内容が揃った32ビットになるように詰め物の1つ、2つ、または3つのオクテットが追加されました。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
The following is the format of the Error-Specific Details field for Error Code 4.
以下は、エラーコード4のエラー固有の詳細情報フィールドのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format
図13：不明な属性のフォーマット
Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver.
不明なタイプ：この7ビットのフィールドは、受信機に知られていなかった（エラーメッセージをトリガしたメッセージに存在した）属性の種類が含まれています。
R: At this point, this bit is reserved. It SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
R：この時点で、このビットは予約されています。これは、メッセージの送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
The following is the format of the ERROR-INFO attribute.
以下は、ERROR-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format
図14：ERROR-INFOフォーマット
Text: This field contains UTF-8 [6] encoded text.
テキスト：このフィールドには、UTF-8 [6]エンコードされたテキストが含まれています。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field.
いくつかの状況では、テキストフィールドの内容は、オートマトンによって生成されてもよいです。このオートマトンは、特定のERROR-INFO属性の受信機の好みの言語についての情報を持っている場合、それは、テキストフィールドを生成するには、この言語を使用するかもしれません。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：ERROR-INFO属性の内容が揃った32ビットになるように詰め物の1つ、2つ、または3つのオクテットが追加されました。パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The following is the format of the PARTICIPANT-PROVIDED-INFO attribute.
以下は、参加者が提供する-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format
図15：参与提供-INFOフォーマット
Text: This field contains UTF-8 [6] encoded text.
テキスト：このフィールドには、UTF-8 [6]エンコードされたテキストが含まれています。
Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：1つ、2つ、または参加者が提供する-INFO属性は32ビット整列されるの内容となるよう追加パディングの3つのオクテット。パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The following is the format of the STATUS-INFO attribute.
以下は、STATUS-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format
図16：STATUS-INFOフォーマット
Text: This field contains UTF-8 [6] encoded text.
テキスト：このフィールドには、UTF-8 [6]エンコードされたテキストが含まれています。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field.
いくつかの状況では、テキストフィールドの内容は、オートマトンによって生成されてもよいです。このオートマトンは、特定のSTATUS-INFO属性の受信機の好みの言語についての情報を持っている場合、それは、テキストフィールドを生成するには、この言語を使用するかもしれません。
Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：STATUS-INFO属性の内容が揃った32ビットになるように詰め物の1つ、2つ、または3つのオクテットが追加されました。パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The following is the format of the SUPPORTED-ATTRIBUTES attribute.
以下は、サポートされている-ATTRIBUTES属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format
図17：サポートされているアトリビュートフォーマット
Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format:
補遺。 ATTR：これらのフィールドは次の形式でフロア制御サーバによってサポートされている属性の種類が含まれています。
R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception.
R：予約：このビットは送信時にゼロに設定しなければならなくて、受信時に無視しなければなりません。
Padding: Two octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
パディング：SUPPORTED-属性の内容は、32ビットの整列である属性のように、パディングの2つのオクテットが追加。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
The following is the format of the SUPPORTED-PRIMITIVES attribute.
以下は、サポートされているプリミティブ属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SUPPORTED-PRIMITIVES format
図18：サポートされているプリミティブ形式
Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives.
プリミティブ：これらのフィールドは、フロア制御サーバによってサポートされているBFCPメッセージのタイプを含みます。 BFCPプリミティブのリストについては、表1を参照してください。
Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
パディング：サポートされているプリミティブのコンテンツ属性ように添加パディングの1つ、2つ、または3つのオクテットは、32ビットで整列されています。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。
The following is the format of the USER-DISPLAY-NAME attribute.
以下は、USER-DISPLAY-NAME属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: USER-DISPLAY-NAME format
図19：USER-DISPLAY-NAMEフォーマット
Text: This field contains the UTF-8 encoded name of the user.
テキスト：このフィールドは、ユーザーのUTF-8エンコードされた名前が含まれています。
Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：USER-DISPLAY-NAME属性の内容は、32ビットに整列されるように添加し1つ、2つ、又はパディングの3つのオクテット。パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The following is the format of the USER-URI attribute.
以下は、USER-URI属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: USER-URI format
図20：USER-URIフォーマット
Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user.
テキスト：このフィールドは、UTF-8でエンコードされたユーザの連絡先URIが含まれ、すなわち、BFCPによって制御されるリソース（例えば、メディアストリーム）を設定するためにユーザによって使用されるURI。たとえば、SIPによって設定された会議の文脈では、USER-URI属性は、ユーザーのSIP URIを運ぶでしょう。
Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID.
USER-URI属性でユーザーのURIを含むメッセージは、ユーザーのユーザーIDが含まれています。この方法は、そのようなメッセージを受信したクライアントは、ユーザのユーザIDとユーザのURI（例えば、SIP URI会議に参加するために使用されるユーザ）を相関させることができます。
Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：USER-URI属性の内容が揃った32ビットとなるようにパディングの1つ、2つ、または3つのオクテットを追加します。パディングビットは送信者によってゼロに設定されるべきであり、受信機で無視しなければなりません。属性がすでに32ビットの整列である場合には、パディングは必要ありません。
The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER:
受益情報属性は、属性の配列が続く受益-情報HEADERと呼ばれるヘッダ、から成るグループ化された属性です。以下は、受益-INFORMATION-HEADERの形式であります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format
図21：受益-情報ヘッダフォーマット
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者ID：このフィールドは、一意の会議内のユーザを識別する16ビット値を含みます。
The following is the ABNF (Augmented Backus-Naur Form) [2] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
次の[2]受益-INFORMATIONグループ化された属性のABNF（増補バッカスナウア記法）です。 （EXTENSION属性は、将来的に定義することができる拡張属性をいいます。）
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *[EXTENSION-ATTRIBUTE]
受益-INFORMATION =（受益-情報HEADER）[USER-DISPLAY-NAME] [USER-URI] * [EXTENSION属性]
Figure 22: BENEFICIARY-INFORMATION format
図22：受益情報フォーマット
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
FLOOR要求情報の属性は、属性の配列が続く床要求情報、ヘッダと呼ばれるヘッダ、から成るグループ化された属性です。以下は、FLOOR-REQUEST-INFORMATION-HEADERの形式であります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
図23：フロア要求情報ヘッダフォーマット
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
フロア要求ID：このフィールドは、フロア制御サーバにおけるフロア要求を識別する16ビット値を含みます。
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、FLOOR-REQUEST-INFORMATIONグループ化された属性のABNFです。 （EXTENSION属性は、将来的に定義することができる拡張属性をいいます。）
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) [OVERALL-REQUEST-STATUS] 1*(FLOOR-REQUEST-STATUS) [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] *[EXTENSION-ATTRIBUTE]
FLOOR要求情報=（FLOOR要求情報-HEADER）[全体-REQUEST-STATUS] 1 *（FLOOR-REQUEST-STATUS）受益-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT提供-info] * [EXTENSION-ATTRIBUTE]
Figure 24: FLOOR-REQUEST-INFORMATION format
図24：フロア要求情報フォーマット
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER:
REQUESTED-BY-INFORMATION属性は、属性の配列が続くREQUESTED-BY-情報ヘッダと呼ばれるヘッダ、から成るグループ化された属性です。以下は、要求-BY-情報ヘッダのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: REQUESTED-BY-INFORMATION-HEADER format
図25：要求-BY-情報ヘッダフォーマット
Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
要求されたバイID：このフィールドは、一意の会議内のユーザを識別する16ビット値を含みます。
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、要求-BY-INFORMATIONグループ化された属性のABNFです。 （EXTENSION属性は、将来的に定義することができる拡張属性をいいます。）
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *[EXTENSION-ATTRIBUTE]
REQUESTED-BY-INFORMATION =（要求-BY-情報HEADER）[USER-DISPLAY-NAME] [USER-URI] * [EXTENSION属性]
Figure 26: REQUESTED-BY-INFORMATION format
図26：要求-BY-情報フォーマット
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
FLOOR-REQUEST-STATUS属性は、属性の配列が続くFLOOR-REQUEST-STATUS-ヘッダと呼ばれるヘッダ、から成るグループ化された属性です。以下は、FLOOR-REQUEST-STATUS-HEADERの形式であります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
図27：FLOOR-REQUEST-STATUS-HEADERフォーマット
Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference.
フロアID：このフィールドは、一意の会議内のフロアを識別する16ビット値を含みます。
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、FLOOR-REQUEST-STATUSグループ化された属性のABNFです。 （EXTENSION属性は、将来的に定義することができる拡張属性をいいます。）
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) [REQUEST-STATUS] [STATUS-INFO] *[EXTENSION-ATTRIBUTE]
FLOOR-REQUEST-STATUS =（FLOOR-REQUEST-STATUS-HEADER）[REQUEST-STATUS] [STATUS-INFO] * [EXTENSION属性]
Figure 28: FLOOR-REQUEST-STATUS format
図28：FLOOR-REQUEST-STATUSフォーマット
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
OVERALL-REQUEST-STATUS属性は、属性の配列が続くOVERALL-REQUEST-STATUS-ヘッダと呼ばれるヘッダ、から成るグループ化された属性です。以下は、全体的な-REQUEST-STATUS-HEADERの形式であります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format
図29：総合-REQUEST-STATUS-ヘッダフォーマット
Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server.
フロア要求ID：このフィールドは、フロア制御サーバにおけるフロア要求を識別する16ビット値を含みます。
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、全体的な-REQUEST-STATUSグループ化された属性のABNFです。 （EXTENSION属性は、将来的に定義することができる拡張属性をいいます。）
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) [REQUEST-STATUS] [STATUS-INFO] *[EXTENSION-ATTRIBUTE]
OVERALL-REQUEST-STATUS =（全体-REQUEST-STATUS-HEADER）[REQUEST-STATUS] [STATUS-INFO] * [EXTENSION属性]
Figure 30: OVERALL-REQUEST-STATUS format
図30：総合-REQUEST-STATUSフォーマット
This section contains the normative ABNF (Augmented Backus-Naur Form) [2] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
このセクションでは、BFCPメッセージの規範ABNF（増補バッカスナウア記法）[2]を含んでいます。将来的に定義することができる拡張属性は、ABNFでEXTENSION属性と呼ばれます。
Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message:
フロアの参加者は、フロア制御サーバにFloorRequestメッセージを送信することにより、フロアを要求します。次はFloorRequestメッセージのフォーマットであります：
FloorRequest = (COMMON-HEADER) 1*(FLOOR-ID) [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY] *[EXTENSION-ATTRIBUTE]
FloorRequest =（COMMON-HEADER）1 *（FLOOR-ID）受益-ID] [PARTICIPANT提供-INFO] [PRIORITY] * [EXTENSION属性]
Figure 31: FloorRequest format
図31：FloorRequestフォーマット
Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message:
フロアの参加者は、フロア制御サーバにFloorReleaseメッセージを送信することにより、床をリリース。フロアの参加者はまた、保留床の要求をキャンセルするFloorReleaseメッセージを使用します。次はFloorReleaseメッセージのフォーマットであります：
FloorRelease = (COMMON-HEADER) (FLOOR-REQUEST-ID) *[EXTENSION-ATTRIBUTE]
FloorRelease =（COMMON-HEADER）（FLOOR-REQUEST-ID）* [EXTENSION属性]
Figure 32: FloorRelease format
図32：FloorReleaseフォーマット
Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message:
フロアの参加者とフロアチェアフロア制御サーバにFloorRequestQueryメッセージを送信することにより、フロア要求に関する情報を要求します。次はFloorRequestQueryメッセージのフォーマットであります：
FloorRequestQuery = (COMMON-HEADER) (FLOOR-REQUEST-ID) *[EXTENSION-ATTRIBUTE]
FloorRequestQuery =（COMMON-HEADER）（FLOOR-REQUEST-ID）* [EXTENSION属性]
Figure 33: FloorRequestQuery format
図33：FloorRequestQueryフォーマット
The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message:
フロア制御サーバは、彼らにFloorRequestStatusメッセージを送信することにより、フロア参加者とそのフロア要求のステータスに関する階の椅子を通知します。次はFloorRequestStatusメッセージのフォーマットであります：
FloorRequestStatus = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE]
FloorRequestStatus =（COMMON-HEADER）（FLOOR要求情報）* [EXTENSION属性]
Figure 34: FloorRequestStatus format
図34：FloorRequestStatusフォーマット
Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message:
フロアの参加者とフロアチェアフロア制御サーバにUserQueryメッセージを送信することにより、この参加者に関連する参加者や床要求に関する情報を要求します。次はUserQueryメッセージのフォーマットであります：
UserQuery = (COMMON-HEADER) [BENEFICIARY-ID] *[EXTENSION-ATTRIBUTE]
UserQuery =（COMMON-HEADER）受益-ID] * [EXTENSION属性]
Figure 35: UserQuery format
図35：UserQueryフォーマット
The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message:
フロア制御サーバは、メッセージをそれらをUSERSTATUS送信することにより、フロアの参加者とフロアの椅子に参加者とその関連するフロア要求に関する情報を提供します。次はUSERSTATUSメッセージのフォーマットであります：
UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] *(FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE]
USERSTATUS =（COMMON-HEADER）受益-INFORMATION] *（FLOOR要求情報）* [EXTENSION属性]
Figure 36: UserStatus format
図36：USERSTATUSフォーマット
Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorRequest message:
フロアの参加者とフロアチェアフロア制御サーバにFloorQueryメッセージを送信することにより、床や床についての情報を要求します。次はFloorRequestメッセージのフォーマットであります：
FloorQuery = (COMMON-HEADER) *(FLOOR-ID) *[EXTENSION-ATTRIBUTE]
FloorQuery =（COMMON-HEADER）*（FLOOR-ID）* [EXTENSION属性]
Figure 37: FloorQuery format
図37：FloorQueryフォーマット
The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message:
フロア制御サーバは、彼らにFloorStatusメッセージを送信することにより、フロアの参加者や床の状態（例えば、現在の所有者）について、フロアチェアを通知します。次はFloorStatusメッセージのフォーマットであります：
FloorStatus = (COMMON-HEADER) *1(FLOOR-ID) *[FLOOR-REQUEST-INFORMATION] *[EXTENSION-ATTRIBUTE]
FloorStatus =（COMMON-HEADER）* 1（FLOOR-ID）* [FLOOR要求情報] * [EXTENSION属性]
Figure 38: FloorStatus format
図38：FloorStatusフォーマット
Floor chairs send instructions to floor control servers by sending ChairAction messages. The following is the format of the ChairAction message:
フロアチェアChairActionメッセージを送信することにより、フロア制御サーバに指示を送ります。次はChairActionメッセージのフォーマットであります：
ChairAction = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE]
ChairAction =（COMMON-HEADER）（FLOOR要求情報）* [EXTENSION属性]
Figure 39: ChairAction format
図39：ChairActionフォーマット
Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message:
フロア制御サーバは、彼らがChairActionAckメッセージを送信することにより、ChairActionメッセージを受け入れていることを確認してください。次はChairActionAckメッセージのフォーマットであります：
ChairActionAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
ChairActionAck =（COMMON-HEADER）* [EXTENSION属性]
Figure 40: ChairActionAck format
図40：ChairActionAckフォーマット
Floor participants and floor chairs check the liveliness of floor control servers by sending a Hello message. The following is the format of the Hello message:
フロアの参加者とフロアチェアは、Helloメッセージを送信することによって、フロア制御サーバの活気をご確認ください。以下は、Helloメッセージのフォーマットであります：
Hello = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
こんにちは=（COMMON-HEADER）* [EXTENSION-ATTRIBUTE]
Figure 41: Hello format
図41：こんにちはフォーマット
Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message:
フロア制御サーバは、彼らがこんにちはAckメッセージを送信することにより、Helloメッセージの受信に生きていることを確認してください。次ハローAckメッセージの形式であります：
HelloAck = (COMMON-HEADER) (SUPPORTED-PRIMITIVES) (SUPPORTED-ATTRIBUTES) *[EXTENSION-ATTRIBUTE]
HelloAck =（COMMON-HEADER）（サポートプリミティブ）（サポート-ATTRIBUTES）* [EXTENSION属性]
Figure 42: HelloAck format
図42：HelloAckフォーマット
Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message:
フロア制御サーバは、彼らにエラー・メッセージを送信することにより、要求を処理エラーに関するフロアの参加者とフロアチェアを知らせます。以下は、エラーメッセージの形式であります：
Error = (COMMON-HEADER) (ERROR-CODE) [ERROR-INFO] *[EXTENSION-ATTRIBUTE]
エラー=（COMMON-HEADER）（ERROR-CODE）[ERROR-INFO] * [EXTENSION-ATTRIBUTE]
Figure 43: Error format
図43：エラーフォーマット
BFCP entities exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing is implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes.
BFCP実体は、TCP接続を使用してBFCPメッセージを交換します。 TCPは、バイトストリームのインオーダー信頼性の高い配信を提供します。したがって、メッセージフレーミングは、アプリケーションレイヤに実装されます。 BFCPはTLV-エンコードされた属性を使用してアプリケーション層のフレーミングを実装しています。
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed.
クライアントは、会議内の所定のフロア制御サーバと通信するために、複数のTCPコネクションを使用してはなりません。同じ物理ボックスは異なるクライアントを扱う場合にもかかわらず、（例えば、フロアチェア、フロア参加者）異なるユーザIDで識別され、クライアントごとに別々の接続が許可されます。
If a BFCP entity (a client or a floor control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out, the TCP connection SHOULD be reestablished.
BFCPエンティティ（クライアントまたはフロア制御サーバ）が解析できないTCPからのデータを受信した場合、エンティティは、TCP接続を閉じる必要があり、接続が再確立されるべきである（SHOULD）。 TCP接続がBFCPメッセージと時間を提供することができない場合は同様に、TCP接続が再確立されるべきである（SHOULD）。
The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server (e.g., using an SDP offer/answer exchange [7]). Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server.
処理される方法接続再確立は、クライアントがフロア制御サーバに連絡するための情報を取得する方法に依存する（例えば、SDPオファー/アンサー交換を使用して[7]）。 TCP接続が再確立されると、クライアントは、フロア制御サーバからの応答を取得しなかったため、これらのメッセージを再送信することができます。
If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished.
フロア制御サーバは、フロア参加者の一人に向けたTCP接続が失われたことを検出した場合は、フロアの参加者の保留床の要求をどうするかまで、フロア制御サーバのローカルポリシーにあります。いずれにせよ、TCP接続が再確立されている間（それはそれらをキャンセルしないこと、すなわち）フロア制御サーバは、フロア要求をおくことをお勧めします。
If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client.
クライアントは、フロア制御サーバとのBFCPの接続を終了したい場合は、クライアントが（すなわち、優雅近い）フロア制御サーバへのTCP接続を終了します。フロア制御サーバがクライアントとのBFCPの接続を終了したい場合（例えば、会議の焦点は、クライアントが会議から追い出されたフロア制御サーバに通知）、フロア制御サーバ閉じ（すなわち、優雅近いですクライアントへの）TCP接続。
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS [3]. Any BFCP entity MAY support other security mechanisms.
BFCPはリプレイと完全性の保護と機密性を提供するために、下位層のセキュリティメカニズムに依存しています。 （両方のフロアの参加者とフロアチェアがあり）BFCPフロア制御サーバとクライアントはTLSをサポートしなければならない[3]。どれBFCPエンティティは、他のセキュリティ・メカニズムをサポートするかもしれません。
BFCP entities MUST support, at a minimum, the TLS TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
BFCPエンティティ[5]は、最小で、TLS TLS_RSA_WITH_AES_128_CBC_SHAの暗号スイートをサポートしなければなりません。
Which party, the client or the floor control server, acts as the TLS server depends on how the underlying TCP connection is established. For example, when the TCP connection is established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server.
どの政党、クライアントやフロア制御サーバは、TLSサーバは、基礎となるTCP接続が確立された方法によって異なりとして機能します。 TCP接続がSDPオファー/アンサー交換を使用して確立されたとき、例えば、[7]、（クライアント又はフロア制御サーバであってもよい）回答は常にTLSサーバとして機能します。
In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions (notifications). Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. The request carries a Transaction ID in its common header, which the floor control server copies into the response. Clients use Transaction ID values to match responses with previously issued requests.
クライアントが開始したトランザクションとサーバー開始されたトランザクション（通知）：BFCPでは、取引の2種類があります。クライアント開始されたトランザクションは、フロア制御サーバへのクライアントからの要求やクライアントへのフロア制御サーバからの応答で構成されます。要求は、共通ヘッダ内のトランザクションID、応答にフロア制御サーバコピーを運びます。クライアントは、以前に発行された要求と応答を一致させるためにトランザクションID値を使用します。
Server-initiated transactions consist of a single message from a floor control server to a client. Since they do not trigger any response, their Transaction ID is set to 0.
サーバ起動トランザクションは、クライアントへのフロア制御サーバから単一のメッセージで構成されています。彼らはどんな反応を誘発しないので、そのトランザクションIDが0に設定されています。
A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously.
クライアントが開始したトランザクションを開始するクライアントは、クライアントが以前に得られた会議の会議IDにメッセージの共通ヘッダに会議IDを設定しなければなりません。
The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server.
クライアントは、0とは異なる数に共通ヘッダ内のトランザクションIDの値を設定する必要があり、サーバからの応答は、トランザクションのために受信されるまで、そのクライアントからの別のメッセージにおいて再利用してはいけません。クライアントは、フロア制御サーバからの応答に、このメッセージに一致するトランザクションIDの値を使用しています。
A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0.
クライアントが開始したトランザクション内で応答を送信するフロア制御サーバは、応答の中に、クライアントから受信した要求から会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。サーバ起動トランザクションは0に等しいトランザクションIDを含まなければなりません。
BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it.
BFCPクライアントはそれに任意のBFCPメッセージを送信したり、そこから任意のBFCPメッセージを受け入れる前に、フロア制御サーバを認証する必要があります。同様に、フロア制御サーバは、そこから任意のBFCPメッセージを受け入れるか、それをどのBFCPメッセージを送信する前にクライアントを認証すべきです。
BFCP supports TLS-based mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.
9.1節で指定されているようBFCPは、クライアントとフロア制御サーバ間のTLSベースの相互認証をサポートしています。これは、BFCPで推奨される認証メカニズムです。
Note that future extensions may define additional authentication mechanisms.
将来の拡張には、追加の認証メカニズムを定義することがあります。
In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further.
BFCPメッセージを認証することに加えて、フロア制御サーバは、それらを承認する必要があります。認証されたBFCPメッセージを受信すると、フロア制御サーバのチェックがメッセージを送信するクライアントが許可されるかどうか。クライアントが要求されている操作を実行することを許可されていない場合は、図5（不正な操作）の値とエラーコードで、セクション13.8に記載されているように、フロア制御サーバは、エラーメッセージを生成します。許可することができないクライアントからのメッセージがさらに処理してはなりません。
BFCP supports TLS-based mutual authentication between clients and floor control servers. BFCP assumes that there is an integrity-protected channel between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. These certificates are used at TLS establishment time.
BFCPは、クライアントとフロア制御サーバ間のTLSベースの相互認証をサポートしています。 BFCPは、クライアントと彼らの自己署名証明書を交換するために使用することができ、フロア制御サーバ間の整合性が保護チャネルが存在することを前提としてや、より一般的に、これらの証明書のフィンガープリント。これらの証明書は、TLSの確立時に使用されています。
The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [7].
SIPを使用して、このような完全性保護チャネルの実装およびSDPオファー/アンサーモデルは、[7]に記載されています。
BFCP messages received over an authenticated TLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP (no TLS) can request the use of TLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore unauthenticated messages.
BFCPメッセージは、認証されたTLS接続を介して受信認証さと考えられています。 9（使用TLS）の値とエラーコードで、セクション13.8に記載されているようにTCP（NO TLS）上BFCPメッセージを受信したフロア制御サーバは、エラーメッセージを生成することによって、TLSの使用を要求することができます。クライアントは、単に認証されていないメッセージを無視すべきです。
Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority).
将来の拡張が初期完全性保護されたチャネルを必要としない追加の認証メカニズムを定義することができることに留意されたい（例えば、認証証明機関によって署名された証明書に基づきます）。
As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server SHOULD check that messages arriving over a given authenticated TLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS connection is allowed to use).
第9章で説明したように、フロア制御サーバは、すべてのメッセージを処理する前に承認を実行する必要があります。具体的には、フロア制御サーバは、所定の認証TLS接続を介して到着したメッセージが許可されたユーザのID（認証済みTLS接続を確立し、ユーザが使用を許可されている、すなわち、ユーザID）を使用することを確認する必要があります。
This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).
このセクションでは、フロアの参加者は、以前のセクションで説明したプロトコル要素を使用して、フロアを要求するなど、さまざまな操作を実行する方法を指定します。セクション11は、フロアを許可または取り消すフロア制御サーバに指示として床椅子に固有の動作を指定し、セクション12は、任意のクライアント（すなわち、フロア参加者とフロア椅子の両方）によって行うことができる操作を指定します。
A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.
一の以上のフロアを要求したいフロア参加者は、フロア制御サーバにFloorRequestメッセージを送信することによって、そうします。
The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.1項でABNFはFloorRequestメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1.
フロア参加者は、セクション8.1で与えられた規則に従って共通ヘッダに会議IDおよびトランザクションIDを設定します。
The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor.
フロア参加者がフロア参加者の識別子に共通ヘッダ内のユーザIDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。 （ユーザIDによって識別される）FloorRequestメッセージの送信者が最終的に（つまり、サードパーティ製のフロア要求）床になるだろう参加者でない場合は、送信者は、受益者を識別するメッセージに受益-ID属性を追加すべきです床の。
Note that the name space for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in the common header and in several attributes: BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-INFORMATION.
ユーザーIDと受益者IDの両方のための名前空間が同じであることに注意してください。受益-ID受益-INFORMATION、要求-BY-INFORMATION：それは、与えられた参加者は、共通ヘッダ内のユーザIDに、いくつかの属性を使用することができる単一の16ビット値によって識別されます。
The floor participant must insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR-ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message.
フロア参加者はFloorRequestメッセージ内の少なくとも1つのFLOOR-ID属性を挿入する必要があります。クライアントが複数のFLOOR-ID属性を挿入した場合は、フロア制御サーバは、原子のパッケージなど、すべての階のリクエストを処理します。これは、フロア制御サーバはFloorRequestメッセージ内の全フロアを許可または拒否するか、です。
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.
フロアの参加者は、参加者が提供する-INFOは、床や床が要求されている理由を述べるために属性を使用することができます。参与提供-INFO属性のテキストフィールドは、人間の消費のために意図されます。
The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute.
フロアの参加者は、サーバがPRIORITY属性を使用して、特定の優先順位のフロア要求を処理することを要求することができます。
A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージがFloorRequestメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合、セクション8.1で説明したように、フロア制御サーバからのメッセージは、FloorRequestメッセージへの応答であると考えられます。そのような応答を受信すると、フロアの参加者がフロア制御サーバ認証に関連する第9の規則に従います。
The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request.
フロア制御サーバでFloorRequestメッセージの成功した処理は、1つまたはいくつかのFloorRequestStatusメッセージを生成することを含みます。フロアの参加者は、フロア制御サーバからの最初のFloorRequestStatusメッセージでFLOOR-REQUEST-INFORMATION属性のフロア要求IDフィールドに、フロア要求IDを取得します。同じフロア要求に関するフロア制御サーバからの後続FloorRequestStatusメッセージは、初期FloorRequestStatusメッセージとしてFLOOR-REQUEST-INFORMATION属性に同じフロア要求IDを運ぶでしょう。このように、フロアの参加者は、継続的なフロア要求で、後続の着信FloorRequestStatusメッセージを関連付けることができます。
The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request.
フロアの参加者は、フロア制御サーバから受信したFloorRequestStatusメッセージのそれぞれのFLOOR-REQUEST-INFORMATION属性にフロア要求の状態に関する情報を取得します。この属性は、グループ化された属性であり、そのようにそれがフロア要求に関する情報を提供する属性の数を含んでいます。
The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user.
OVERALL-REQUEST-STATUS属性は、フロア要求の全体的なステータスに関する情報を提供します。リクエストステータス値が付与されている場合は、FloorRequestメッセージで要求されたすべての階が付与されています。リクエストステータス値が拒否された場合、FloorRequestメッセージで要求されたすべての階が拒否されています。フロア要求は、それが保留中、承認済み、または許可された状態にあるときに、進行中であると考えられています。フロア要求値が不明な場合は、応答がまだ処理されています。しかし、意味のある値がユーザに報告することはできません。
The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
STATUS-INFO属性が存在する場合、フロア参加者がユーザーに表示されることがありという余分な情報を提供します。
The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
FLOOR-REQUEST-STATUS属性は、特定の階に関連するフロア要求のステータスに関する情報を提供します。 STATUS-INFO属性が存在する場合、フロア参加者がユーザーに表示されることがありという余分な情報を提供します。
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header.
受益-INFORMATION属性は、サードパーティ製の床リクエストでフロア要求の受益者を特定します。 REQUESTED-BY-INFORMATION属性は、このフロアの参加者が既に共通ヘッダにユーザIDによって識別されるように、フロアを要求し、フロア参加者によって受信FloorRequestStatusメッセージ内に存在する必要はありません。
The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message.
PRIORITY属性は、存在する場合、FloorRequestメッセージの発電機によって要求された優先順位が含まれています。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がエラーメッセージである場合には、フロア制御サーバは、エラーメッセージに記述されているいくつかの理由でFloorRequestメッセージを処理できませんでした。
A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.
継続中のフロア要求をキャンセルしたいフロア参加者は、フロア制御サーバにFloorReleaseメッセージを送信することによって、そうします。 FloorReleaseメッセージは、床を保持し、それを解放したいと思い、フロアの参加者によって使用されます。
The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.2項でABNFはFloorReleaseメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
フロア参加者は、セクション8.1で与えられた規則に従って共通ヘッダに会議IDおよびトランザクションIDを設定します。フロア参加者がフロア参加者の識別子に共通ヘッダ内のユーザIDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire.
FloorReleaseメッセージが付与された床又は床を解放するために、継続的なフロア要求をキャンセルするために使用されることに注意してください（プロトコルの観点から、両方の継続的なフロア要求です）。両方の状況で同じメッセージを使用すると、FloorReleaseメッセージとFloorGrantメッセージがワイヤーに交差するときに発生する競合状態を解決するのに役立ちます。
The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling.
フロア参加者はFloorReleaseメッセージがキャンセルさFloorRequestメッセージに応答して受信されたFLOOR-REQUEST-IDを使用しています。
Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time).
フロア参加者（すなわち、単一FloorRequestメッセージ内）アトミック動作として、いくつかのフロアを要求した場合、全ての床が同様（すなわち、全てが同時に放出される）アトミック動作として放出されることに留意されたいです。
A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージがFloorRequestメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合、セクション8.1で説明したように、フロア制御サーバからのメッセージは、FloorReleaseメッセージへの応答であると考えられます。そのような応答を受信すると、フロアの参加者がフロア制御サーバ認証に関連する第9の規則に従います。
If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
応答はFloorRequestStatusメッセージである場合、（FLOOR要求情報グループ化属性内）全体的な-REQUEST-STATUS属性に要求ステータス値がキャンセルまたは解放されるであろう。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がエラーメッセージである場合には、フロア制御サーバは、エラーメッセージに記述されているいくつかの理由でFloorRequestメッセージを処理できませんでした。
It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease.
FloorReleaseメッセージがキャンセルまたはリリースは異なる要求ステータスを持つサーバーからFloorRequestStatusメッセージを持つワイヤーに交差している可能性があります。そのトランザクションIDがFloorReleaseのものと一致しませんどのような場合には、そのようなFloorRequestStatusメッセージは、FloorReleaseメッセージに応答できません。
This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections.
このセクションでは、フロアチェア、先のセクションに記載されているプロトコル要素を使用して床を付与または取り消すフロア制御サーバに指示することができる方法を指定します。
Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message.
フロア制御サーバに指示を送りたいフロアチェアChairActionメッセージを送ることによって、それを行います。
The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.9項でABNFはChairActionメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
フロアチェアは、セクション8.1で与えられた規則に従って共通ヘッダに会議IDおよびトランザクションIDを設定します。フロアチェアフロア参加者の識別子に共通ヘッダーにユーザーIDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.
ChairActionメッセージは、特定のフロア要求内の1つのまたは複数のフロアに適用する命令が含まれています。床または床は、床-REQUEST-STATUS属性によって識別され、フロア要求がChairActionメッセージで運ばれるFLOOR-REQUEST-情報ヘッダによって識別されます。
For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision.
フロア要求が別のフロアチェアに依存して2つのフロアで構成されていた場合、各フロアチェアフロア要求内の床が付与されます。両方の椅子が彼らの床を付与した後、フロア制御サーバは、全体として、フロア要求を許可します。フロアの椅子の一つは、その床を拒否した場合一方、フロア制御サーバは関係なく、他のフロアチェアの決定の、全体としてフロア要求を拒否します。
The floor chair provides the new status of the floor request as it relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field SHOULD be set to zero. The floor chair SHOULD use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and SHOULD use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted).
それはFLOOR-REQUEST-STATUS属性を使用して特定の階に関連するフロアチェアフロア要求の新しいステータスを提供します。フロア要求の新しいステータスが受理された場合は、フロアチェアフロア要求のためのキュー位置を提供するために、キュー位置フィールドを使用するかもしれません。フロアチェアは、キューの位置を提供することを望まない場合は、キュー位置フィールドの全てのビットがゼロに設定する必要があります。フロアチェア（すなわち、許可状態）を付与されたフロアを取り消す取り消しステータスを使用すると、他の状況（例えば、保留中および承認）におけるフロア要求を拒否するように拒否ステータスを使用します。
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request.
フロアチェアフロア要求のための新たな全体的な状況を提供するために、ChairActionメッセージにOVERALL-REQUEST-STATUS属性を追加するかもしれません。フロア要求の新しい全体的な状況が受け入れられると、フロアチェアフロア要求のためのキュー位置を提供するために、キュー位置フィールドを使用するかもしれません。
Note that a particular floor control server may implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request may involve several floors and that a ChairAction message may only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overall status of the floor request.
特定のフロア制御サーバがその特定のフロア、全フロア要求、またはその両方のための一般的なキューに関連するすべてのフロア要求を含む各フロアごとに異なるキューを実装してもよいことに留意されたいです。また、フロア要求は、いくつかのフロアを伴い、ChairActionメッセージのみがこれらの床の一部に対処することが可能性があることに注意（例えば、単一のフロアチェアは、全フロアを管理するために許可されていない場合）。この場合、フロア制御サーバは、フロア要求の全体的な状況を思い付く属性FLOOR-REQUEST-STATUSで別のフロアチェアから受け取った命令を結合します。
Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content.
フロアチェアのアクションは、全体的な-REQUEST-STATUS属性に情報を通信することができる一方で、フロア制御サーバは、上書き、変更、またはこのフィールドの内容を無視して、あることに注意してください。
The floor chair may use STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption.
フロアチェアは、STATUS-INFOは、床や床は、受け入れ付与された、または取り消されている理由を述べるために属性を使用することができます。 STATUS-INFO属性内のテキストは、人間の消費のために意図されます。
A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication.
サーバからのメッセージがChairActionメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合、セクション8.1で説明したように、フロア制御サーバからのメッセージは、ChairActionメッセージへの応答であると考えられます。そのような応答を受信すると、フロアチェアフロア制御サーバ認証に関連する第9の規則に従います。
A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message.
フロア制御サーバからChairActionAckメッセージは、フロア制御サーバはChairActionメッセージを受け入れたことを確認します。エラーメッセージは、フロア制御サーバがエラーメッセージに記述されているいくつかの理由のためChairActionメッセージを処理できなかったことを示します。
This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.
このセクションでは、任意のクライアントで実行できる操作を指定します。つまり、彼らは床の参加者や床椅子に固有のものではありません。彼らは両方で行うことができます。
A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントはBFCPを使用してアウトオブバンドメカニズムを使用することを含む様々な方法で床又は床の状態に関する情報を得ることができます。そのような情報を得るためにBFCPを使用するクライアントは、このセクションで説明する手順を使用します。
Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.
クライアントは1つのステータスやフロア制御サーバにFloorQueryメッセージを送信することにより、いくつかのフロアについての情報を要求します。
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.7項でABNFはFloorQueryメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは、8.1節で与えられた規則に従って共通ヘッダに会議IDとトランザクションIDを設定します。クライアントは、クライアントの識別子に共通ヘッダのUser IDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute.
クライアントは、メッセージに、それはに関する情報を受信したいすべてのフロアIDを挿入します。フロア制御サーバは、これらのフロアのすべてについて定期的に情報が送信されます。クライアントは、もはや特定の階に関する情報を受信したくない場合は、このフロアの床-IDを削除し、新たなFloorQueryメッセージを送信します。クライアントは、もはや任意の床についての情報を受信したくない場合は、無FLOOR-ID属性でFloorQueryメッセージを送信します。
A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the
フロア制御サーバからのメッセージが同じ会議ID、トランザクションID、およびユーザIDを有する場合にフロア制御サーバからのメッセージがFloorQueryメッセージへの応答であると考えられます
FloorRequest message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
8.1節で説明したようにFloorRequestメッセージ。そのような応答を受信すると、クライアントは、フロア制御サーバ認証に関連する第9の規則に従います。
On reception of the FloorQuery message, the floor control server will respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either.
FloorQueryメッセージを受信すると、フロア制御サーバはFloorStatusメッセージまたはエラーメッセージで応答します。応答がFloorStatusメッセージであれば、それは、クライアントが情報を要求したフロアの1についての情報が含まれています。クライアントはそのFloorQueryメッセージのいずれかのFLOOR-ID属性が含まれていなかった場合は、フロア制御サーバからFloorStatusメッセージは、任意のFLOOR-IDは、どちらかの属性は含まれません（つまり、クライアントは、もはや任意の床についての情報を受信したくはありません） 。
FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request.
床についての情報を運ぶFloorStatusメッセージは床を識別FLOOR-ID属性が含まれています。この属性の後、FloorStatusメッセージは、そのフロアに関連する既存の（一つ以上）のフロア要求に関する情報が含まれています。各特定のフロア要求に関する情報は、フロア要求情報属性に符号化されます。このグループ化された属性は、フロア要求に関する情報を提供する属性のセットに続くフロア要求を識別するフロア要求IDを運びます。
After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about.
最初FloorStatus後、フロア制御サーバは、定期的にクライアントが情報を要求したフロアに、変更についてクライアントに通知、FloorStatusメッセージの送信を継続します。
A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、BFCPを使用し、アウトオブバンドメカニズムを使用することを含む、さまざまな方法では、1つのまたは複数のフロア要求の状況についての情報を得ることができます。そのような情報を得るためにBFCPを使用するクライアントは、このセクションで説明する手順を使用します。
Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server.
クライアントは、フロア制御サーバにFloorRequestQueryメッセージを送信することにより、フロア要求の現在のステータスに関する情報を要求します。
Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.
特定のフロア要求に関する情報を要求することは多くの状況で有用です。例えば、FloorRequestメッセージの受信時に、フロア制御サーバは、フロア要求がキュー内に進んだ場合、フロア要求（例えば、承認から確かに）その状態を変化させるだけでなく、場合FloorRequestStatusメッセージを返すように選択することができます。ユーザーが要求した場合、このような状況では、フロアの参加者は、フロア要求のステータスのフロア制御サーバをポーリングするFloorRequestQueryメッセージを使用することができます。
The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.3でのABNFはFloorRequestQueryメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは、8.1節で与えられた規則に従って共通ヘッダに会議IDとトランザクションIDを設定します。クライアントは、クライアントの識別子に共通ヘッダのUser IDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
The client must insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.
クライアントは、フロア制御サーバでフロア要求を識別しFLOOR-REQUEST-ID属性を挿入する必要があります。
A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージがFloorRequestQueryメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合、セクション8.1で説明したように、フロア制御サーバからのメッセージは、FloorRequestQueryメッセージへの応答であると考えられます。そのような応答を受信すると、クライアントは、フロア制御サーバ認証に関連する第9の規則に従います。
If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute.
応答がFloorRequestStatusメッセージである場合、クライアントは、クライアントがFLOOR-REQUEST-INFORMATION属性に情報を要求しFloorRequestのステータスに関する情報を取得します。
If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.
応答がエラーメッセージである場合には、フロア制御サーバは、エラーメッセージに記述されているいくつかの理由でFloorRequestQueryメッセージを処理できませんでした。
A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、参加者とBFCPを使用してアウトオブバンドメカニズムを使用することを含む様々な方法、この参加者に関連するフロア要求に関する情報を取得することができます。そのような情報を得るためにBFCPを使用するクライアントは、このセクションで説明する手順を使用します。
Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server.
クライアントは、参加者とフロア制御サーバにUserQueryメッセージを送信することにより、この参加者に関連したフロア要求に関する情報を要求します。
This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist.
この機能は、フロアチェアや表示名と特定のフロアの参加者のURIに興味フロアの参加者のために有用である可能性があります。また、フロアの参加者は、それが役に立つ自分自身に関する情報を要求するかもしれません。例えば、フロアの参加者は、接続の問題を経験した後に（例えば、フロア制御サーバとのTCP接続がしばらくダウンしていたし、最終的に再確立されました）、まだ自分自身に関連したすべてのフロア要求に関する情報を要求する必要があるかもしれませんが存在します。
The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.5でのABNFはUserQueryメッセージを含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは、8.1節で与えられた規則に従って共通ヘッダに会議IDとトランザクションIDを設定します。クライアントは、クライアントの識別子に共通ヘッダのUser IDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute.
クライアントが情報を要求しているフロア参加者は、（メッセージの共通ヘッダ内のユーザIDで識別される）UserQueryメッセージを発行するクライアントがない場合、クライアント受益-ID属性を挿入する必要があります。
A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージがUserQueryメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合、セクション8.1で説明したように、フロア制御サーバからのメッセージは、UserQueryメッセージへの応答であると考えられます。そのような応答を受信すると、クライアントは、フロア制御サーバ認証に関連する第9の規則に従います。
If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.
応答がUSERSTATUSメッセージである場合、クライアントは、受益-INFORMATIONグループ化された属性の床の参加者について及びFLOOR-REQUEST-INFORMATION属性の床の参加者に関連付けられた床のリクエストのステータスに関する情報を取得します。
If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.
応答がエラーメッセージである場合には、フロア制御サーバは、エラーメッセージに記述されているいくつかの理由でUserQueryメッセージを処理できませんでした。
A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.
フロア制御サーバの能力を得たいクライアントは、フロア制御サーバにHelloメッセージを送信することによって、そうします。
The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.11でのABNFは、Helloメッセージに含めることができる属性について説明します。また、ABNFは必須であり、どれがオプションであるこれらの属性のどの規範的に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは、8.1節で与えられた規則に従って共通ヘッダに会議IDとトランザクションIDを設定します。クライアントは、クライアントの識別子に共通ヘッダのUser IDを設定します。このユーザーIDは、要求を認証し、認証するために、フロア制御サーバによって使用されます。
A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
8.1節で説明したように、フロア制御サーバからのメッセージは、Helloメッセージと同じ会議ID、トランザクションID、およびユーザIDを持っている場合は、フロア制御サーバからのメッセージは、クライアントによってHelloメッセージに対する応答と考えられています。そのような応答を受信すると、クライアントは、フロア制御サーバ認証に関連する第9の規則に従います。
If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITVIES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server.
応答がHelloAckメッセージである場合には、フロア制御サーバが正常にHelloメッセージを処理することができます。 SUPPORTED-PRIMITVIESおよび属性は、サーバーによってサポートされ、それぞれ、プリミティブと属性を示しSUPPORTEDは、ATTRIBUTES。
If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.
応答がエラーメッセージである場合には、フロア制御サーバは、エラーメッセージに記述されているいくつかの理由でHelloメッセージを処理できませんでした。
This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections.
このセクションでは、フロア制御サーバは、以前のセクションで説明したプロトコル要素を使用して、フロアを許可などの異なる操作を実行する方法を指定します。
On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive).
クライアントからのメッセージを受信すると、フロア制御サーバは、プリミティブの値がサポートされているかどうかをチェックしなければなりません。そうでない場合は、セクション13.8で説明したように、フロア制御サーバがエラーコード3（不明なプリミティブ）と、エラー・メッセージを送信する必要があります。
On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist).
クライアントからのメッセージを受信すると、フロア制御サーバは、会議IDの値が既存の会議にマッチしたかどうかをチェックしなければなりません。それがない場合は、エラーコード1で、13.8節で説明したように、フロア制御サーバは、（会議が存在しない）、エラー・メッセージを送信する必要があります。
On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message.
クライアントからのメッセージの受信時に、フロア制御サーバは、メッセージの認証に関連する第9の規則に従います。
On reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 2 (Authentication Failed). The Error message SHOULD list the attributes that were not understood.
クライアントからのメッセージを受信すると、フロア制御サーバは、それがすべての必須（「M」ビットセットを）理解したメッセージの属性かどうかをチェックしなければなりません。フロア制御サーバは、それらのすべてを理解していない場合はエラーコード2（認証失敗）で、13.8節で説明したように、フロア制御サーバは、エラー・メッセージを送信する必要があります。エラーメッセージが理解されていなかったの属性をリストする必要があります。
On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorRequestメッセージを受信すると、フロア制御サーバは、クライアントの認証と承認に関連する第9項の規則に従います。 FloorRequestメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests for this Floor) to inform the floor participant.
BFCPは、フロアの参加者が同じフロア（例えば、同じフロアの参加者が同時にキュー内の複数の位置を占めることができる）のためのいくつかの継続的なフロア要求を持つことができます。唯一のフロア参加者ごとの継続的なフロア要求の一定数をサポートしているフロア制御サーバは（例えば、1）は、フロアの参加者に通知する（あなたはすでにこのフロアのための継続的なフロア要求の最大数に達しました）エラーコード8を使用することができます。
The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates.
フロア制御サーバによってFloorRequestメッセージの成功した処理は、できるだけ早く生成されるべき最初のうち1つまたはいくつかのFloorRequestStatusメッセージを生成することを含みます。フロア制御サーバは（例えば、椅子からの決定が必要とされている）、助成金を受け入れるか、すぐにフロア要求を拒否することができない場合は、FLOOR内（OVERALL-REQUEST-STATUS属性に保留中の要求ステータスの値を使用する必要があります-request-情報は、それが生成する第1 FloorRequestStatusメッセージの属性）をグループ化します。
The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made.
フロア制御サーバは、フロアを許可または拒否するために、次のポリシーは、この文書の範囲外です。別の椅子として決定がなされる必要があるたびに、人間の演技に連絡することができながら、与えられたフロア制御サーバは自動的にこれらの決定を行うことができます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the
フロア制御サーバは、へFloorRequestから会議ID、トランザクションID、およびユーザIDをコピーする必要があります
FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
8.2節で説明したようにFloorRequestStatus、。さらに、フロア制御サーバはFloorRequestStatusに属性をグループ化FLOOR-REQUEST-情報を追加する必要があります。このグループ化された属性に含まれる属性は、フロア要求に関する情報を運びます。
The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future.
フロア制御サーバは、このフロア要求に会議内でユニークな識別子を割り当てる必要があり、およびFLOOR-REQUEST-INFORMATION属性のフロア要求IDフィールドに挿入しなければなりません。この識別子は、将来的には、この特定のフロア要求を参照するために、フロア参加者（あるいは椅子や椅子で）使用されます。
The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request).
FLOOR-REQUEST-STATUSにFloorRequestのFLOOR-ID属性でのフロアIDをコピーする必要があり、フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性の属性。これらのフロアIDは、フロアが要求されている識別（すなわち、この特定のフロア要求に関連付けられたフロア）。
The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
フロア制御サーバは、（存在する場合）FLOOR要求情報グループ化属性内部受益情報属性にFloorRequestから受益-ID属性の内容をコピーする必要があります。さらに、フロア制御サーバは、この受益-INFORMATION属性に表示名および受益者のURIを提供することができます。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性の内部REQUESTED-BY-INFORMATION属性の床の依頼者に関する情報を提供することができます。
The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.
（存在する場合）、フロア制御サーバは、参加者が提供する-INFOは、FLOOR-REQUEST-INFORMATIONグループ化された属性にFloorRequestから属性をコピーすることができます。
Note that this attribute carries the priority requested by the participant. The priority that the floor control server assigns to the floor request depends on the priority requested by the participant and the rights the participant has according to the policy of the conference. For example, a participant that is only allowed to use the Normal priority may request Highest priority for a floor request. In that case, the floor control server would ignore the priority requested by the participant.
この属性は、参加者から要求された優先順位を運ぶことに注意してください。フロア制御サーバは、フロア要求に割り当てる優先順位は、参加者と参加者が会議の方針に従っている権利によって要求された優先順位に依存します。例えば、参加者のみがフロア要求のための最高の優先順位を要求することができる通常の優先順位を使用することが許可されています。その場合には、フロア制御サーバは、参加者から要求された優先順位を無視します。
The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.
（存在する場合）、フロア制御サーバは、参加者が提供する-INFOは、FLOOR-REQUEST-INFORMATIONグループ化された属性にFloorRequestから属性をコピーすることができます。
A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages.
フロア要求は限りそれは、キャンセルリリース、または失効状態にないとして、進行中であると考えられています。フロア制御サーバによって生成された第1 FloorRequestStatusメッセージの（FLOOR-REQUEST-INFORMATIONグループ化された属性の内部）OVERALL-REQUEST-STATUS属性は、これらの状態のいずれかを示すものではありませんでした場合は、フロア制御サーバは、後続FloorRequestStatusメッセージを送信する必要があります。
When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.)
ときにフロア要求の状況が変化すると、フロア制御サーバは、適切な要求ステータスを持つ新しいFloorRequestStatusメッセージを送るべきです。フロア制御サーバは、同じフロア要求に関連する新しいFloorRequestStatus第1 FloorRequestStatusメッセージで送信されるものと同じフロア要求IDを持つフロア要求情報の属性を追加しなければなりません。 （フロア要求IDはFloorRequestStatusが適用されるフロア要求を識別する。）
The floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0.
フロア制御サーバは0に、後続のFloorRequestStatusメッセージのトランザクションIDを設定しなければなりません。
The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied.
フロア制御サーバがFloorRequestStatusメッセージを送信する速度は、ローカルポリシーの問題です。フロア制御サーバは、新しいFloorRequestStatusメッセージに別のが唯一のフロア要求が許可または拒否された新しいFloorRequestStatusメッセージを送信することを選択するかもしれないが、フロア要求は、フロア要求キューに移動するたびに送信することもできます。
The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied).
フロア制御サーバは、フロア要求（例えば、それが拒否された理由）について、その決定についての追加情報を提供するために、生成FloorRequestStatusメッセージのいずれかにSTATUS-INFO属性を追加することができます。
Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in Section 12.1. If the processing of a floor request changes the status of a floor (e.g., the floor request is granted and consequently the floor has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that have requested that information.
フロアの参加者とフロアの椅子は、12.1節の手順次のフロアの状況について通知するように要求することができます。フロア要求の処理が床の状態を変更した場合（例えば、フロア要求が許可され、その結果、床が新しいホルダーを持っている）、フロア制御サーバは、要求されたクライアントに通知するために、セクション13.5の手順に従ってくださいする必要がありますその情報。
The common header and the rest of the attributes are the same as in the first FloorRequestStatus message.
共通ヘッダおよび属性の残りの部分は、第FloorRequestStatusメッセージと同じです。
The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.
これは、キャンセルリリース、または取り消さの状態に達したときにフロア制御サーバは、特定のフロア要求に関する状態情報を破棄することができます。
On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorRequestQueryメッセージを受信すると、フロア制御サーバは、クライアントの認証と承認に関連する第9項の規則に従います。 FloorRequestQueryメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
フロア制御サーバによってFloorRequestQueryメッセージの成功した処理は、できるだけ早く生成されるべきであるFloorRequestStatusメッセージを生成することを含みます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.
8.2節で説明したように、フロア制御サーバは、FloorRequestStatusメッセージにFloorRequestQueryメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。さらに、フロア制御サーバはFloorRequestStatusへFLOOR-REQUEST-INFORMATIONグループ化された属性にフロア要求に関する情報を含まなければなりません。
The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
フロア制御サーバは、FLOOR-REQUEST-INFORMATION属性のフロア要求IDフィールドにFloorRequestQueryメッセージからFLOOR-REQUEST-ID属性の内容をコピーしなければなりません。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
フロア制御サーバは、FLOOR-REQUEST-STATUSは、（FLOOR-REQUEST-ID属性によって識別されたフロア要求に関連付けられた、すなわち、フロア）が要求されるフロアを識別するフロア要求情報グループ化された属性に属性を追加しなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
フロア制御サーバは、フロア要求の受益者を識別する床要求情報グループ化された属性に受益-ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益-INFORMATION属性に表示名および受益者のURIを提供することができます。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性の内部REQUESTED-BY-INFORMATION属性の床の依頼者に関する情報を提供することができます。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロア制御サーバは、フロアの参加者が参加者が提供する-INFOで床を要求した理由を提供することができます。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request.
フロア制御サーバもFLOOR-REQUEST-INFORMATIONグループ化された属性に加えるかもしれフロア要求とSTATUS-INFOのために要求された優先順位値を持つPRIORITY属性は、フロア要求に関する追加情報を属性。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
フロア制御サーバは、フロア要求の現在の状態でFLOOR-REQUEST-INFORMATIONグループ化された属性にOVERALL-REQUEST-STATUS属性を追加しなければなりません。それは床REQUEST-STATUS属性に要求されているフロアのそれぞれに関連するフロア制御サーバは、フロア要求のステータスに関する情報を提供することができます。
On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
UserQueryメッセージを受信すると、フロア制御サーバは、クライアントの認証と承認に関連する第9項の規則に従います。 UserQueryメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible.
フロア制御サーバによってUserQueryメッセージの成功した処理は、できるだけ早く生成されるべきであるUSERSTATUSメッセージを生成することを含みます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the USerStatus message, as described in Section 8.2.
8.2節で説明したように、フロア制御サーバは、USERSTATUSメッセージにUserQueryメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message.
UserQueryメッセージの送信者は、所与の参加者（参加者が受益者又は要求者のいずれかである、すなわち、フロア要求）に関連付けられたすべてのフロア要求に関する情報を要求しています。この参加者は、受益-ID属性によって、又は受益-ID属性が存在しない場合に、UserQueryメッセージの共通ヘッダ内のユーザIDによって識別されます。
The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute.
フロア制御サーバはUSERSTATUSメッセージ受益情報属性に存在する場合、UserQueryメッセージから受益-ID属性の内容をコピーする必要があります。さらに、フロア制御サーバは、表示名とUSERSTATUSメッセージは、この受益-INFORMATION属性に情報を提供するかについて参加者のURIを提供することができます。
The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
フロア制御サーバは、メッセージが情報を提供するかについて、参加者に関連する各フロア要求のUSERSTATUSメッセージにFLOOR要求情報グループ化された属性を追加すべきである（すなわち、参加者が受益者又は要求者のいずれかであるフロア要求）。各FLOOR-REQUEST-INFORMATION属性については、フロア制御サーバは、次の手順に従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
フロア制御サーバは、フロア要求情報属性が床要求情報属性のフロア要求IDフィールドを充填することによりに適用フロア要求を識別しなければなりません。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
フロア制御サーバは、FLOOR-REQUEST-STATUSは、（FLOOR-REQUEST-ID属性によって識別されたフロア要求に関連付けられた、すなわち、フロア）が要求されるフロアを識別するフロア要求情報グループ化された属性に属性を追加しなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
フロア制御サーバは、フロア要求の受益者を識別する床要求情報グループ化された属性に受益-ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益-INFORMATION属性に表示名および受益者のURIを提供することができます。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性の内部REQUESTED-BY-INFORMATION属性の床の依頼者に関する情報を提供することができます。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロア制御サーバは、フロアの参加者が参加者が提供する-INFOで床を要求した理由を提供することができます。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性にフロア要求のために要求された優先順位値を持つPRIORITY属性を追加するかもしれません。
The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性にOVERALL-REQUEST-STATUS属性にフロア要求の現在の状態を含まなければなりません。フロア制御サーバは、フロア要求に関する追加情報を含むSTATUS-INFO属性を追加するかもしれません。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
それは床REQUEST-STATUS属性に要求されているフロアのそれぞれに関連するフロア制御サーバは、フロア要求のステータスに関する情報を提供することができます。
On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorReleaseメッセージを受信すると、フロア制御サーバは、クライアントの認証と承認に関連する第9項の規則に従います。 FloorReleaseメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
フロア制御サーバによってFloorReleaseメッセージの成功した処理は、できるだけ早く生成されるべきであるFloorRequestStatusメッセージを生成することを含みます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2.
8.2節で説明したように、フロア制御サーバは、FloorRequestStatusメッセージにFloorReleaseメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
フロア制御サーバはFloorRequestStatusに属性をグループ化FLOOR-REQUEST-情報を追加する必要があります。このグループ化された属性に含まれる属性は、フロア要求に関する情報を運びます。
The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
FloorReleaseメッセージは、それが床REQUEST-IDを使用して適用されるフロア要求を識別する。フロア制御サーバは、FLOOR-REQUEST-INFORMATION属性のフロア要求IDフィールドにFloorReleaseメッセージからFLOOR-REQUEST-ID属性の内容をコピーしなければなりません。
The floor control server MUST identify the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、FLOOR-REQUEST-STATUSに要求さ床（すなわち、床は、床-REQUEST-ID属性によって識別されたフロア要求に関連付けられた）床要求情報グループ化された属性に属性を識別しなければなりません。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性にOVERALL-REQUEST-STATUS属性を追加しなければなりません。床（または床）は、以前に付与されていなかった場合は、床（または床）は、以前に、付与された、またはキャンセルされた場合には要求ステータス値は、解放する必要があります。フロア制御サーバは、フロア要求に関する追加情報を含むSTATUS-INFO属性を追加するかもしれません。
On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorQueryメッセージの受信時に、フロア制御サーバは、クライアントの認証に関連する第9の規則に従います。 FloorReleaseメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages.
クライアントからFloorQueryメッセージを受信し、フロア制御サーバは、FLOOR-IDで識別されるフロアの状況FloorQueryメッセージの属性についての情報を、このクライアントを維持する必要があります。フロア・コントロール・サーバーは、FloorStatusメッセージを使って通知クライアントを保ちます。
An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors.
個々FloorStatusメッセージは、単一の床についての情報を運びます。 FloorQueryメッセージが複数のフロアについての情報を要求したときに、フロア制御サーバは、異なる階に別々のFloorStatusメッセージを送信する必要があります。
The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so.
FloorQueryメッセージが運ぶ情報は、情報を要求しているユーザに依存してもよいです。例えば、椅子は通常のユーザーがそうすることを許可されないかもしれないが、保留中の要求に関する情報を受信することができます。
The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible.
フロア制御サーバによってFloorQueryメッセージの成功した処理は、できるだけ早く生成されるべき最初のうち1つまたはいくつかのFloorStatusメッセージを生成することを含みます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2.
8.2節で説明したように、フロア制御サーバは、FloorStatusメッセージにFloorQueryメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant.
FloorQueryメッセージは、任意のFLOOR-ID属性が含まれていなかった場合は、フロア制御サーバは、追加の属性を追加することなく、FloorStatusメッセージを送信し、フロアの参加者に後続FloorStatusメッセージを送信しません。
If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
FloorQueryメッセージが含まれている場合は一つ以上のFLOOR-ID属性、フロア制御サーバは、それらの中からいずれかを選択し、FloorStatusメッセージにこのFLOOR-ID属性を追加します。フロア制御サーバは、床に関連する各フロア要求のためのFLOOR-REQUEST-INFORMATIONグループ化された属性を追加する必要があります。属性をグループ化し、各フロア要求情報は、フロア要求に関する情報を提供する属性の数が含まれています。各FLOOR-REQUEST-INFORMATION属性については、フロア制御サーバは、次の手順に従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
フロア制御サーバは、フロア要求情報属性が床要求情報属性のフロア要求IDフィールドを充填することによりに適用フロア要求を識別しなければなりません。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
フロア制御サーバは、FLOOR-REQUEST-STATUSは、（FLOOR-REQUEST-ID属性によって識別されたフロア要求に関連付けられた、すなわち、フロア）が要求されるフロアを識別するフロア要求情報グループ化された属性に属性を追加しなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
フロア制御サーバは、フロア要求の受益者を識別する床要求情報グループ化された属性に受益-ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益-INFORMATION属性に表示名および受益者のURIを提供することができます。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性の内部REQUESTED-BY-INFORMATION属性の床の依頼者に関する情報を提供することができます。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロア制御サーバは、フロアの参加者が参加者が提供する-INFOで床を要求した理由を提供することができます。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
フロア制御サーバは、FLOOR-REQUEST-INFORMATIONグループ化された属性にフロア要求のために要求された優先順位値を持つPRIORITY属性を追加するかもしれません。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
フロア制御サーバは、フロア要求の現在の状態でFLOOR-REQUEST-INFORMATIONグループ化された属性にOVERALL-REQUEST-STATUS属性を追加しなければなりません。フロア制御サーバは、フロア要求に関する追加情報を含むSTATUS-INFO属性を追加するかもしれません。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
それは床REQUEST-STATUS属性に要求されているフロアのそれぞれに関連するフロア制御サーバは、フロア要求のステータスに関する情報を提供することができます。
If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0.
FloorQueryメッセージが複数のFLOOR-ID属性を行った場合は、フロア制御サーバは、できるだけ早く（FLOOR-ID属性を除いて、第1 FloorStatusメッセージのために選択された）それらの各々のためのFloorStatusメッセージを生成する必要があります。これらFloorStatusメッセージは、最初のFloorStatusメッセージ（13.5.1項を参照）と同じ規則を次のように生成されますが、そのトランザクションIDは0です。
After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0.
これらのメッセージを生成した後、フロア制御サーバは、定期的にクライアントが情報を要求したすべてのフロアについての情報をクライアントに保ち、FloorStatusメッセージを送信します。これらのメッセージのトランザクションIDは0でなければなりません。
The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus message every time a new floor request arrives, while another may choose to only send a new FloorStatus message when a new floor request is Granted.
フロア制御サーバがFloorStatusメッセージを送信する速度は、ローカルポリシーの問題です。フロア制御サーバは別の唯一の新しいフロア要求が許可された新しいFloorStatusメッセージを送信することを選択するかもしれないが、新しいFloorStatusメッセージ新しいフロア要求が到着するたびに送信することもできます。
On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
ChairActionメッセージを受信すると、フロア制御サーバは、クライアントの認証と承認に関連する第9項の規則に従います。 ChairActionメッセージの処理中に、フロア制御サーバでエラーが発生した場合は、セクション13.8に記載される手順に従ってエラー応答を生成する必要があります。
The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible.
フロア制御サーバによってChairActionメッセージの成功した処理は、できるだけ早く生成されるべきであるChairActionAckメッセージを生成することを含みます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2.
8.2節で説明したように、フロア制御サーバは、ChairActionAckメッセージにChairActionメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
フロア制御サーバは考慮ChairActionメッセージで要求された動作を取る必要がある（例えば、フロア権を付与）が、必ずしも床椅子の要求に応じて、それを実行する必要はありません。フロア制御サーバが実行する動作はChairActionメッセージに、フロア制御サーバの内部状態に依存します。
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well.
例えば、床、椅子は、いくつかの床を含ん原子フロア要求操作の一部として要求された床を付与ChairActionメッセージを送信することができます。フロアの1の責任の椅子が床を付与するために、フロア制御サーバに指示した場合でも他の階を担当する椅子は、同様にそれらを許可することに同意するまで、フロア制御サーバは、それを許可しません。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
だから、フロア制御サーバはこの状態への入力として、フロアの椅子からの命令を使用してコヒーレント床状態を維持するための最終的な責任です。
If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.)
ChairActionメッセージに新しいステータスが受け入れられ、キュー位置フィールドの全てのビットがゼロの場合、フロアチェア（例えば、キュー内の最後の）フロア要求には、ベースフロア制御サーバは、キュー位置を割り当てることを要求していますフロア制御サーバのローカルポリシーに。 （フロア制御サーバがキューを実装している場合もちろん、そのような要求にのみ適用されます。）
On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
Helloメッセージを受信すると、フロア制御サーバは、クライアントの認証に関連する第9項の規則に従います。 Helloメッセージを処理している間に、フロア制御サーバでエラーが発生した場合、それは、セクション13.8で説明した手順を以下のエラー応答を生成する必要があります。
The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2.
フロア制御サーバによってHelloメッセージの成功した処理ができるだけ早く生成されるべきであるHelloAckメッセージを生成することを伴います。 8.2節で説明したように、フロア制御サーバは、HelloAckへこんにちはから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server.
フロア制御サーバは、サポートされているプリミティブは、フロア制御サーバでサポートされているすべてのプリミティブ（すなわち、BFCPメッセージ）をリストアップHelloAckメッセージに属性を追加しなければなりません。
The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server.
フロア制御サーバは、サポートされている、属性がフロア制御サーバがサポートするすべての属性をリストHelloAckメッセージに属性を追加しなければなりません。
Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional.
エラーメッセージは常にクライアントが開始したトランザクションの一部としてクライアントから前のメッセージに応答して送信されます。 5.3.13項でABNFは、エラーメッセージを含めることができる属性について説明します。また、ABNFは必須で、どれがオプションであるこれらの属性のどの規範的に指定します。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2.
8.2節で説明したように、フロア制御サーバは、エラー・メッセージに、クライアントからのメッセージから会議ID、トランザクションID、およびユーザIDをコピーしなければなりません。
The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.
フロア制御サーバは、エラーメッセージにERROR-CODE属性を追加しなければなりません。 ERROR-CODE属性はさらに、フロア制御サーバはERROR-INFOはエラーに関する追加情報と属性を追加して、表5からのエラーコードが含まれています。
BFCP uses TLS to provide mutual authentication between clients and servers. TLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS with non-null encryption always be used. BFCP entities MAY use other security mechanisms as long as they provide similar security properties.
BFCPは、クライアントとサーバー間の相互認証を提供するために、TLSを使用しています。 TLSはまた、リプレイと完全性の保護と機密性を提供します。非ヌル暗号化でTLSを常に使用することをお勧めします。 BFCPエンティティは、限り、彼らは同様のセキュリティ特性を提供するように、他のセキュリティ・メカニズムを使用するかもしれません。
The remainder of this section analyzes some of the threats against BFCP and how they are addressed.
このセクションの残りの部分は、BFCPとそれらがどのように対処さに対する脅威のいくつかを分析します。
An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections. The floor control server assumes that attackers cannot highjack the TLS connection and, therefore, that messages over the TLS connection come from the client that was initially authenticated.
攻撃者は、鍛造床要求を生成したり、既存の床の要求を許可または拒否するために、クライアント（フロア参加者やフロアチェア）を偽装しようとすることができます。クライアントの偽装は、サーバーのみ認証されたTLS接続を介してBFCPメッセージを受け入れることによって回避されます。フロア制御サーバは、攻撃者がTLS接続を介してメッセージが最初に認証されたクライアントから来ていること、そのため、TLS接続をハイジャックしていないことを前提としています。
An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections.
攻撃者は、フロア制御サーバを偽装しようとすることができます。成功した攻撃者は、クライアントが、彼らはそれにアクセスするための正当な権利を持たずに（メディアを送信するなど、）リソースにアクセスしようとするように、彼らは、特定のフロアを保持することを考えさせることができるでしょう。フロア制御サーバの偽装は、サーバーのみ認証されたTLS接続を介してBFCPメッセージを受け入れることによって回避されます。
Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS connections prevents this attack.
攻撃者は、クライアントとフロア制御サーバで交換されるメッセージを変更しようとすることがあります。 TLS接続が提供する完全性保護は、この攻撃を防ぐことができます。
An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS connection is allowed to use).
攻撃者は、フロア制御サーバにクライアントから送信された有効なメッセージを取得し、攻撃者とフロア制御サーバ間の接続を介して、それを再生しようとすることができます。この攻撃は、フロア制御サーバが認証所定のTLS接続を介して到着したメッセージが許可されたユーザーIDを使用することを確認有することによって防止される（すなわち、認証されたTLS接続を確立し、ユーザが使用を許可されたユーザID）。
Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS confidentiality prevents this attack. Therefore, it is RECOMMENDED that TLS be used with a non-null encryption algorithm.
攻撃者は、フロア制御サーバとクライアントの間で機密情報へのアクセスを取得するために、ネットワークからのメッセージを選択しようと試みてもよい（例えば、フロア要求が拒否された理由）。 TLSの機密性は、この攻撃を防ぐことができます。したがって、TLSがnull以外の暗号化アルゴリズムを使用することをお勧めします。
The IANA has created a new registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This new registry has a number of subregistries, which are described in the following sections.
IANAは、「バイナリフロア制御プロトコル（BFCP）パラメータ」と呼ばれるBFCPパラメータのための新しいレジストリを作成しました。この新しいレジストリは、次のセクションで説明されているsubregistries、の数を持っています。
This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP attributes shall be "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics.
このセクションでは、BFCPパラメータレジストリの下に属性の副登録を確立します。 RFC 2434での用語あたり[4]、BFCP属性の登録ポリシーは、「仕様が必要」とします。この副登録の目的のために、BFCPはIANA登録が要求されている属性の標準トラックRFCで定義されなければなりません。このようなRFCは属性の型、名前、フォーマット、およびセマンティクスを指定しなければなりません。
For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry.
各BFCP属性に、IANAは、そのタイプ、名前、および属性が定義されているRFCへの参照を登録します。次の表は、この副登録の初期値が含まれています。
+------+---------------------------+------------+
| Type | Attribute | Reference |
+------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC 4582] |
| 2 | FLOOR-ID | [RFC 4582] |
| 3 | FLOOR-REQUEST-ID | [RFC 4582] |
| 4 | PRIORITY | [RFC 4582] |
| 5 | REQUEST-STATUS | [RFC 4582] |
| 6 | ERROR-CODE | [RFC 4582] |
| 7 | ERROR-INFO | [RFC 4582] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
| 9 | STATUS-INFO | [RFC 4582] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
| 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
| 12 | USER-DISPLAY-NAME | [RFC 4582] |
| 13 | USER-URI | [RFC 4582] |
| 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
| 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
| 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
| 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+------+---------------------------+------------+
Table 6: Initial values of the BFCP Attribute subregistry
表6：BFCP属性副登録の初期値
This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics.
このセクションでは、BFCPパラメータレジストリの下にプリミティブ副登録を確立します。 RFC 2434での用語あたり[4]、BFCPプリミティブの登録ポリシーは、「仕様が必要」とします。この副登録の目的のために、IANA登録が要求されているBFCPプリミティブは、標準トラックRFCで定義されなければなりません。このようなRFCは、プリミティブ値、名前、フォーマット、およびセマンティクスを指定しなければなりません。
For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
プリミティブ各BFCPために、IANAは、その値、その名前、およびプリミティブが定義されているRFCへの参照を登録します。次の表は、この副登録の初期値が含まれています。
+-------+--------------------+------------+
| Value | Primitive | Reference |
+-------+--------------------+------------+
| 1 | FloorRequest | [RFC 4582] |
| 2 | FloorRelease | [RFC 4582] |
| 3 | FloorRequestQuery | [RFC 4582] |
| 4 | FloorRequestStatus | [RFC 4582] |
| 5 | UserQuery | [RFC 4582] |
| 6 | UserStatus | [RFC 4582] |
| 7 | FloorQuery | [RFC 4582] |
| 8 | FloorStatus | [RFC 4582] |
| 9 | ChairAction | [RFC 4582] |
| 10 | ChairActionAck | [RFC 4582] |
| 11 | Hello | [RFC 4582] |
| 12 | HelloAck | [RFC 4582] |
| 13 | Error | [RFC 4582] |
+-------+--------------------+------------+
Table 7: Initial values of the BFCP primitive subregistry
表7：BFCPプリミティブ副登録の初期値
This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status.
このセクションでは、BFCPパラメータレジストリの下で要求ステータス副登録を確立します。 RFC 2434での用語あたり[4]、BFCP要求ステータスの登録ポリシーは、「仕様が必要」とします。この副登録の目的のために、IANA登録が要求されているBFCP要求のステータスは、標準トラックRFCで定義されなければなりません。このようなRFCは、値と要求状態のセマンティクスを指定しなければなりません。
For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry.
各BFCP要求ステータスのため、IANAは、その値、その意味、および要求のステータスが定義されているRFCへの参照を登録します。次の表は、この副登録の初期値が含まれています。
+-------+-----------+------------+
| Value | Status | Reference |
+-------+-----------+------------+
| 1 | Pending | [RFC 4582] |
| 2 | Accepted | [RFC 4582] |
| 3 | Granted | [RFC 4582] |
| 4 | Denied | [RFC 4582] |
| 5 | Cancelled | [RFC 4582] |
| 6 | Released | [RFC 4582] |
| 7 | Revoked | [RFC 4582] |
+-------+-----------+------------+
Table 8: Initial values of the Request Status subregistry
表8：要求ステータス副登録の初期値
This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it.
このセクションでは、BFCPパラメータレジストリの下のエラーコード副登録を確立します。 RFC 2434における用語の通り[4]、BFCPエラーコードの登録ポリシーが「仕様が必要」でなければなりません。この副登録の目的のために、IANA登録が要求されたBFCPエラーコードは、標準トラックRFCによって定義されなければなりません。このようなRFCは、値とエラーコードの意味、およびそれに適用されるエラー固有の詳細を指定する必要があります。
For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
プリミティブ各BFCPために、IANAは、その値、その意味、およびプリミティブが定義されているRFCへの参照を登録します。次の表は、この副登録の初期値が含まれています。
+-------+-----------------------------------------------+------------+
| Value | Meaning | Reference |
+-------+-----------------------------------------------+------------+
| 1 | Conference does not Exist | [RFC 4582] |
| 2 | User does not Exist | [RFC 4582] |
| 3 | Unknown Primitive | [RFC 4582] |
| 4 | Unknown Mandatory Attribute | [RFC 4582] |
| 5 | Unauthorized Operation | [RFC 4582] |
| 6 | Invalid Floor ID | [RFC 4582] |
| 7 | Floor Request ID Does Not Exist | [RFC 4582] |
| 8 | You have Already Reached the Maximum Number | [RFC 4582] |
| | of Ongoing Floor Requests for this Floor | |
| 9 | Use TLS | [RFC 4582] |
+-------+-----------------------------------------------+-----------+
Table 9: Initial Values of the Error Code subregistry
表9：エラーコード副登録の初期値
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments.
XCON WGチェア、アダムローチとアラン・ジョンストンは、このドキュメントのために有益なアイデアを提供しました。また、Xiaotao呉、ポールKyzivat、ジョナサン・ローゼンバーグ、ミゲルA.ガルシア・マーティン、メアリー・バーンズ、ベン・キャンベル、デイヴ・モーガン、そしてオスカーノボは有益なコメントを提供しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[3]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[5]、RFC 3268、2002年6月のchown、P.、 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせを"。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[7] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[7]、RFC 4583、2006年11月カマリロ、G.、 "バイナリフロア制御プロトコル（BFCP）ストリームのセッション記述プロトコル（SDP）フォーマットを"。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.
[9] Koskelainen、P.、オット、J.、Schulzrinneと、H.、およびX.呉、 "フロア制御プロトコルのための要件"、RFC 4376、2006年2月。
[10] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", Work in Progress, February 2005.
[10]バーンズ、M.および「一元会議のためのフレームワークとデータモデル」C.ボールトン、進歩、2005年2月に作業。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Joerg Ott Helsinki University of Technology Department for Electrical and Communications Engineering Networking Laboratory PO Box 3000 02015 TKK Finland
電気工学と通信エンジニアリング・ネットワーキング研究所私書箱3000 02015 TKKフィンランドのための技術部門のイェルクオットヘルシンキ大学
EMail: jo@netlab.hut.fi
メールアドレス：jo@netlab.hut.fi
Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK
キース糖剤ルーセント・テクノロジーズ風車の丘ビジネスパークスウィンドンウィルトシャー州SN5 6PP英国
EMail: drage@lucent.com
メールアドレス：drage@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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, THE IETF TRUST, 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彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。