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