原文

[要約] RFC 4582は、会議で共有リソースへの一時的なアクセス権（フロア）を調整するBinary Floor Control Protocol（BFCP）を規定しています。フロア要求・解放、フロアチェアによる許可・拒否・取消し、状態通知のためのメッセージ形式と処理手順を定めています。本仕様はRFC 8855によって廃止され、後継仕様に置き換えられています。

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)

バイナリ・フロア制御プロトコル（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.

本書はインターネットコミュニティ向けのインターネット標準化過程プロトコルを規定し、その改善に向けた議論や提案を求めます。このプロトコルの標準化状況については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。本書は無制限に配布できます。

Copyright Notice

著作権表示

Copyright (C) The IETF Trust (2006).

Copyright (C) The IETF Trust (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
   1. はじめに ........................................................4
   2. Terminology .....................................................4
   2. 用語 ............................................................4
   3. Scope ...........................................................5
   3. 範囲 ............................................................5
      3.1. Floor Creation .............................................7
      3.1. フロアの作成 ...............................................7
      3.2. Obtaining Information to Contact a Floor Control Server ....7
      3.2. フロア制御サーバーに連絡するための情報の取得 ...............7
      3.3. Obtaining Floor-Resource Associations ......................7
      3.3. フロアとリソースの対応付けの取得 ...........................7
      3.4. Privileges of Floor Control ................................8
      3.4. フロア制御の権限 ...........................................8
   4. Overview of Operation ...........................................8
   4. 動作の概要 ......................................................8
      4.1. Floor Participant to Floor Control Server Interface ........8
      4.1. フロア参加者とフロア制御サーバー間のインターフェイス .......8
      4.2. Floor Chair to Floor Control Server Interface .............13
      4.2. フロアチェアとフロア制御サーバー間のインターフェイス ......13
   5. Packet Format ..................................................14
   5. パケット形式 ...................................................14
      5.1. COMMON-HEADER Format ......................................15
      5.1. COMMON-HEADER形式 .........................................15
      5.2. Attribute Format ..........................................16
      5.2. 属性形式 ..................................................16
           5.2.1. BENEFICIARY-ID .....................................18
           5.2.1. BENEFICIARY-ID .....................................18
           5.2.2. FLOOR-ID ...........................................18
           5.2.2. FLOOR-ID ...........................................18
           5.2.3. FLOOR-REQUEST-ID ...................................19
           5.2.3. FLOOR-REQUEST-ID ...................................19
           5.2.4. PRIORITY ...........................................19
           5.2.4. PRIORITY ...........................................19
           5.2.5. REQUEST-STATUS .....................................20
           5.2.5. REQUEST-STATUS .....................................20
           5.2.6. ERROR-CODE .........................................21
           5.2.6. ERROR-CODE .........................................21
                  5.2.6.1. Error-Specific Details for Error Code 4 ...22
                  5.2.6.1. エラーコード4に固有の詳細 .................22
           5.2.7. ERROR-INFO .........................................22
           5.2.7. ERROR-INFO .........................................22
           5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
           5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
           5.2.9. STATUS-INFO ........................................24
           5.2.9. STATUS-INFO ........................................24
           5.2.10. SUPPORTED-ATTRIBUTES ..............................24
           5.2.10. SUPPORTED-ATTRIBUTES ..............................24
           5.2.11. SUPPORTED-PRIMITIVES ..............................25
           5.2.11. SUPPORTED-PRIMITIVES ..............................25
           5.2.12. USER-DISPLAY-NAME .................................26
           5.2.12. USER-DISPLAY-NAME .................................26
           5.2.13. USER-URI ..........................................26
           5.2.13. USER-URI ..........................................26
           5.2.14. BENEFICIARY-INFORMATION ...........................27
           5.2.14. BENEFICIARY-INFORMATION ...........................27
           5.2.15. FLOOR-REQUEST-INFORMATION .........................27
           5.2.15. FLOOR-REQUEST-INFORMATION .........................27
           5.2.16. REQUESTED-BY-INFORMATION ..........................28
           5.2.16. REQUESTED-BY-INFORMATION ..........................28
           5.2.17.  FLOOR-REQUEST-STATUS .............................29
           5.2.17.  FLOOR-REQUEST-STATUS .............................29
           5.2.18.  OVERALL-REQUEST-STATUS ...........................30
           5.2.18.  OVERALL-REQUEST-STATUS ...........................30
      5.3. Message Format ............................................30
      5.3. メッセージ形式 ............................................30
           5.3.1. FloorRequest .......................................31
           5.3.1. FloorRequest .......................................31
           5.3.2. FloorRelease .......................................31
           5.3.2. FloorRelease .......................................31
           5.3.3. FloorRequestQuery ..................................31
           5.3.3. FloorRequestQuery ..................................31
           5.3.4. FloorRequestStatus .................................31
           5.3.4. FloorRequestStatus .................................31
           5.3.5. UserQuery ..........................................32
           5.3.5. UserQuery ..........................................32
           5.3.6. UserStatus .........................................32
           5.3.6. UserStatus .........................................32
           5.3.7. FloorQuery .........................................32
           5.3.7. FloorQuery .........................................32
           5.3.8. FloorStatus ........................................33
           5.3.8. FloorStatus ........................................33
           5.3.9. ChairAction ........................................33
           5.3.9. ChairAction ........................................33
           5.3.10. ChairActionAck ....................................33
           5.3.10. ChairActionAck ....................................33
           5.3.11. Hello .............................................33
           5.3.11. Hello .............................................33
           5.3.12. HelloAck ..........................................34
           5.3.12. HelloAck ..........................................34
           5.3.13. Error .............................................34
           5.3.13. Error .............................................34
   6. Transport ......................................................34
   6. トランスポート .................................................34
   7. Lower-Layer Security ...........................................35
   7. 下位層のセキュリティ ...........................................35
   8. Protocol Transactions ..........................................35
   8. プロトコルトランザクション .....................................35
      8.1. Client Behavior ...........................................36
      8.1. クライアントの動作 ........................................36
      8.2. Server Behavior ...........................................36
      8.2. サーバーの動作 ............................................36
   9. Authentication and Authorization ...............................36
   9. 認証と認可 .....................................................36
      9.1. TLS-Based Mutual Authentication ...........................37
      9.1. TLSベースの相互認証 .......................................37
   10. Floor Participant Operations ..................................37
   10. フロア参加者の操作 ............................................37
      10.1. Requesting a Floor .......................................37
      10.1. フロアの要求 .............................................37
           10.1.1. Sending a FloorRequest Message ....................38
           10.1.1. FloorRequestメッセージの送信 ......................38
           10.1.2. Receiving a Response ..............................38
           10.1.2. 応答の受信 ........................................38
      10.2. Cancelling a Floor Request and Releasing a Floor .........40
      10.2. フロア要求の取消しとフロアの解放 .........................40
           10.2.1. Sending a FloorRelease Message ....................40
           10.2.1. FloorReleaseメッセージの送信 ......................40
           10.2.2. Receiving a Response ..............................40
           10.2.2. 応答の受信 ........................................40
   11. Chair Operations ..............................................41
   11. フロアチェアの操作 ............................................41
      11.1. Sending a ChairAction Message ............................41
      11.1. ChairActionメッセージの送信 ..............................41
      11.2. Receiving a Response .....................................42
      11.2. 応答の受信 ...............................................42
   12. General Client Operations .....................................43
   12. クライアントの一般的な操作 ....................................43
      12.1. Requesting Information about Floors ......................43
      12.1. フロアに関する情報の要求 .................................43
           12.1.1. Sending a FloorQuery Message ......................43
           12.1.1. FloorQueryメッセージの送信 ........................43
           12.1.2. Receiving a Response ..............................43
           12.1.2. 応答の受信 ........................................43
      12.2. Requesting Information about Floor Requests ..............44
      12.2. フロア要求に関する情報の要求 .............................44
           12.2.1. Sending a FloorRequestQuery Message ...............45
           12.2.1. FloorRequestQueryメッセージの送信 .................45
           12.2.2. Receiving a Response ..............................45
           12.2.2. 応答の受信 ........................................45
      12.3. Requesting Information about a User ......................45
      12.3. 利用者に関する情報の要求 .................................45
           12.3.1. Sending a UserQuery Message .......................46
           12.3.1. UserQueryメッセージの送信 .........................46
           12.3.2. Receiving a Response ..............................46
           12.3.2. 応答の受信 ........................................46
      12.4. Obtaining the Capabilities of a Floor Control Server .....46
      12.4. フロア制御サーバーの機能の取得 ...........................46
           12.4.1. Sending a Hello Message ...........................47
           12.4.1. Helloメッセージの送信 .............................47
           12.4.2. Receiving Responses ...............................47
           12.4.2. 応答の受信 ........................................47
   13. Floor Control Server Operations ...............................47
   13. フロア制御サーバーの操作 ......................................47
      13.1. Reception of a FloorRequest Message ......................48
      13.1. FloorRequestメッセージの受信 .............................48
           13.1.1. Generating the First FloorRequestStatus Message ...48
           13.1.1. 最初のFloorRequestStatusメッセージの生成 ..........48
           13.1.2. Generation of Subsequent
                   FloorRequestStatus Messages .......................50
           13.1.2. 後続のFloorRequestStatusメッセージの生成 ..........50
      13.2. Reception of a FloorRequestQuery Message .................51
      13.2. FloorRequestQueryメッセージの受信 ........................51
      13.3. Reception of a UserQuery Message .........................52
      13.3. UserQueryメッセージの受信 ................................52
      13.4. Reception of a FloorRelease Message ......................53
      13.4. FloorReleaseメッセージの受信 .............................53
      13.5. Reception of a FloorQuery Message ........................54
      13.5. FloorQueryメッセージの受信 ...............................54
           13.5.1. Generation of the First FloorStatus Message .......55
           13.5.1. 最初のFloorStatusメッセージの生成 .................55
           13.5.2. Generation of Subsequent FloorStatus Messages .....56
           13.5.2. 後続のFloorStatusメッセージの生成 .................56
      13.6. Reception of a ChairAction Message .......................56
      13.6. ChairActionメッセージの受信 ..............................56
      13.7. Reception of a Hello Message .............................57
      13.7. Helloメッセージの受信 ....................................57
      13.8. Error Message Generation .................................58
      13.8. Errorメッセージの生成 ....................................58
   14. Security Considerations .......................................58
   14. セキュリティに関する考慮事項 ..................................58
   15. IANA Considerations ...........................................59
   15. IANAに関する考慮事項 ..........................................59
      15.1. Attribute Subregistry ....................................59
      15.1. 属性サブレジストリ .......................................59
      15.2. Primitive Subregistry ....................................60
      15.2. プリミティブサブレジストリ ...............................60
      15.3. Request Status Subregistry ...............................61
      15.3. 要求状態サブレジストリ ...................................61
      15.4. Error Code Subregistry ...................................62
      15.4. エラーコードサブレジストリ ...............................62
   16. Acknowledgements ..............................................62
   16. 謝辞 ..........................................................62
   17. References ....................................................63
   17. 参考文献 ......................................................63
      17.1. Normative References .....................................63
      17.1. 規範的な参考文献 .........................................63
      17.2. Informational References .................................63
      17.2. 参考情報 .................................................63
1. Introduction
1. はじめに

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]は、フロア制御プロトコルが満たすべき一連の要件を定めています。本書で規定するBinary Floor Control Protocol（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メッセージの伝送時間を最小限に抑えます。遅延に敏感なメッセージには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では本書全体で使う用語を定義し、セクション3ではBFCPの適用範囲（BFCPが扱うタスクと別の仕組みで行うタスク）を説明します。セクション4ではBFCPの動作を非規範的に概説し、以降のセクションではBFCPの規範的な仕様を示します。

2. Terminology
2. 用語

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」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、BCP 14およびRFC 2119 [1]の説明に従って解釈し、適合する実装に求められる要件レベルを示します。

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.

フロア制御サーバー：存在するフロア、各フロアチェア、およびフロア保持者など、フロアの状態を管理する論理的な主体です。フロアを操作する要求はフロア制御サーバーに送られます。ある会議のフロア制御サーバーが、別の会議ではフロア参加者など別の論理的役割を担うこともあります。

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.

参加者：フロア参加者、メディア参加者、またはその両方として動作する主体です。

3. Scope
3. 範囲

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接続の確立に不可欠です。以下の各節では、これらのタスクと実現方法の一部を説明します。

3.1. Floor Creation
3.1. フロアの作成

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の範囲外であり、会議オブジェクトを操作する会議制御プロトコルで処理します。そのため、フロア制御サーバーは、会議オブジェクトの変更（新しいフロアの作成など）を把握しておく必要があります。

3.2. Obtaining Information to Contact a Floor Control Server
3.2. フロア制御サーバーに連絡するための情報の取得

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 offer/answer [8]の交換を利用できます。その他の方法はXCONフレームワーク[10]および関連文書で説明されています。

3.3. Obtaining Floor-Resource Associations
3.3. フロアとリソースの対応付けの取得

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 offer/answer [8]の交換など、複数の方法でこの情報を取得できます。SDP offer/answer交換を使って対応関係を取得する方法は[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.

フロア参加者は、その会議のconference focusとSDP offer/answerを交換します。そのためconference focusは、フロア参加者とのSDP offer/answer交換で対応関係を伝えられるよう、フロアとリソースの対応情報を取得する必要があります。

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) Focusに提供する方法については、XCONフレームワーク[10]および関連文書で説明されています。

3.4. Privileges of Floor Control
3.4. フロア制御の権限

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]で扱います。

4. Overview of Operation
4. 動作の概要

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（Type-Length-Value）方式のバイナリー符号化を使う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種類があります。クライアント開始トランザクションは、クライアントからフロア制御サーバーへのメッセージと、サーバーからクライアントへの応答で構成されます。両メッセージの共通ヘッダーには同じTransaction ID値が含まれるため、互いに対応付けられます。サーバー開始トランザクションは、フロア制御サーバーからクライアントへ送る単一のメッセージで構成され、そのTransaction IDは0です。

4.1. Floor Participant to Floor Control Server Interface
4.1. フロア参加者とフロア制御サーバー間のインターフェイス

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メッセージでは、共通ヘッダーのUser IDフィールドで要求者を識別し、第三者によるフロア要求の場合はBENEFICIARY-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メッセージに複数のフロア識別子が含まれる場合、フロア制御サーバーはそれらすべてを不可分な1つの要求として扱います。つまり、メッセージ内の全フロアを許可するか、全フロアを拒否します。

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.

フロア制御サーバーは、FloorRequestメッセージに対してFloorRequestStatusメッセージを返し、フロア要求の状態を通知します。最初のFloorRequestStatusメッセージはクライアントのFloorRequestへの応答であるため、FloorRequestと同じTransaction 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.

最初のFloorRequestStatusメッセージには、FLOOR-REQUEST-INFORMATION属性内にFloor Request IDも含まれます。同じフロア要求に関する後続のFloorRequestStatusメッセージも、同じFloor Request 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メッセージと同じFloor Request 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では、フロア参加者がフロアを要求して取得し、後で解放する流れを示します。この図では、Transaction 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への応答であり、FloorQueryと同じTransaction IDを持ちます。

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メッセージはサーバー開始トランザクションであるため、Transaction IDは0です。FloorStatusメッセージ(2)は、Floor IDが543のフロアに対して2件のフロア要求が現在存在することを示します。メッセージ(3)はFloor Request ID 764の要求が許可され、Floor Request ID 635の要求がキューの先頭にあることを示します。メッセージ(4)はFloor Request 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)は、Floor Request ID 635の受益者（要求が許可されたときにフロアを保持する参加者）がUser ID 154の参加者であることを示します。この要求が対象とするのはFloor 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.

複数フロア要求とは、複数のフロアに適用される要求です（たとえば、参加者がホワイトボードで発言しながら同時に書き込む場合です）。フロア制御サーバーは、この要求を不可分な一まとまりとして扱い、すべてのフロアを許可するか、すべて拒否します。

4.2. Floor Chair to Floor Control Server Interface
4.2. フロアチェアとフロア制御サーバー間のインターフェイス

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：フロア制御サーバーを指示するフロアチェア

5. Packet Format
5. パケット形式

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オクテットの共通ヘッダーと、それに続く属性で構成されます。すべてのプロトコル値はネットワークバイトオーダーで送信しなければなりません (MUST)。

5.1. COMMON-HEADER Format
5.1. COMMON-HEADER形式

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：COMMON-HEADER形式

Ver: The 3-bit version field MUST be set to 1 to indicate this version of BFCP.

Ver：3ビットバージョンフィールドは、BFCPのこのバージョンを示すために1に設定しなければなりません (MUST)。

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.

Reserved：この時点では予約フィールドです。メッセージ送信者はこのフィールドの5ビットを0に設定すべきです (SHOULD)。受信者はこのビットを無視しなければなりません (MUST)。

Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined:

Primitive：この8ビットフィールドは、メッセージの主な目的を識別します。次のPrimitive値が定義されています。 

             +-------+--------------------+------------------+
             | 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.

Conference 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).

Transaction ID：このフィールドには、ユーザーが特定のメッセージをその応答と一致させることができる16ビット値が含まれています。サーバー開始トランザクションのTransaction IDの値は0です（セクション8を参照）。

User ID: This field contains a 16-bit value that uniquely identifies a participant within a conference.

User 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.

BFCPで参加者を識別するUser IDフィールドの値は、通常、同じ参加者がセッション確立プロトコル（SIPなど）で使う識別子に対応付けられます。この対応付けの方法は本仕様の適用範囲外です。

5.2. Attribute Format
5.2. 属性形式

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:

Type：この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.

Grouped：属性の内容は一連の属性です。

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：Mandatory bit（必須ビット）とも呼ばれるMビットは、その属性のサポートが必須かどうかを示します。Mビットが1の未認識属性を受信した場合、メッセージは拒否されます。Mビットが意味を持つのは、他の文書で定義される拡張属性だけです。本書で規定するすべての属性は受信側が理解しなければならないため (MUST)、これらの属性では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.

Length：この8ビットフィールドには、属性の長さをオクテット単位で格納します。特定の属性に定義されたパディングは長さに含めません。グループ化されていない属性の長さにはType、Mビット、Lengthの各フィールドを含めます。グループ化属性のLengthは、属性自体（Type、Mビット、Lengthフィールドを含む）の長さと、含まれるすべての属性の長さ（パディングを含む）の合計です。

Attribute Contents: The contents of the different attributes are defined in the following sections.

Attribute Contents：各属性の内容は、次の各節で定義します。

5.2.1. BENEFICIARY-ID
5.2.1. BENEFICIARY-ID

The following is the format of the BENEFICIARY-ID attribute.

以下は、BENEFICIARY-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：BENEFICIARY-ID形式

Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.

Beneficiary 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.

Beneficiary IDフィールドと共通ヘッダーのUser IDフィールドは形式が似ていますが、意味は異なります。Beneficiary IDは、第三者によるフロア要求や特定の参加者に関する情報の要求に使います。

5.2.2. FLOOR-ID
5.2.2. FLOOR-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.

Floor ID：このフィールドには、会議内のフロアを一意に識別する16ビット値が格納されます。

5.2.3. FLOOR-REQUEST-ID
5.2.3. FLOOR-REQUEST-ID

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.

Floor Request ID：このフィールドには、フロア制御サーバー上のフロア要求を識別する16ビット値が格納されます。

5.2.4. PRIORITY
5.2.4. PRIORITY

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：このフィールドには、表3に示す3ビットの優先度値が格納されます。送信者はこのフィールドに4を超える値を設定すべきではありません (SHOULD NOT)。受信者は、4を超える値を受信した場合、受信値を4（最高）として扱わなければなりません (MUST)。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.

Reserved：この時点では予約フィールドです。メッセージ送信者はこのフィールドの13ビットを0に設定すべきです (SHOULD)。受信者はこのビットを無視しなければなりません (MUST)。

5.2.5. REQUEST-STATUS
5.2.5. REQUEST-STATUS

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.

Request Status：この8ビットフィールドには、次の表に示す要求の状態が格納されます。 

                           +-------+-----------+
                           | Value | Status    |
                           +-------+-----------+
                           |   1   | Pending   |
                           |   2   | Accepted  |
                           |   3   | Granted   |
                           |   4   | Denied    |
                           |   5   | Cancelled |
                           |   6   | Released  |
                           |   7   | Revoked   |
                           +-------+-----------+

Table 4: Request Status values

表4：Request Statusの値

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.

Queue Position：この8ビットのフィールドには、該当する場合、サーバーのフロア要求キューにおけるフロア要求の位置が含まれます。Request Status値がAccepted以外である場合、フロア制御サーバーがフロア要求キューを実装していない場合、またはフロア制御サーバーがクライアントにこの情報を提供したくない場合、このフィールドのすべてのビットはゼロに設定されるべきです (SHOULD)。

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.

フロア制御サーバーがフロア要求を受理するためにフロアチェアへ連絡する必要があり、まだ連絡していない場合、要求の状態はPendingです。フロアチェアが要求を受理すると、状態はAcceptedに変わります。

5.2.6. ERROR-CODE
5.2.6. ERROR-CODE

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.

Error Code：この8ビットフィールドには、次の表に示すエラーコードが格納されます。受信側が認識できないエラーコードを受け取った場合、エラーが発生したものとしてメッセージを処理しなければなりません (MUST)。ただし、エラーの内容は不明です。 

   +-------+-----------------------------------------------------------+
   | 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.

Error Specific Details：このフィールドは一部のError Codeでのみ存在します。本書ではError Code 4（Unknown Mandatory Attribute）にだけ存在します。定義はセクション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.

Padding：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.

パディングビットは、送信者によってゼロに設定すべきであり (SHOULD)、受信機は無視しなければなりません (MUST)。

5.2.6.1. Error-Specific Details for Error Code 4
5.2.6.1. エラーコード4に固有の詳細

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.

Unknown Type：これらの7ビットフィールドには、エラーの原因となったメッセージに含まれていた属性のうち、受信側が認識しなかった属性のTypeが格納されます。

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：この時点では予約ビットです。メッセージ送信者は0に設定すべきです (SHOULD)。受信者はこのビットを無視しなければなりません (MUST)。

5.2.7. ERROR-INFO
5.2.7. ERROR-INFO

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.

状況によっては、Textフィールドの内容を自動処理機構が生成する場合があります。その機構が、特定のERROR-INFO属性の受信者が希望する言語を把握していれば、その言語を使ってTextフィールドを生成してもかまいません (MAY)。

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.

Padding：ERROR-INFO属性の内容を32ビット境界に揃えるため、1、2、または3オクテットを追加します。送信側はPaddingビットを0に設定すべきです (SHOULD)。受信側はこれらのビットを無視しなければなりません (MUST)。属性がすでに32ビット境界に揃っている場合、パディングは不要です。

5.2.8. PARTICIPANT-PROVIDED-INFO
5.2.8. PARTICIPANT-PROVIDED-INFO

The following is the format of the PARTICIPANT-PROVIDED-INFO attribute.

以下は、PARTICIPANT-PROVIDED-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：PARTICIPANT-PROVIDED-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.

Padding：PARTICIPANT-PROVIDED-INFO属性の内容を32ビット境界に揃えるため、1、2、または3オクテットを追加します。送信側はPaddingビットを0に設定すべきです (SHOULD)。受信側はこれらのビットを無視しなければなりません (MUST)。属性がすでに32ビット境界に揃っている場合、パディングは不要です。

5.2.9. STATUS-INFO
5.2.9. STATUS-INFO

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.

状況によっては、Textフィールドの内容を自動処理機構が生成する場合があります。その機構が、特定のSTATUS-INFO属性の受信者の希望言語を把握していれば、その言語を使ってTextフィールドを生成してもかまいません (MAY)。

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.

Padding：STATUS-INFO属性の内容を32ビット境界に揃えるため、1、2、または3オクテットを追加します。送信側はPaddingビットを0に設定すべきです (SHOULD)。受信側はこれらのビットを無視しなければなりません (MUST)。属性がすでに32ビット境界に揃っている場合、パディングは不要です。

5.2.10. SUPPORTED-ATTRIBUTES
5.2.10. SUPPORTED-ATTRIBUTES

The following is the format of the SUPPORTED-ATTRIBUTES attribute.

以下にSUPPORTED-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：SUPPORTED-ATTRIBUTES形式

Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format:

Supp. Attr.：これらのフィールドには、フロア制御サーバーがサポートする属性のTypeが次の形式で格納されます。

R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception.

R：予約済み：このビットは、送信時にゼロに設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。

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-ATTRIBUTES属性の内容を32ビット境界に揃えるために追加する2オクテットです。属性の内容がすでに32ビット境界に揃っている場合、パディングは不要です。

The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.

パディングビットは、送信者によってゼロに設定すべきであり (SHOULD)、受信機は無視しなければなりません (MUST)。

5.2.11. SUPPORTED-PRIMITIVES
5.2.11. SUPPORTED-PRIMITIVES

The following is the format of the SUPPORTED-PRIMITIVES attribute.

以下は、SUPPORTED-PRIMITIVES属性の形式です。 

      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：SUPPORTED-PRIMITIVES形式

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.

Primitive：これらのフィールドには、フロア制御サーバーがサポートする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.

Padding：SUPPORTED-PRIMITIVES属性の内容を32ビット境界に揃えるため、1、2、または3オクテットを追加します。属性がすでに32ビット境界に揃っている場合、パディングは不要です。

The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.

パディングビットは、送信者によってゼロに設定すべきであり (SHOULD)、受信機は無視しなければなりません (MUST)。

5.2.12. USER-DISPLAY-NAME
5.2.12. USER-DISPLAY-NAME

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～3オクテットです。送信者はパディングビットを0に設定すべきです (SHOULD)。受信者はそのビットを無視しなければなりません (MUST)。属性の内容がすでに32ビット境界に揃っている場合、パディングは不要です。

5.2.13. USER-URI
5.2.13. USER-URI

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.

Text：このフィールドには、ユーザーの連絡先URIをUTF-8で符号化した値が含まれます。これは、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を含むメッセージには、そのユーザーのUser IDも含まれます。これにより、そのようなメッセージを受信するクライアントは、ユーザーのURI（たとえば会議への参加に使ったSIP URI）とUser IDを対応付けられます。

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～3オクテットです。送信者はパディングビットを0に設定すべきです (SHOULD)。受信者はそのビットを無視しなければなりません (MUST)。属性の内容がすでに32ビット境界に揃っている場合、パディングは不要です。

5.2.14. BENEFICIARY-INFORMATION
5.2.14. BENEFICIARY-INFORMATION

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:

BENEFICIARY-INFORMATION属性はグループ化属性です。BENEFICIARY-INFORMATION-HEADERというヘッダーに続いて、属性の並びで構成されます。以下にBENEFICIARY-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-INFORMATION-HEADERの形式

Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.

Beneficiary 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.)

以下に、BENEFICIARY-INFORMATIONグループ化属性のABNF（拡張バッカス・ナウア形式）[2]を示します。（EXTENSION-ATTRIBUTEは、将来定義される拡張属性を指します。） 

   BENEFICIARY-INFORMATION =   (BENEFICIARY-INFORMATION-HEADER)
                               [USER-DISPLAY-NAME]
                               [USER-URI]
                              *[EXTENSION-ATTRIBUTE]

Figure 22: BENEFICIARY-INFORMATION format

図22：BENEFICIARY-INFORMATION形式

5.2.15. FLOOR-REQUEST-INFORMATION
5.2.15. FLOOR-REQUEST-INFORMATION

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-REQUEST-INFORMATION属性はグループ化属性です。FLOOR-REQUEST-INFORMATION-HEADERというヘッダーに続いて、属性の並びで構成されます。以下に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-INFORMATION-HEADERの形式

Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.

Floor Request 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-ATTRIBUTEは、将来定義される拡張属性を指します。） 

   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]

Figure 24: FLOOR-REQUEST-INFORMATION format

図23：FLOOR-REQUEST-INFORMATION-HEADER形式

5.2.16. REQUESTED-BY-INFORMATION
5.2.16. REQUESTED-BY-INFORMATION

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-INFORMATION-HEADERというヘッダーに続いて、属性の並びで構成されます。以下にREQUESTED-BY-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 1 0 0 0 0|M|    Length     |       Requested-by ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 25: REQUESTED-BY-INFORMATION-HEADER format

図25：REQUESTED-BY-INFORMATION-HEADERの形式

Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference.

Requested-by 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.)
   REQUESTED-BY-INFORMATION =   (REQUESTED-BY-INFORMATION-HEADER)
                                [USER-DISPLAY-NAME]
                                [USER-URI]
                               *[EXTENSION-ATTRIBUTE]

Figure 26: REQUESTED-BY-INFORMATION format

図26：REQUESTED-BY-INFORMATIONの形式

5.2.17. FLOOR-REQUEST-STATUS
5.2.17. FLOOR-REQUEST-STATUS

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-HEADERというヘッダーに続いて、属性の並びで構成されます。以下に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.

Floor 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-ATTRIBUTEは、将来定義される拡張属性を指します。） 

   FLOOR-REQUEST-STATUS     =   (FLOOR-REQUEST-STATUS-HEADER)
                                [REQUEST-STATUS]
                                [STATUS-INFO]
                               *[EXTENSION-ATTRIBUTE]

Figure 28: FLOOR-REQUEST-STATUS format

図28：FLOOR-REQUEST-STATUS形式

5.2.18. OVERALL-REQUEST-STATUS
5.2.18. OVERALL-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-HEADERというヘッダーに続いて、属性の並びで構成されます。以下にOVERALL-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：OVERALL-REQUEST-STATUS-HEADERの形式

Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server.

Floor Request 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.)

以下に、OVERALL-REQUEST-STATUSグループ化属性のABNFを示します。（EXTENSION-ATTRIBUTEは、将来定義される拡張属性を指します。） 

   OVERALL-REQUEST-STATUS   =   (OVERALL-REQUEST-STATUS-HEADER)
                                [REQUEST-STATUS]
                                [STATUS-INFO]
                               *[EXTENSION-ATTRIBUTE]

Figure 30: OVERALL-REQUEST-STATUS format

図30：OVERALL-REQUEST-STATUS形式

5.3. Message Format
5.3. メッセージ形式

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-ATTRIBUTEと表します。

5.3.1. FloorRequest
5.3.1. FloorRequest

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]

Figure 31: FloorRequest format

図31：FloorRequest形式

5.3.2. FloorRelease
5.3.2. FloorRelease

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 =   (COMMON-HEADER)
                    (FLOOR-REQUEST-ID)
                   *[EXTENSION-ATTRIBUTE]

Figure 32: FloorRelease format

図32：FloorReleaseの形式

5.3.3. FloorRequestQuery
5.3.3. FloorRequestQuery

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]

Figure 33: FloorRequestQuery format

図33：FloorRequestQuery形式

5.3.4. FloorRequestStatus
5.3.4. FloorRequestStatus 
   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 =   (COMMON-HEADER)
                          (FLOOR-REQUEST-INFORMATION)
                         *[EXTENSION-ATTRIBUTE]

Figure 34: FloorRequestStatus format

図34：FloorRequestStatus形式

5.3.5. UserQuery
5.3.5. UserQuery

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]

Figure 35: UserQuery format

図35：UserQueryの形式

5.3.6. UserStatus
5.3.6. UserStatus

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]

Figure 36: UserStatus format

図36：UserStatus形式

5.3.7. FloorQuery
5.3.7. FloorQuery

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メッセージをフロア制御サーバーに送信して、1つ以上のフロアに関する情報を求めます。以下に原文の記載どおりFloorRequestメッセージの形式を示します。 

   FloorQuery =   (COMMON-HEADER)
                 *(FLOOR-ID)
                 *[EXTENSION-ATTRIBUTE]

Figure 37: FloorQuery format

図37：FloorQueryの形式

5.3.8. FloorStatus
5.3.8. FloorStatus

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]

Figure 38: FloorStatus format

図38：FloorStatus形式

5.3.9. ChairAction
5.3.9. ChairAction

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]

Figure 39: ChairAction format

図39：ChairActionの形式

5.3.10. ChairActionAck
5.3.10. ChairActionAck

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メッセージを送信することにより、フロアチェアのメッセージを受け入れたことを確認します。以下は、ChairActionAckメッセージの形式です。 

   ChairActionAck  =   (COMMON-HEADER)
                      *[EXTENSION-ATTRIBUTE]

Figure 40: ChairActionAck format

図40：ChairActionAckの形式

5.3.11. Hello
5.3.11. Hello

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]

Figure 41: Hello format

図41：Hello形式

5.3.12. HelloAck
5.3.12. HelloAck

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:

フロア制御サーバーはHelloメッセージを受信すると、HelloAckメッセージを送信して自らが稼働中であることを確認します。以下にHelloAckメッセージの形式を示します。 

   HelloAck      =  (COMMON-HEADER)
                    (SUPPORTED-PRIMITIVES)
                    (SUPPORTED-ATTRIBUTES)
                   *[EXTENSION-ATTRIBUTE]

Figure 42: HelloAck format

図42：HelloAck形式

5.3.13. Error
5.3.13. Error

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メッセージを送信し、要求の処理中に発生したエラーをフロア参加者とフロアチェアに通知します。以下にErrorメッセージの形式を示します。 

   Error              =   (COMMON-HEADER)
                          (ERROR-CODE)
                          [ERROR-INFO]
                         *[EXTENSION-ATTRIBUTE]

Figure 43: Error format

図43：エラー形式

6. Transport
6. トランスポート

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.

クライアントは、1つの会議内で特定のフロア制御サーバーと通信するために、複数のTCP接続を使ってはなりません (MUST NOT)。ただし、同じ物理装置が異なるUser 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接続を閉じなければなりません (MUST)。接続は再確立すべきです (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接続が再確立されると、クライアントはフロア制御サーバーから応答が得られなかったメッセージを再送信できます (MAY)。

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接続を再確立する間、フロア制御サーバーがフロア要求を保持し（すなわち取り消さずにおく）ことが推奨されます (RECOMMENDED)。

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接続を終了する場合（たとえば、会議のFocusからクライアントが会議から退出させられたと通知された場合）も、クライアント側へのTCP接続を正常に閉じます。

7. Lower-Layer Security
7. 下位層のセキュリティ

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は、リプレイ攻撃や改変への対策、および機密性を提供する下位層のセキュリティ機構に依存します。フロア制御サーバーとクライアント（フロア参加者およびフロアチェア）はTLS [3]をサポートしなければなりません (MUST)。BFCPエンティティは他のセキュリティ機構もサポートしてもよい (MAY) です。

BFCP entities MUST support, at a minimum, the TLS TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].

BFCPエンティティは、少なくとも暗号スイートTLS_RSA_WITH_AES_128_CBC_SHA [5]をサポートしなければなりません (MUST)。

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接続の確立方法によって決まります。たとえば、SDP offer/answer交換[7]でTCP接続を確立する場合、クライアントまたはフロア制御サーバーのいずれがAnswererであっても、AnswererがTLSサーバーとして動作します。

8. Protocol Transactions
8. プロトコルトランザクション

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種類があります。クライアント開始トランザクションは、クライアントからフロア制御サーバーへの要求と、サーバーからクライアントへの応答で構成されます。要求の共通ヘッダーにはTransaction IDが含まれ、フロア制御サーバーはその値を応答にコピーします。クライアントはTransaction 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.

サーバー開始トランザクションは、フロア制御サーバーからクライアントに送る単一のメッセージで構成されます。応答を引き起こさないため、Transaction IDは0に設定されます。

8.1. Client Behavior
8.1. クライアントの動作

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.

クライアント開始トランザクションを開始するクライアントは、以前に取得した会議のConference IDをメッセージの共通ヘッダーに設定しなければなりません (MUST)。

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.

クライアントは、共通ヘッダーのTransaction ID値を0とは異なる数値に設定しなければなりません (MUST)。これは、トランザクションのサーバーからの応答が受信されるまで、クライアントからの別のメッセージに再利用してはなりません (MUST NOT)。クライアントは、Transaction ID値を使用して、このメッセージをフロア制御サーバーからの応答と一致させます。

8.2. Server Behavior
8.2. サーバーの動作

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.

クライアントが開始したトランザクション内で応答を送信するフロア制御サーバーは、クライアントから受け取ったリクエストから、Conference ID、Transaction ID、およびUser IDを応答にコピーしなければなりません (MUST)。サーバー開始トランザクションには、0に等しいTransaction IDが含まれていなければなりません (MUST)。

9. Authentication and Authorization
9. 認証と認可

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メッセージを受け入れるべきです (SHOULD)。同様に、フロア制御サーバーは、BFCPメッセージを受け入れる前にクライアントを認証するか、BFCPメッセージを送信すべきです (SHOULD)。

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.

BFCPは、セクション9.1で規定するクライアントとフロア制御サーバー間のTLSベース相互認証をサポートします。BFCPでは、この認証方式が推奨されます (RECOMMENDED)。

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メッセージを受信すると、フロア制御サーバーは送信クライアントが認可されているか確認します。クライアントに要求された操作を行う権限がない場合、フロア制御サーバーはセクション13.8に従い、値5（Unauthorized Operation）のError Codeを含むErrorメッセージを生成します。認可できないクライアントからのメッセージを、それ以上処理してはなりません (MUST NOT)。

9.1. TLS-Based Mutual Authentication
9.1. TLSベースの相互認証

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.

認証済みTLS接続を介して受信したBFCPメッセージは、認証済みと見なされます。TCP（TLSなし）でBFCPメッセージを受信したフロア制御サーバーは、セクション13.8に従い、Error Codeの値が9（Use TLS）のErrorメッセージを生成してTLSの使用を要求できます。クライアントは未認証のメッセージを単に無視すべきです (SHOULD)。

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接続を介して到着したメッセージが、認可されたUser ID（つまり、その認証済みTLS接続を確立したユーザーが使用を許可されているUser ID）を使用していることを確認すべきです (SHOULD)。

10. Floor Participant Operations
10. フロア参加者の操作

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は、任意のクライアント（つまり、フロア参加者とフロアチェアの両方）が実行できる操作を指定します。

10.1. Requesting a Floor
10.1. フロアの要求

A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.

フロア参加者は、1つ以上のフロアを要求するため、FloorRequestメッセージをフロア制御サーバーに送信します。

10.1.1. Sending a FloorRequest Message
10.1.1. 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に記載されているルールに従って、共通ヘッダーにConference IDとTransaction 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.

フロア参加者は、共通ヘッダーのUser IDに自身の識別子を設定します。フロア制御サーバーは、このUser IDを使って要求を認証および認可します。FloorRequestメッセージの送信者（User IDで識別される参加者）が、最終的にフロアを得る参加者と異なる場合（第三者によるフロア要求）、送信者はフロアの受益者を示すBENEFICIARY-ID属性をメッセージに追加すべきです (SHOULD)。

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.

User IDとBeneficiary IDの名前空間は共通です。つまり、各参加者は単一の16ビット値で識別され、その値は共通ヘッダーのUser IDと、BENEFICIARY-ID、BENEFICIARY-INFORMATION、REQUESTED-BY-INFORMATIONの各属性で使用されます。

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.

フロア参加者は、フロアを要求する理由を示すためにPARTICIPANT-PROVIDED-INFO属性を使用できます。この属性のTextフィールドは、人が読むための情報を格納します。

The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute.

フロア参加者は、PRIORITY属性を使って、特定の優先度でフロア要求を処理するようサーバーに求めることができます。

10.1.2. Receiving a Response
10.1.2. 応答の受信

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.

フロア制御サーバーからのメッセージは、セクション8.1で説明したとおり、FloorRequestメッセージと同じConference ID、Transaction ID、User IDを持つ場合、その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属性内にあるFloor Request IDフィールドから、Floor Request IDを取得します。同じ要求についてサーバーが後続のFloorRequestStatusメッセージを送信する場合も、最初のメッセージと同じFloor Request IDを含むFLOOR-REQUEST-INFORMATION属性を使います。これにより、フロア参加者は後続メッセージを進行中の要求に対応付けられます。

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属性は、フロア要求全体の状態を示します。Request Status値がGrantedなら、FloorRequestメッセージで要求されたすべてのフロアが付与されています。値がDeniedなら、要求されたすべてのフロアが拒否されています。フロア要求は、状態がPending、Accepted、またはGrantedである間、進行中と見なされます。フロア要求の状態値が不明でも応答は処理しますが、ユーザーに意味のある値を報告することはできません。

The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.

STATUS-INFO属性が存在する場合、フロア参加者がユーザーに表示してもよい (MAY) 追加情報を提供します。

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属性が存在する場合、フロア参加者がユーザーに表示してもよい (MAY) 追加情報を提供します。

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.

BENEFICIARY-INFORMATION属性は、第三者フロア要求におけるフロア要求の受益者を識別します。フロアを要求したフロア参加者は共通ヘッダーのUser IDですでに識別されているため、その参加者が受信するFloorRequestStatusメッセージにはREQUESTED-BY-INFORMATION属性を含める必要はありません。

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メッセージを処理できませんでした。これはエラーメッセージで説明されています。

10.2. Cancelling a Floor Request and Releasing a Floor
10.2. フロア要求の取消しとフロアの解放

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メッセージは、付与済みのフロアを保持しているフロア参加者が、そのフロアを解放する場合にも使います。

10.2.1. Sending a FloorRelease Message
10.2.1. 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の規則に従って、共通ヘッダーにConference IDとTransaction IDを設定します。また、共通ヘッダーのUser IDにはフロア参加者の識別子を設定します。フロア制御サーバーは、このUser 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.

フロア参加者は、取り消すFloorRequestに対する応答で受信したFLOOR-REQUEST-IDをFloorReleaseメッセージに設定します。

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).

フロア参加者が複数のフロアを不可分な操作として要求した場合（つまり、1つのFloorRequestメッセージで要求した場合）、それらのフロアも不可分な操作として解放されます（つまり、すべて同時に解放されます）。

10.2.2. Receiving a Response
10.2.2. 応答の受信

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.

フロア制御サーバーからのメッセージは、セクション8.1の説明どおり、FloorRequestメッセージと同じConference ID、Transaction ID、User IDを持つ場合、FloorReleaseメッセージへの応答と見なされます（原文では比較対象をFloorRequestメッセージと記載しています）。この応答を受信したフロア参加者は、フロア制御サーバーの認証に関するセクション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メッセージの場合、OVERALL-REQUEST-STATUS属性（FLOOR-REQUEST-INFORMATIONグループ化属性内）のRequest Status値はCancelledまたはReleasedです。

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メッセージと、CancelledまたはReleased以外のRequest Statusを含むFloorRequestStatusメッセージが通信路上ですれ違う場合があります。いずれにしても、そのFloorRequestStatusメッセージのTransaction IDはFloorReleaseのTransaction IDと一致しないため、FloorReleaseへの応答ではありません。

11. Chair Operations
11. フロアチェアの操作

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メッセージを送信します。

11.1. Sending a ChairAction Message
11.1. 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メッセージに含められる属性を定義します。また、含めることが必須の属性と任意の属性も規範的に定めています。

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の規則に従って、共通ヘッダーにConference IDとTransaction IDを設定します。また、共通ヘッダーのUser IDにはフロア参加者の識別子を設定します。フロア制御サーバーは、このUser 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つ以上のフロアに適用する指示が含まれます。フロアはFLOOR-REQUEST-STATUS属性で識別し、フロア要求はChairActionメッセージに含まれるFLOOR-REQUEST-INFORMATION-HEADERで識別します。

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属性を使って、特定のフロアに関するフロア要求の新しい状態を示します。新しい状態がAcceptedの場合、Queue Positionフィールドを使ってフロア要求のキュー位置を示してもよい (MAY) です。キュー位置を示さない場合、Queue Positionフィールドの全ビットを0にすべきです (SHOULD)。付与済みのフロアを取り消すにはStatus Revokedを使うべきです (SHOULD)。それ以外の状態（PendingやAcceptedなど）にあるフロア要求を拒否するにはStatus Deniedを使うべきです (SHOULD)。

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属性を追加してもよい (MAY) です。新しい全体状態がAcceptedの場合、Queue Positionフィールドを使ってフロア要求のキュー位置を示してもよい (MAY) です。

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.

フロア制御サーバーは、フロアごとにそのフロアに関するすべての要求を格納する個別のキュー、すべてのフロア要求を格納する共通キュー、またはその両方を実装できます。また、1つのフロア要求が複数のフロアに関係していても、ChairActionメッセージがその一部のフロアだけを扱う場合があります（たとえば、1人のフロアチェアにすべてのフロアを管理する権限がない場合）。この場合、フロア制御サーバーは、各フロアチェアから受信した指示を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.

フロアチェアの操作はOVERALL-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属性のTextは、人が読むための情報です。

11.2. Receiving a Response
11.2. 応答の受信

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.

サーバーからのメッセージは、セクション8.1の説明どおり、ChairActionメッセージと同じConference ID、Transaction ID、User IDを持つ場合、その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メッセージを受け入れたことを確認します。Errorメッセージは、記載された理由によりサーバーがChairActionメッセージを処理できなかったことを示します。

12. General Client Operations
12. クライアントの一般的な操作

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.

このセクションでは、フロア参加者とフロアチェアのどちらも実行できる、すべてのクライアントに共通する操作を規定します。

12.1. Requesting Information about Floors
12.1. フロアに関する情報の要求

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や帯域外の仕組みなど、さまざまな方法で1つ以上のフロアの状態を取得できます。BFCPを使って取得するクライアントは、このセクションの手順に従います。

Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.

クライアントは、FloorQueryメッセージをフロア制御サーバーに送信することにより、1つまたは複数のフロアのステータスに関する情報を要求します。

12.1.1. Sending a FloorQuery Message
12.1.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の規則に従って、共通ヘッダーにConference IDとTransaction IDを設定します。また、共通ヘッダーのUser IDにはクライアントの識別子を設定します。フロア制御サーバーは、このUser 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.

クライアントは、情報を受け取りたいすべてのフロアのFLOOR-IDをメッセージに設定します。フロア制御サーバーは、これらすべてのフロアの情報を定期的に送信します。特定のフロアの情報が不要になった場合、クライアントはそのフロアのFLOOR-IDを除いた新しいFloorQueryメッセージを送ります。どのフロアの情報も不要になった場合は、FLOOR-ID属性を含まないFloorQueryメッセージを送ります。

12.1.2. Receiving a Response
12.1.2. 応答の受信

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 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メッセージと同じConference ID、Transaction ID、User IDを持つ場合、FloorQueryメッセージへの応答と見なされます（原文では比較対象を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メッセージまたはErrorメッセージで応答します。FloorStatusメッセージには、クライアントが情報を要求したフロアのいずれかに関する情報が含まれます。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メッセージには、そのフロアに関係する既存の1つ以上のフロア要求の情報が含まれます。各フロア要求の情報はFLOOR-REQUEST-INFORMATION属性に格納されます。このグループ化属性には、フロア要求を識別するFloor Request 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メッセージを継続して送信し、クライアントが情報を要求したフロアの変化を定期的に通知します。

12.2. Requesting Information about Floor Requests
12.2. フロア要求に関する情報の要求

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メッセージを受信したフロア制御サーバーが、要求の状態が変わったとき（AcceptedからGrantedへの遷移など）だけFloorRequestStatusメッセージを返し、要求がキュー内で進んだときには返さない場合があります。このとき利用者から求められれば、フロア参加者はFloorRequestQueryメッセージを使ってフロア要求の状態をポーリングできます。

12.2.1. Sending a FloorRequestQuery Message
12.2.1. 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に記載されているルールに従って、共通ヘッダーにConference IDとTransaction IDを設定します。クライアントは、User IDを共通ヘッダーにクライアントの識別子に設定します。このUser IDは、フロア制御サーバーによって使用され、リクエストを認証および認可します。

The client must insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.

クライアントは、フロア制御サーバーのフロア要求を識別するFLOOR-REQUEST-ID属性を挿入する必要があります。

12.2.2. Receiving a Response
12.2.2. 応答の受信

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.

フロア制御サーバーからのメッセージは、セクション8.1の説明どおり、FloorRequestQueryメッセージと同じConference ID、Transaction ID、User IDを持つ場合、その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メッセージの場合、クライアントは、要求したFloorRequestの状態をFLOOR-REQUEST-INFORMATION属性から取得します。

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メッセージを処理できませんでした。

12.3. Requesting Information about a User
12.3. 利用者に関する情報の要求

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接続が一時的に切断された後に再確立された場合、フロア参加者は、自分に関連付けられたまま残っているすべてのフロア要求について情報を求めることがあります。

12.3.1. Sending a UserQuery Message
12.3.1. UserQueryメッセージの送信

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に記載されているルールに従って、共通ヘッダーにConference IDとTransaction IDを設定します。クライアントは、User IDを共通ヘッダーにクライアントの識別子に設定します。このUser 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.

クライアントが情報を求めるフロア参加者がUserQueryメッセージを送信するクライアントと異なる場合（送信クライアントはメッセージの共通ヘッダーにあるUser IDで識別されます）、クライアントはBENEFICIARY-ID属性を挿入しなければなりません (MUST)。

12.3.2. Receiving a Response
12.3.2. 応答の受信

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.

フロア制御サーバーからのメッセージは、セクション8.1の説明どおり、UserQueryメッセージと同じConference ID、Transaction ID、User IDを持つ場合、その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メッセージの場合、クライアントはBENEFICIARY-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メッセージを処理できませんでした。これはエラーメッセージで説明されています。

12.4. Obtaining the Capabilities of a Floor Control Server
12.4. フロア制御サーバーの機能の取得

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メッセージを送信します。

12.4.1. Sending a Hello Message
12.4.1. 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メッセージに含められる属性と、そのうち必須の属性および任意の属性を規範的に定めています。

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に記載されているルールに従って、共通ヘッダーにConference IDとTransaction IDを設定します。クライアントは、User IDを共通ヘッダーにクライアントの識別子に設定します。このUser IDは、フロア制御サーバーによって使用され、リクエストを認証および認可します。

12.4.2. Receiving Responses
12.4.2. 応答の受信

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メッセージと同じConference ID、Transaction ID、User 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.

応答がエラーメッセージである場合、フロア制御サーバーは何らかの理由でハローメッセージを処理できませんでした。これはエラーメッセージで説明されています。

13. Floor Control Server Operations
13. フロア制御サーバーの操作

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).

クライアントからメッセージを受信すると、フロア制御サーバーはPrimitiveの値がサポートされているか確認しなければなりません (MUST)。サポートされていない場合、フロア制御サーバーはセクション13.8の説明に従い、Error Code 3（Unknown Primitive）のErrorメッセージを送信すべきです (SHOULD)。

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).

クライアントからメッセージを受信すると、フロア制御サーバーはConference IDの値が既存の会議と一致するか確認しなければなりません (MUST)。一致しない場合、フロア制御サーバーはセクション13.8の説明に従い、Error Code 1（Conference does not Exist）のErrorメッセージを送信すべきです (SHOULD)。

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ビットが設定された属性）をすべて理解できるか確認しなければなりません (MUST)。すべてを理解できない場合、セクション13.8の説明に従い、エラーコード2（Authentication Failed）を含むErrorメッセージを送信すべきです (SHOULD)。Errorメッセージには、理解できなかった属性を列挙すべきです (SHOULD)。

13.1. Reception of a FloorRequest Message
13.1. FloorRequestメッセージの受信

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の手順に従いError応答を生成すべきです (SHOULD)。

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件）を設けるフロア制御サーバーは、Error Code 8（You have Already Reached the Maximum Number of Ongoing Floor Requests for this Floor）を使って参加者に通知できます。

13.1.1. Generating the First FloorRequestStatus Message
13.1.1. 最初のFloorRequestStatusメッセージの生成

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メッセージを生成します。その最初のメッセージは、できるだけ早く生成すべきです (SHOULD)。フロア制御サーバーがフロア要求を直ちに受け入れ、付与、または拒否できない場合（例えば、フロアチェアの判断が必要な場合）、最初に生成するFloorRequestStatusメッセージのFLOOR-REQUEST-INFORMATIONグループ化属性内にあるOVERALL-REQUEST-STATUS属性では、PendingのRequest Status値を使うべきです (SHOULD)。

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 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の説明どおり、FloorRequestからConference ID、Transaction ID、User IDをFloorRequestStatusにコピーしなければなりません (MUST)。また、フロア要求の情報を格納するFLOOR-REQUEST-INFORMATIONグループ化属性をFloorRequestStatusに追加しなければなりません (MUST)。

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.

フロア制御サーバーは、このフロア要求に会議内で一意となる識別子を割り当てなければなりません (MUST)。また、その識別子をFLOOR-REQUEST-INFORMATION属性のFloor Request IDフィールドに設定しなければなりません (MUST)。フロア参加者または1人以上のフロアチェアは、以後この識別子を使って当該フロア要求を参照します。

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).

フロア制御サーバーは、FloorRequestメッセージの各FLOOR-ID属性に含まれるFloor IDを、FLOOR-REQUEST-INFORMATIONグループ化属性内のFLOOR-REQUEST-STATUS属性にコピーしなければなりません (MUST)。これらのFloor 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.

フロア制御サーバーは、FloorRequestのBENEFICIARY-ID属性の内容を（属性があれば）FLOOR-REQUEST-INFORMATIONグループ化属性内のBENEFICIARY-INFORMATION属性にコピーすべきです (SHOULD)。さらに、BENEFICIARY-INFORMATION属性に受益者の表示名とURIを含めてもかまいません (MAY)。

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属性に、フロア要求者の情報を含めてもよい (MAY) です。

The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.

フロア制御サーバーは、FloorRequestのPARTICIPANT-PROVIDED-INFO属性を（属性があれば）FLOOR-REQUEST-INFORMATIONグループ化属性にコピーしてもかまいません (MAY)。

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.

この属性には、参加者が要求した優先度が格納されます。フロア制御サーバーがフロア要求に割り当てる優先度は、参加者が要求した優先度と、会議ポリシーに基づく参加者の権限によって決まります。たとえば、Normal優先度しか使う権限がない参加者が、フロア要求にHighest優先度を要求することがあります。その場合、フロア制御サーバーは参加者の要求した優先度を無視します。

The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.

フロア制御サーバーは、FloorRequestのPARTICIPANT-PROVIDED-INFO属性を（属性があれば）FLOOR-REQUEST-INFORMATIONグループ化属性にコピーしてもかまいません (MAY)。

13.1.2. Generation of Subsequent FloorRequestStatus Messages
13.1.2. 後続のFloorRequestStatusメッセージの生成

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.

フロア要求は、状態がCancelled、Released、Revokedのいずれでもない間、進行中と見なされます。フロア制御サーバーが最初に生成した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.)

フロア要求の状態が変わった場合、フロア制御サーバーは適切なRequest Statusを含むFloorRequestStatusメッセージを新たに送信すべきです (SHOULD)。同じフロア要求に関する後続の各FloorRequestStatusメッセージには、最初のFloorRequestStatusメッセージで送信したものと同じFloor Request IDを持つFLOOR-REQUEST-INFORMATION属性を含めなければなりません (MUST)。（Floor Request IDは、FloorRequestStatusが適用されるフロア要求を識別します。）

The floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0.

フロア制御サーバーは、後続のFloorRequestStatusメッセージのTransaction IDを0に設定しなければなりません (MUST)。

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メッセージを送る一方、別のサーバーは要求がGrantedまたはDeniedになったときだけ送ることがあります。

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.

フロア要求の状態がCancelled、Released、またはRevokedになった時点で、フロア制御サーバーはその要求に関する状態情報を破棄できます。

13.2. Reception of a FloorRequestQuery Message
13.2. FloorRequestQueryメッセージの受信

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の手順に従ってError応答を生成すべきです (SHOULD)。

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メッセージを生成します。この応答はできるだけ早く生成すべきです (SHOULD)。

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の説明どおり、FloorRequestQueryメッセージからConference ID、Transaction ID、User IDをFloorRequestStatusメッセージにコピーしなければなりません (MUST)。さらに、FloorRequestStatusのFLOOR-REQUEST-INFORMATIONグループ化属性にフロア要求の情報を含めなければなりません (MUST)。

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.

フロア制御サーバーは、FloorRequestQueryメッセージのFLOOR-REQUEST-ID属性の内容を、FLOOR-REQUEST-INFORMATION属性のFloor Request IDフィールドにコピーしなければなりません (MUST)。

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-INFORMATIONのグループ化された属性に追加しなければなりません (MUST)（つまり、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.

フロア制御サーバーは、フロア要求の受益者を識別するBENEFICIARY-ID属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加すべきです (SHOULD)。さらに、BENEFICIARY-INFORMATION属性に受益者の表示名とURIを含めてもよい (MAY) です。

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属性に、フロア要求者の情報を含めてもよい (MAY) です。

The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

フロア制御サーバーは、フロア参加者がPARTICIPANT-PROVIDED-INFOでフロアを要求した理由を提供する場合があります (MAY)。

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.

フロア制御サーバーは、フロア要求に指定されたPriority値を持つPRIORITY属性と、フロア要求に関する追加情報を持つSTATUS-INFO属性を、FLOOR-REQUEST-INFORMATIONグループ化属性に追加してもよい (MAY) です。

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.

フロア制御サーバーは、フロア要求の現在の状態を示すOVERALL-REQUEST-STATUS属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加しなければなりません (MUST)。また、要求された各フロアの状態をFLOOR-REQUEST-STATUS属性で示してもかまいません (MAY)。

13.3. Reception of a UserQuery Message
13.3. UserQueryメッセージの受信

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の手順に従ってError応答を生成すべきです (SHOULD)。

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メッセージが生成されます。このメッセージは、できるだけ早く生成されるべきです (SHOULD)。

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の説明どおり、UserQueryメッセージからConference ID、Transaction ID、User IDをUSerStatusメッセージにコピーしなければなりません (MUST)。

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メッセージの送信者は、特定の参加者に関連するすべてのフロア要求、すなわちその参加者が受益者または要求者であるフロア要求について情報を求めています。この参加者は、BENEFICIARY-ID属性があればその属性で識別され、なければUserQueryメッセージの共通ヘッダーにあるUser 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.

フロア制御サーバーは、UserQueryメッセージにBENEFICIARY-ID属性があれば、その内容をUserStatusメッセージのBENEFICIARY-INFORMATION属性にコピーしなければなりません (MUST)。さらに、UserStatusメッセージが情報を返す対象の参加者について、表示名とURIをこのBENEFICIARY-INFORMATION属性に含めてもよい (MAY) です。

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.

フロア制御サーバーは、情報を返す対象の参加者に関連するフロア要求ごとに、FLOOR-REQUEST-INFORMATIONグループ化属性をUserStatusメッセージに追加すべきです (SHOULD)。ここで対象となるのは、その参加者が受益者または要求者であるフロア要求です。各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.

フロア制御サーバーは、FLOOR-REQUEST-INFORMATION属性のFloor Request IDフィールドを設定して、その属性がどのフロア要求に適用されるかを識別しなければなりません (MUST)。

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-INFORMATIONのグループ化された属性に追加しなければなりません (MUST)（つまり、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.

フロア制御サーバーは、フロア要求の受益者を識別するBENEFICIARY-ID属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加すべきです (SHOULD)。さらに、BENEFICIARY-INFORMATION属性に受益者の表示名とURIを含めてもよい (MAY) です。

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属性に、フロア要求者の情報を含めてもよい (MAY) です。

The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

フロア制御サーバーは、フロア参加者がPARTICIPANT-PROVIDED-INFOでフロアを要求した理由を提供する場合があります (MAY)。

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.

フロア制御サーバーは、フロア要求に指定されたPriority値を持つPRIORITY属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加してもよい (MAY) です。

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.

フロア制御サーバーは、フロア要求の現在の状態をOVERALL-REQUEST-STATUS属性に含め、その属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加しなければなりません (MUST)。フロア制御サーバーは、フロア要求に関する補足情報をSTATUS-INFO属性で追加してもかまいません (MAY)。

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-STATUS属性で示してもよい (MAY) です。

13.4. Reception of a FloorRelease Message
13.4. FloorReleaseメッセージの受信

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の手順に従ってError応答を生成すべきです (SHOULD)。

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メッセージを生成します。この応答はできるだけ早く生成すべきです (SHOULD)。

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の説明に従い、FloorReleaseメッセージのConference ID、Transaction ID、およびUser IDをFloorRequestStatusメッセージにコピーしなければなりません (MUST)。

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.

フロア制御サーバーは、フロア要求の情報を格納するFLOOR-REQUEST-INFORMATIONグループ化属性をFloorRequestStatusに追加しなければなりません (MUST)。このグループ化属性に含まれる属性は、フロア要求に関する情報を示します。

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メッセージはFLOOR-REQUEST-IDを使って対象のフロア要求を識別します。フロア制御サーバーはFloorReleaseメッセージのFLOOR-REQUEST-ID属性の内容を、FLOOR-REQUEST-INFORMATION属性のFloor Request IDフィールドにコピーしなければなりません (MUST)。

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-ID属性で識別されるフロア要求に関連付けられたフロア）をFLOOR-REQUEST-STATUS属性で識別し、FLOOR-REQUEST-INFORMATIONグループ化属性に含めなければなりません (MUST)。

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属性を追加しなければなりません (MUST)。フロアが以前に付与されていた場合、Request Status値はReleasedとすべきです (SHOULD)。以前に付与されていなかった場合はCancelledです。フロア制御サーバーは、フロア要求に関する追加情報をSTATUS-INFO属性に含めてもよい (MAY) です。

13.5. Reception of a FloorQuery Message
13.5. FloorQueryメッセージの受信

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の規則に従います。処理中にエラーが発生した場合、セクション13.8の手順に従ってError応答を生成すべきです (SHOULD)（原文では、この箇所をFloorReleaseメッセージの処理中と記載しています）。

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属性によって識別されたフロアのステータスについて、このクライアントに情報を提供すべきです (SHOULD)。フロア制御サーバーは、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メッセージで返す情報は、情報を要求する利用者によって異なる場合があります。例えば、フロアチェアは保留中の要求に関する情報を受け取れる一方、一般の利用者にはその権限がない場合があります。

13.5.1. Generation of the First FloorStatus Message
13.5.1. 最初のFloorStatusメッセージの生成

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メッセージが生成され、その最初のメッセージは可能な限り速やかに生成すべきです (SHOULD)。

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の説明に従い、FloorQueryメッセージのConference ID、Transaction ID、およびUser IDをFloorStatusメッセージにコピーしなければなりません (MUST)。

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メッセージに1つ以上のFLOOR-ID属性が含まれる場合、フロア制御サーバーはそのうち1つを選び、そのFLOOR-ID属性をFloorStatusメッセージに追加します。サーバーは、フロアに関連付けられた各フロア要求についてFLOOR-REQUEST-INFORMATIONグループ化属性を追加すべきです (SHOULD)。各属性には、フロア要求に関する情報を示す複数の属性が含まれます。各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.

フロア制御サーバーは、FLOOR-REQUEST-INFORMATION属性のFloor Request IDフィールドに値を設定して、その属性が適用されるフロア要求を識別しなければなりません (MUST)。

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-INFORMATIONのグループ化された属性に追加しなければなりません (MUST)（つまり、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.

フロア制御サーバーは、フロア要求の受益者を識別するBENEFICIARY-ID属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加すべきです (SHOULD)。さらに、BENEFICIARY-INFORMATION属性に受益者の表示名とURIを含めてもよい (MAY) です。

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属性に、フロア要求者の情報を含めてもよい (MAY) です。

The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

フロア制御サーバーは、フロア参加者がPARTICIPANT-PROVIDED-INFOでフロアを要求した理由を提供する場合があります (MAY)。

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.

フロア制御サーバーは、フロア要求に指定されたPriority値を持つPRIORITY属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加してもよい (MAY) です。

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.

フロア制御サーバーは、フロア要求の現在の状態を示すOVERALL-REQUEST-STATUS属性をFLOOR-REQUEST-INFORMATIONグループ化属性に追加しなければなりません (MUST)。フロア要求に関する補足情報をSTATUS-INFO属性で追加してもかまいません (MAY)。

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-STATUS属性で示してもよい (MAY) です。

13.5.2. Generation of Subsequent FloorStatus Messages
13.5.2. 後続のFloorStatusメッセージの生成

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属性が含まれている場合、最初のFloorStatusメッセージで選んだFLOOR-ID属性を除き、各属性に対応するFloorStatusメッセージをできるだけ早く生成すべきです (SHOULD)。これらのメッセージは最初のFloorStatusメッセージと同じ規則に従って生成します（セクション13.5.1を参照）が、Transaction 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メッセージを送信し、クライアントが情報を要求したすべてのフロアについて定期的に通知し続けます。これらのメッセージのTransaction IDは0でなければなりません (MUST)。

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メッセージを送る一方、別のサーバーは新しいフロア要求がGrantedになったときだけ送ることがあります。

13.6. Reception of a ChairAction Message
13.6. ChairActionメッセージの受信

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で説明されている手順に従ってエラー応答を生成すべきです (SHOULD)。

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メッセージを生成します。この応答はできるだけ早く生成すべきです (SHOULD)。

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の説明どおり、ChairActionメッセージからConference ID、Transaction ID、User IDをChairActionAckメッセージにコピーしなければなりません (MUST)。

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メッセージの新しいStatusがAcceptedで、Queue Positionフィールドの全ビットが0の場合、フロアチェアはフロア制御サーバーに、サーバーのローカルポリシーに基づいてフロア要求のキュー位置（たとえば最後尾）を割り当てるよう求めています。（この要求は、フロア制御サーバーがキューを実装している場合にのみ適用されます。）

13.7. Reception of a Hello Message
13.7. Helloメッセージの受信

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の手順に従ってError応答を生成すべきです (SHOULD)。

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メッセージを生成します。このメッセージはできるだけ早く生成すべきです (SHOULD)。フロア制御サーバーは、セクション8.2の説明に従い、HelloのConference ID、Transaction ID、およびUser IDをHelloAckにコピーしなければなりません (MUST)。

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プリミティブ（つまりBFCPメッセージ）を列挙したSUPPORTED-PRIMITIVES属性をHelloAckメッセージに追加しなければなりません (MUST)。

The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server.

フロア制御サーバーは、サポートするすべての属性を列挙したSUPPORTED-ATTRIBUTES属性をHelloAckメッセージに追加しなければなりません (MUST)。

13.8. Error Message Generation
13.8. Errorメッセージの生成

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の説明どおり、クライアントのメッセージからConference ID、Transaction ID、User IDをErrorメッセージにコピーしなければなりません (MUST)。

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を追加しなければなりません (MUST)。ERROR-CODEには、表5からのエラーコードが含まれています。さらに、フロア制御サーバーは、エラーに関する追加情報を含むERROR-INFO属性を追加する場合があります。

14. Security Considerations
14. セキュリティに関する考慮事項

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はリプレイ攻撃への対策、完全性保護、機密性も提供します。NULL以外の暗号化アルゴリズムを使うTLSを常に使用することが推奨されます (RECOMMENDED)。同等のセキュリティ特性を提供する限り、BFCPエンティティは他のセキュリティ機構を使ってもよい (MAY) です。

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接続を乗っ取れないため、その接続上のメッセージは最初に認証されたクライアントから送信されたものだと想定します。

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接続で受信したメッセージに、その接続を確立したユーザーが使用を許可されているUser 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の機密性によってこの攻撃を防げます。したがって、NULLではない暗号化アルゴリズムを使うTLSの使用が推奨されます (RECOMMENDED)。

15. IANA Considerations
15. IANAに関する考慮事項

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パラメーターの新しいレジストリを作成しました。この新しいレジストリには、以下のセクションで説明されている多くのサブレジストリがあります。

15.1. Attribute Subregistry
15.1. 属性サブレジストリ

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 Parametersレジストリの下にAttributeサブレジストリを設けます。RFC 2434 [4]の用語では、BFCP属性の登録方針は「Specification Required」です。このサブレジストリへの登録をIANAに申請するBFCP属性は、標準化過程RFCで定義しなければなりません (MUST)。そのRFCでは、属性の型、名称、形式、意味を規定しなければなりません (MUST)。

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属性のサブレジストリの初期値

15.2. Primitive Subregistry
15.2. プリミティブサブレジストリ

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 Parametersレジストリの下にPrimitiveサブレジストリを設けます。RFC 2434 [4]の用語では、BFCPプリミティブの登録方針は「Specification Required」です。このサブレジストリへの登録をIANAに申請するBFCPプリミティブは、標準化過程RFCで定義しなければなりません (MUST)。そのRFCでは、プリミティブの値、名称、形式、意味を規定しなければなりません (MUST)。

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プリミティブサブレジストリの初期値

15.3. Request Status Subregistry
15.3. 要求状態サブレジストリ

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 Parametersレジストリの下にRequest Statusサブレジストリを設けます。RFC 2434 [4]の用語では、BFCP Request Statusの登録ポリシーは「Specification Required」です。このサブレジストリに登録するBFCP Request Statusは、標準化過程RFCで定義しなければなりません (MUST)。そのRFCはRequest Statusの値と意味を規定しなければなりません (MUST)。

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 Request Statusについて、IANAはその値、意味、およびRequest Statusを定義する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：リクエストステータスサブレジストリの初期値

15.4. Error Code Subregistry
15.4. エラーコードサブレジストリ

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 Parametersレジストリの下にError Codeサブレジストリを設けます。RFC 2434 [4]の用語では、BFCPエラーコードの登録方針は「Specification Required」です。このサブレジストリへの登録をIANAに申請するBFCPエラーコードは、標準化過程RFCで定義しなければなりません (MUST)。そのRFCでは、エラーコードの値と意味、および適用されるError Specific Detailsを規定しなければなりません (MUST)。

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：エラーコードサブレジストリの初期値

16. Acknowledgements
16. 謝辞

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ワーキンググループの議長であるAdam RoachとAlan Johnstonは、本書に有益なアイデアを提供しました。また、Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, およびOscar Novoは有益なコメントを寄せました。

17. References
17. 参考文献
17.1. Normative References
17.1. 規範的な参考文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.

[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.

[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[7] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.

[7] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.

17.2. Informational References
17.2. 参考情報

[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.

[9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.

[10] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", Work in Progress, February 2005.

[10] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", Work in Progress, February 2005.

Authors' Addresses

著者の連絡先

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland 

   EMail: Gonzalo.Camarillo@ericsson.com

Joerg Ott Helsinki University of Technology Department for Electrical and Communications Engineering Networking Laboratory PO Box 3000 02015 TKK Finland

Joerg Ott Helsinki University of Technology Department for Electrical and Communications Engineering Networking Laboratory PO Box 3000 02015 TKK Finland 

   EMail: jo@netlab.hut.fi

Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK

Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK 

   EMail: drage@lucent.com

Full Copyright Statement

著作権に関する声明

Copyright (C) The IETF Trust (2006).

Copyright (C) The IETF Trust (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に定める権利、ライセンス、および制限が適用されます。同BCPに別段の定めがある場合を除き、著者はすべての権利を保持します。

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.

本書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表するまたは後援を受ける組織（該当する場合）、Internet Society、IETF Trust、およびInternet Engineering Task Forceは、明示・黙示を問わず、すべての保証を否認します。これには、ここに含まれる情報の使用が権利を侵害しないことの保証や、商品性または特定目的への適合性に関する黙示の保証を含みますが、これらに限定されません。

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.

IETF事務局に提出された知的財産権（IPR）開示の写し、ライセンス提供に関する保証、または本仕様の実装者や利用者が当該権利の使用に関する一般ライセンスや許可を得ようとした結果は、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機能の運営資金は、現在Internet Societyが提供しています。