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
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).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
楼层控制是在（多方）会议环境中管理对共享资源的联合或独占访问的一种方法。因此，楼层控制补充了其他协议实现的其他功能，如会议和媒体会话设置、会议策略操作和媒体控制。
This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
本文件规定了二进制地板控制协议（BFCP）。BFCP用于发言参与者和发言控制服务器之间，以及发言椅（即主持人）和发言控制服务器之间。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Scope ...........................................................5
3.1. Floor Creation .............................................7
3.2. Obtaining Information to Contact a Floor Control Server ....7
3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control ................................8
4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface ........8
4.2. Floor Chair to Floor Control Server Interface .............13
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
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
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、FloorRequest、FloorRequestStatus和ChairAction。预计这些消息的未来扩展不会显著增加这些消息的大小。
The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation, and subsequent sections provide the normative specification of BFCP.
本文件的其余部分组织如下：第2节定义了本文件中使用的术语，第3节讨论了BFCP的范围（即哪些任务属于BFCP的范围，哪些任务使用不同的机制执行），第4节提供了BFCP操作的非规范性概述，随后的章节提供了BFCP的规范性规范。
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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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.
楼层椅：管理一个楼层（授予、拒绝或撤销楼层）的逻辑实体。在给定交易中担任场边主席逻辑角色的实体可能在不同交易中担任不同角色（例如，场边参与者）。现场主席和现场参与者的角色是在逐笔交易的基础上定义的。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
+---------+
| 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).
给定楼层与一个资源或一组资源（例如，媒体流）的关联超出了BFCP的范围，如[10]所述。楼层创建和终止也不属于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).
客户可以通过不同的方式获取这些信息。一种是使用SDP提供/应答[8]交换，如[7]所述。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]交换。[7]中描述了如何使用SDP提供/应答交换来获得这些关联。
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).
XCON框架[10]（和其他相关文档）中描述了获取该信息的其他机制，包括对信息如何提供给（SIP）焦点的讨论。
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.
BFCP消息使用TLV（类型长度值）二进制编码，由一个公共头和一组属性组成。除其他信息外，公共报头包含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中有两种类型的事务：客户端启动的事务和服务器启动的事务。客户端启动的事务包括从客户端到楼层控制服务器的消息和从楼层控制服务器到客户端的响应。这两条消息可以相互关联，因为它们在公共头中携带相同的事务ID值。服务器启动的事务由从楼层控制服务器到客户端的单个消息组成，其事务ID为0。
Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third-party floor requests) in a BENEFICIARY-ID attribute.
楼层参与者通过向楼层控制服务器发送FloorRequest消息来请求楼层。BFCP支持第三方楼层请求。也就是说，发送发言权请求的发言权参与者无需与在发言权请求获得批准后将获得发言权的媒体参与者共同定位。FloorRequest消息在公共标头的用户ID字段中包含请求者的身份，在受益人ID属性中包含楼层受益人的身份（在第三方楼层请求中）。
Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media).
例如，第三方楼层请求可以由与楼层控制服务器有BFCP连接但不是媒体参与者（即不处理任何媒体）的楼层参与者发送。
FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message.
FloorRequest消息通过在floor-ID属性中携带16位楼层标识符来标识所请求的一个或多个楼层。如果FloorRequest消息包含多个楼层标识符，则楼层控制服务器将所有楼层请求视为一个原子包。也就是说，楼层控制服务器授予或拒绝FloorRequest消息中的所有楼层。
Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest.
楼层控制服务器使用FloorRequestStatus消息响应FloorRequest消息，该消息提供有关楼层请求状态的信息。第一条FloorRequestStatus消息是对来自客户端的FloorRequest消息的响应，因此具有与FloorRequest相同的事务ID。
Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request.
此外，first FloorRequestStatus消息在Floor-Request-INFORMATION属性中携带楼层请求ID。与同一楼层请求相关的后续楼层请求状态消息将携带相同的楼层请求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.
来自与特定楼层请求相关的楼层参与者的消息也使用与来自楼层控制服务器的第一个楼层请求状态消息相同的楼层请求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 |
|---------------------------------------------->|
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 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 2: Requesting and releasing a floor
图2：请求和释放地板
Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message.
图3显示了发言参与者如何请求告知发言的状态。来自楼层控制服务器的第一条FloorStatus消息是对FloorQuery消息的响应，因此具有与FloorQuery消息相同的事务ID。
Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted.
后续FloorStatus消息由服务器启动的事务组成，因此其事务ID为0。FloorStatus消息（2）表示当前有两个楼层ID为543的楼层请求。FloorStatus消息（3）表示已批准具有发言权请求ID 764的发言权请求，并且具有发言权请求ID 635的发言权请求是队列中的第一个。FloorStatus消息（4）表示已批准楼层请求ID为635的楼层请求。
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
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 |
|<----------------------------------------------|
| |
|(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 |
|<----------------------------------------------|
| |
|(4) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
Figure 3: Obtaining status information about a floor
图3：获取有关楼层的状态信息
FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request.
FloorStatus消息包含有关其承载的楼层请求的信息。例如，FloorStatus消息（4）指示具有发言权请求ID 635的发言权请求具有用户ID为154的参与者作为受益人（即，当特定发言权请求被授予时持有发言权的参与者）。楼层请求仅适用于楼层ID为543的楼层。也就是说，这不是一个多层请求。
A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors.
多楼层楼层请求适用于多个楼层（例如，参与者希望能够同时在白板上说话和写字）。楼层控制服务器将多层楼层请求视为一个原子包。也就是说，楼层控制服务器要么批准所有楼层的请求，要么拒绝所有楼层的请求。
Figure 4 shows a floor chair instructing a floor control server to grant a floor.
图4显示了一个地板椅，指示地板控制服务器授予地板。
Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
但是，请注意，尽管楼层控制服务器需要考虑在椅子操作消息中接收到的指令（例如，授予楼层），但它不一定需要完全按照楼层主席的请求执行这些指令。楼层控制服务器执行的操作取决于ChairAction消息和楼层控制服务器的内部状态。
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.
例如，一个楼层主席可能会发送一条主席行动消息，批准作为涉及多个楼层的原子楼层请求操作的一部分请求的楼层。即使负责其中一个楼层的主席指示楼层控制服务器授予该楼层，楼层控制服务器也不会授予该楼层控制，直到负责其他楼层的主席也同意授予该楼层控制服务器。在另一示例中，落地椅可指示落地控制服务器向参与者授予发言权。在将发言权授予新参与者之前，发言权控制服务器需要从其当前持有人处撤销发言权。
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 |
|<----------------------------------------------|
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format
图5:COMMON-HEADER格式
Ver: The 3-bit version field MUST be set to 1 to indicate this version of BFCP.
版本：3位版本字段必须设置为1，以指示此版本的BFCP。
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
+-------+--------------------+------------------+
| 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.
BFCP中的参与者使用的身份（在用户ID字段中携带）通常映射到会话建立协议（例如，在SIP中）中相同参与者使用的身份。此映射的执行方式不在本规范的范围内。
BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned.
BFCP属性以TLV（类型长度值）格式编码。属性是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 /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+------+---------------------------+---------------+
+------+---------------------------+---------------+
| 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,
长度：此8位字段包含属性的长度（以八位字节为单位），不包括为特定属性定义的任何填充。未分组属性的长度包括类型“M”位，
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.
和长度字段。分组属性中的长度是分组属性本身的长度（包括类型、“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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format
图7：受益人身份证格式
Beneficiary ID: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：楼层请求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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-------+----------+
+-------+----------+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-------+-----------+
+-------+-----------+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+
| 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位对齐的。如果属性已经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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format
图13：未知属性格式
Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver.
未知类型：这些7位字段包含接收器未知的属性类型（出现在触发错误消息的消息中）。
R: At this point, this bit is reserved. It SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
R：在这一点上，这个位是保留的。消息发送方应将其设置为零，接收方必须忽略它。
The following is the format of the ERROR-INFO attribute.
以下是ERROR-INFO属性的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
在某些情况下，文本字段的内容可能由自动机生成。如果此自动机具有关于特定错误信息属性的接收者的首选语言的信息，则它可以使用此语言生成文本字段。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
填充：添加一个、两个或三个八位字节的填充，以便ERROR-INFO属性的内容是32位对齐的。发送方应将填充位设置为零，接收方必须忽略填充位。如果属性已经32位对齐，则不需要填充。
The following is the format of the PARTICIPANT-PROVIDED-INFO 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 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：参与者提供的信息格式
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.
填充：添加一个、两个或三个八位字节的填充，以便参与者提供的信息属性的内容是32位对齐的。发送方应将填充位设置为零，接收方必须忽略填充位。如果属性已经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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：状态信息格式
Text: This field contains UTF-8 [6] encoded text.
文本：此字段包含UTF-8[6]编码文本。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field.
在某些情况下，文本字段的内容可能由自动机生成。如果此自动机具有关于特定STATUS-INFO属性的接收者的首选语言的信息，则它可以使用此语言生成文本字段。
Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
填充：添加一个、两个或三个八位字节的填充，以便STATUS-INFO属性的内容是32位对齐的。发送方应将填充位设置为零，接收方必须忽略填充位。如果属性已经32位对齐，则不需要填充。
The following is the format of the SUPPORTED-ATTRIBUTES attribute.
以下是受支持的-ATTRIBUTES属性的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
辅助属性：这些字段包含地板控制服务器支持的属性类型，格式如下：
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.
Padding：添加了两个八位字节的Padding，以便SUPPORTED-ATTRIBUTES属性的内容是32位对齐的。如果属性已经32位对齐，则不需要填充。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
发送方应将填充位设置为零，接收方必须忽略填充位。
The following is the format of the SUPPORTED-PRIMITIVES attribute.
以下是SUPPORTED-PRIMITIVES属性的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
填充：添加一个、两个或三个八位字节的填充，以便SUPPORTED-PRIMITIVES属性的内容是32位对齐的。如果属性已经32位对齐，则不需要填充。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
发送方应将填充位设置为零，接收方必须忽略填充位。
The following is the format of the USER-DISPLAY-NAME attribute.
以下是USER-DISPLAY-NAME属性的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：用户名显示格式
Text: This field contains the UTF-8 encoded name of the user.
文本：此字段包含用户的UTF-8编码名称。
Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
填充：添加一个、两个或三个八位字节的填充，以便USER-DISPLAY-NAME属性的内容是32位对齐的。发送方应将填充位设置为零，接收方必须忽略填充位。如果属性已经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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：用户URI格式
Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user.
文本：此字段包含UTF-8编码的用户联系人URI，即用户用于设置由BFCP控制的资源（例如媒体流）的URI。例如，在SIP设置的会议上下文中，USER-URI属性将携带用户的SIPURI。
Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID.
在user-URI属性中包含用户URI的消息也包含用户的用户ID。这样，接收此类消息的客户端可以将用户的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.
填充：添加一个、两个或三个八位字节的填充，以便USER-URI属性的内容是32位对齐的。发送方应将填充位设置为零，接收方必须忽略填充位。如果属性已经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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]
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:
FLOOR-REQUEST-INFORMATION属性是一个分组属性，由一个标题（称为FLOOR-REQUEST-INFORMATION-header）和一系列属性组成。以下是FLOOR-REQUEST-INFORMATION-HEADER的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
图23:FLOOR-REQUEST-INFORMATION-HEADER格式
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
楼层请求ID：此字段包含一个16位值，用于标识楼层控制服务器上的楼层请求。
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下是FLOOR-REQUEST-INFORMATION-grouped属性的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]
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:
request-BY-INFORMATION属性是一个分组属性，它由一个标题（称为request-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Requested by ID：此字段包含一个16位值，用于唯一标识会议中的用户。
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下是“按信息分组请求”属性的ABNF。（EXTENSION-ATTRIBUTE是指将来可能定义的扩展属性。）
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
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属性是一个分组属性，由一个标题（称为FLOOR-REQUEST-STATUS-header）和一系列属性组成。以下是FLOOR-REQUEST-STATUS-HEADER的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
图27:FLOOR-REQUEST-STATUS-HEADER格式
Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference.
楼层ID：此字段包含一个16位值，用于唯一标识会议中的楼层。
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下是FLOOR-REQUEST-STATUS分组属性的ABNF。（EXTENSION-ATTRIBUTE是指将来可能定义的扩展属性。）
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-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:
total-REQUEST-STATUS属性是一个分组属性，由一个标题（称为total-REQUEST-STATUS-header）和一系列属性组成。以下是total-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:total-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.)
下面是total-REQUEST-STATUS分组属性的ABNF。（EXTENSION-ATTRIBUTE是指将来可能定义的扩展属性。）
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[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（增强的Backus Naur格式）[2]。将来可能定义的扩展属性在ABNF中称为Extension-ATTRIBUTE。
Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message:
楼层参与者通过向楼层控制服务器发送FloorRequest消息来请求楼层。以下是FloorRequest消息的格式：
FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID)
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*[EXTENSION-ATTRIBUTE]
FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID)
[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:
楼层参与者通过向楼层控制服务器发送楼层释放消息来释放楼层。楼层参与者还使用FloorRelease消息取消挂起的楼层请求。以下是FloorRelease消息的格式：
FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
Figure 32: FloorRelease format
图32：楼层租赁格式
Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message:
楼层参与者和楼层椅子通过向楼层控制服务器发送FloorRequestQuery消息来请求有关楼层请求的信息。以下是FloorRequestQuery消息的格式：
FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-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消息，通知他们楼层请求的状态。以下是FloorRequestStatus消息的格式：
FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
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消息来请求有关参与者的信息以及与此参与者相关的楼层请求。以下是UserQuery消息的格式：
UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE]
UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE]
Figure 35: UserQuery format
图35:UserQuery格式
The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message:
楼层控制服务器通过向楼层参与者和楼层椅子发送用户状态消息，向他们提供有关参与者及其相关楼层请求的信息。以下是UserStatus消息的格式：
UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
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:
楼层参与者和楼层椅子通过向楼层控制服务器发送FloorQuery消息来请求有关一个或多个楼层的信息。以下是FloorRequest消息的格式：
FloorQuery = (COMMON-HEADER)
*(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]
FloorQuery = (COMMON-HEADER)
*(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]
Figure 37: FloorQuery format
图37:FloorQuery格式
The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message:
楼层控制服务器通过向楼层参与者和楼层椅子发送FloorStatus消息，通知他们楼层的状态（例如，当前持有者）。以下是FloorStatus消息的格式：
FloorStatus = (COMMON-HEADER)
*1(FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION]
*[EXTENSION-ATTRIBUTE]
FloorStatus = (COMMON-HEADER)
*1(FLOOR-ID)
*[FLOOR-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消息的格式：
ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
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:
楼层控制服务器通过发送ChairActionAck消息确认已接受ChairAction消息。以下是ChairActionAck消息的格式：
ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 40: ChairActionAck format
图40:ChairActionAck格式
Floor participants and floor chairs check the liveliness of floor control servers by sending a Hello message. The following is the format of the Hello message:
地板参与者和地板椅通过发送Hello消息来检查地板控制服务器的活力。以下是Hello消息的格式：
Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 41: Hello format
图41:Hello格式
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]
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]
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.
如果楼层控制服务器检测到与其中一个楼层参与者的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和AES 128 CBC SHA密码套件[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连接时，应答者（可能是客户端或楼层控制服务器）始终充当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中，有两种类型的事务：客户端启动的事务和服务器启动的事务（通知）。客户机启动的事务包括从客户机到楼层控制服务器的请求和从楼层控制服务器到客户机的响应。请求在其公共头中携带事务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.
按照第9.1节的规定，BFCP支持客户端和楼层控制服务器之间基于TLS的相互认证。这是BFCP中推荐的身份验证机制。
Note that future extensions may define additional authentication mechanisms.
请注意，未来的扩展可能会定义额外的身份验证机制。
In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further.
除了验证BFCP消息外，楼层控制服务器还需要对其进行授权。收到经过身份验证的BFCP消息后，楼层控制服务器将检查发送消息的客户端是否经过授权。如果未授权客户端执行请求的操作，楼层控制服务器将生成错误消息，如第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].
[7]中描述了使用SIP和SDP提供/应答模型实现这种完整性保护信道。
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消息的楼层控制服务器可通过生成错误消息请求使用TLS，如第13.8节所述，错误代码值为9（使用TLS）。客户端应该忽略未经验证的消息。
Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority).
请注意，未来的扩展可能会定义不需要初始完整性保护通道的附加身份验证机制（例如，基于证书颁发机构签署的证书的身份验证）。
As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server SHOULD check that messages arriving over a given authenticated TLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS connection is allowed to use).
如第9节所述，楼层控制服务器需要在处理任何消息之前执行授权。特别是，楼层控制服务器应检查通过给定的认证TLS连接到达的消息是否使用授权用户ID（即，建立认证TLS连接的用户允许使用的用户ID）。
This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).
本节指定楼层参与者如何使用前面几节中描述的协议元素执行不同的操作，例如请求楼层。第11节规定了特定于落地椅的操作，如指示落地控制服务器授予或撤销落地，第12节规定了可由任何客户机（即落地参与者和落地椅）执行的操作。
A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.
希望请求一个或多个楼层的楼层参与者通过向楼层控制服务器发送FloorRequest消息来请求一个或多个楼层。
The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.1节中的ABNF描述了FloorRequest消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1.
现场参与者按照第8.1节给出的规则在公共标题中设置会议ID和交易ID。
The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor.
楼层参与者将公共标题中的用户ID设置为楼层参与者的标识符。楼层控制服务器将使用此用户ID对请求进行身份验证和授权。如果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的名称空间是相同的。也就是说，给定的参与者由单个16位值标识，该值可用于公共报头中的用户ID和几个属性：受益人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消息中至少插入一个楼层ID属性。如果客户机插入多个FLOOR-ID属性，FLOOR-control服务器将把所有FLOOR请求视为一个原子包。也就是说，楼层控制服务器将授予或拒绝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.
楼层参与者可以使用参与者提供的信息属性来说明请求楼层的原因。“参与者提供的信息”属性中的文本字段供人使用。
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.
如第8.1节所述，如果来自地板控制服务器的消息与地板请求消息具有相同的会议ID、事务ID和用户ID，则来自地板控制服务器的消息被视为对地板请求消息的响应。收到此类响应后，楼层参与者遵循第9节中与楼层控制服务器身份验证相关的规则。
The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request.
在楼层控制服务器上成功处理FloorRequest消息需要生成一条或多条FloorRequestStatus消息。楼层参与者从楼层控制服务器获取第一个楼层请求状态消息中楼层请求信息属性的楼层请求ID字段中的楼层请求ID。来自楼层控制服务器的关于同一楼层请求的后续楼层请求状态消息将在楼层请求信息属性中携带与初始楼层请求状态消息相同的楼层请求ID。通过这种方式，楼层参与者可以将后续传入的FloorRequestStatus消息与正在进行的楼层请求相关联。
The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request.
楼层参与者在从楼层控制服务器接收的每个FloorRequestStatus消息的floor-request-information属性中获取有关楼层请求状态的信息。此属性是一个分组属性，因此它包括许多提供有关楼层请求信息的属性。
The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user.
“总体请求状态”属性提供有关楼层请求总体状态的信息。如果已授予请求状态值，则已授予FloorRequest消息中请求的所有楼层。如果请求状态值被拒绝，则FloorRequest消息中请求的所有楼层都已被拒绝。发言权请求在待决、已接受或已批准状态时被视为正在进行中。如果楼层请求值未知，则仍会处理响应。但是，无法向用户报告任何有意义的值。
The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
STATUS-INFO属性（如果存在）提供了楼层参与者可以向用户显示的额外信息。
The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
FLOOR-REQUEST-STATUS属性提供与特定楼层相关的楼层请求状态信息。STATUS-INFO属性（如果存在）提供了楼层参与者可以向用户显示的额外信息。
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header.
“受益人信息”属性标识第三方发言权请求中发言权请求的受益人。请求发言权的发言权参与者接收的FloorRequestStatus消息中不需要存在REQUESTED-BY-INFORMATION属性，因为该发言权参与者已由公共标头中的用户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.
如果响应是错误消息，则楼层控制服务器由于某种原因无法处理FloorRequest消息，错误消息中对此进行了描述。
A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.
希望取消正在进行的楼层请求的楼层参与者通过向楼层控制服务器发送楼层释放消息来取消该请求。持有某个楼层并希望释放该楼层的楼层参与者也可以使用FloorRelease消息。
The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.2节中的ABNF描述了FloorRelease消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
现场参与者按照第8.1节给出的规则在公共标题中设置会议ID和交易ID。楼层参与者将公共标题中的用户ID设置为楼层参与者的标识符。楼层控制服务器将使用此用户ID对请求进行身份验证和授权。
Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire.
请注意，FloorRelease消息用于释放一个或多个已授予的楼层，以及取消正在进行的楼层请求（从协议的角度来看，两者都是正在进行的楼层请求）。在这两种情况下使用相同的消息有助于解决FloorRelease消息和FloorGrant消息在线路上相互交叉时发生的争用情况。
The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling.
楼层参与者使用在响应FloorRequest消息（FloorRequest消息正在取消）时收到的楼层请求ID。
Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time).
请注意，如果楼层参与者请求几个楼层作为原子操作（即，在单个FloorRequest消息中），则所有楼层也将作为原子操作释放（即，所有楼层同时释放）。
A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
如第8.1节所述，如果来自地板控制服务器的消息与地板请求消息具有相同的会议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消息，则全局请求状态属性（在FLOOR-Request-INFORMATION分组属性内）中的请求状态值将被取消或释放。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
如果响应是错误消息，则楼层控制服务器由于某种原因无法处理FloorRequest消息，错误消息中对此进行了描述。
It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease.
FloorRelease消息可能与来自请求状态不同于Cancelled或Released的服务器的FloorRequestStatus消息在线路上交叉。在任何情况下，这样的FloorRequestStatus消息都不会是对FloorRelease消息的响应，因为它的事务ID与FloorRelease的事务ID不匹配。
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描述了ChairAction消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
会议主席按照第8.1节给出的规则，在公共标题中设置会议ID和交易ID。地板椅将公共标题中的用户ID设置为地板参与者的标识符。楼层控制服务器将使用此用户ID对请求进行身份验证和授权。
The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.
ChairAction消息包含适用于特定楼层请求中的一个或多个楼层的说明。楼层由floor-REQUEST-STATUS属性标识，楼层请求由floor-REQUEST-INFORMATION-HEADER标识，该标题包含在ChairAction消息中。
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.
无论其他楼层主席的决定如何，控制服务器将拒绝整个楼层请求。
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.
请注意，特定楼层控制服务器可以为每个楼层实现一个不同的队列，其中包含与该特定楼层相关的所有楼层请求，也可以为所有楼层请求实现一个通用队列，或者两者都实现。还请注意，楼层请求可能涉及多个楼层，主席行动消息可能仅处理这些楼层的子集（例如，如果一个楼层主席无权管理所有楼层）。在这种情况下，楼层控制服务器将在楼层请求状态属性中组合从不同楼层椅子接收的指令，以得出楼层请求的总体状态。
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.
楼层主席可以使用STATUS-INFO属性来说明楼层被接受、授予或撤销的原因。STATUS-INFO属性中的文本供人使用。
A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication.
如第8.1节所述，如果来自服务器的消息与ChairAction消息具有相同的会议ID、事务ID和用户ID，则来自楼层控制服务器的消息被视为对ChairAction消息的响应。在收到此类响应后，楼层主席将遵循第9节中与楼层控制服务器身份验证相关的规则。
A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message.
来自楼层控制服务器的ChairActionAck消息确认楼层控制服务器已接受ChairAction消息。错误消息表示楼层控制服务器由于某种原因无法处理ChairAction消息，错误消息中对此进行了描述。
This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.
本节指定可由任何客户端执行的操作。也就是说，它们并不特定于现场参与者或现场椅子。两者都可以执行。
A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
客户端可以通过不同的方式获取一个或多个楼层的状态信息，包括使用BFCP和带外机制。使用BFCP获取此类信息的客户使用本节所述的程序。
Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.
客户端通过向楼层控制服务器发送FloorQuery消息来请求有关一个或多个楼层状态的信息。
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.7节中的ABNF描述了FloorQuery消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
客户机按照第8.1节给出的规则在公共标头中设置会议ID和事务ID。客户端将公共标头中的用户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。楼层控制服务器将定期发送有关所有这些楼层的信息。如果客户端不想再接收有关特定楼层的信息，它将发送一条新的FloorQuery消息，删除该楼层的floor-ID。如果客户端不想再接收任何楼层的信息，它将发送一条不带floor-ID属性的FloorQuery消息。
A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the
如果来自楼层控制服务器的消息具有与楼层控制服务器相同的会议ID、事务ID和用户ID，则来自楼层控制服务器的消息被视为对楼层查询消息的响应
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.
FloorRequest消息，如第8.1节所述。收到此类响应后，客户端将遵循第9节中与楼层控制服务器身份验证相关的规则。
On reception of the FloorQuery message, the floor control server will respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either.
收到FloorQuery消息后，楼层控制服务器将以FloorStatus消息或错误消息进行响应。如果响应是FloorStatus消息，则它将包含有关客户机请求的其中一个楼层的信息。如果客户端在其FloorQuery消息中未包含任何FLOOR-ID属性（即，客户端不想再接收任何楼层的信息），则来自FLOOR control server的FloorStatus消息也不会包含任何FLOOR-ID属性。
FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request.
带有楼层信息的FloorStatus消息包含标识楼层的floor-ID属性。在该属性之后，FloorStatus消息包含与该楼层相关的现有（一个或多个）楼层请求的信息。关于每个特定楼层请求的信息编码在floor-request-information属性中。此分组属性包含一个楼层请求ID，该ID标识楼层请求，后跟一组提供楼层请求信息的属性。
After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about.
在第一个FloorStatus之后，楼层控制服务器将继续发送FloorStatus消息，定期向客户机通知客户机请求的有关楼层的更改信息。
A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
客户端可以通过不同的方式获取一个或多个楼层请求的状态信息，包括使用BFCP和带外机制。使用BFCP获取此类信息的客户使用本节所述的程序。
Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server.
客户端通过向楼层控制服务器发送FloorRequestQuery消息来请求有关楼层请求当前状态的信息。
Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.
在许多情况下，请求有关特定发言权请求的信息非常有用。例如，在接收到FloorRequest消息时，楼层控制服务器可以选择仅在楼层请求更改其状态（例如，从已接受更改为已授予）时返回FloorRequestStatus消息，而不是在楼层请求在其队列中前进时返回FloorRequestStatus消息。在这种情况下，如果用户请求，楼层参与者可以使用FloorRequestQuery消息轮询楼层控制服务器以了解楼层请求的状态。
The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.3节中的ABNF描述了FloorRequestQuery消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
客户机按照第8.1节给出的规则在公共标头中设置会议ID和事务ID。客户端将公共标头中的用户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.
如第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消息，则客户端将在FLOOR-REQUEST-information属性中获取有关FloorRequest状态的信息，该信息是客户端请求的信息。
If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.
如果响应是错误消息，则楼层控制服务器由于某种原因无法处理FloorRequestQuery消息，错误消息中对此进行了描述。
A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
客户机可以通过不同的方式获取关于参与者和与该参与者相关的发言请求的信息，包括使用BFCP和带外机制。使用BFCP获取此类信息的客户使用本节所述的程序。
Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server.
客户端通过向楼层控制服务器发送UserQuery消息来请求有关参与者的信息以及与此参与者相关的楼层请求。
This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a
对于对特定楼层参与者的显示名称和URI感兴趣的楼层椅子或楼层参与者，此功能可能很有用。此外，现场参与者可能会发现要求了解自己的信息很有用。例如，一个
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.
楼层参与者在遇到连接问题（例如，其与楼层控制服务器的TCP连接中断了一段时间并最终重新建立）后，可能需要请求与自身相关的、仍然存在的所有楼层请求的信息。
The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.5节中的ABNF描述了UserQuery消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
客户机按照第8.1节给出的规则在公共标头中设置会议ID和事务ID。客户端将公共标头中的用户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.
如果客户请求信息的楼层参与者不是发出UserQuery消息的客户（由消息公共标题中的用户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.
如第8.1节所述，如果来自楼层控制服务器的消息与UserQuery消息具有相同的会议ID、事务ID和用户ID，则来自楼层控制服务器的消息被视为对UserQuery消息的响应。收到此类响应后，客户端将遵循第9节中与楼层控制服务器身份验证相关的规则。
If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.
如果响应是UserStatus消息，则客户端将在“受益人信息分组”属性中获取有关楼层参与者的信息，以及在“楼层请求信息”属性中获取与楼层参与者关联的楼层请求的状态信息。
If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.
如果响应是错误消息，则楼层控制服务器由于某种原因无法处理UserQuery消息，错误消息中对此进行了描述。
A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.
希望获得地板控制服务器功能的客户端通过向地板控制服务器发送Hello消息来实现。
The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
第5.3.11节中的ABNF描述了Hello消息可以包含的属性。此外，ABNF规范性地指定这些属性中哪些是强制性的，哪些是可选的。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
客户机按照第8.1节给出的规则在公共标头中设置会议ID和事务ID。客户端将公共标头中的用户ID设置为客户端的标识符。楼层控制服务器将使用此用户ID对请求进行身份验证和授权。
A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
如第8.1节所述，如果来自地板控制服务器的消息与Hello消息具有相同的会议ID、事务ID和用户ID，则来自地板控制服务器的消息被视为客户端对Hello消息的响应。收到此类响应后，客户端将遵循第9节中与楼层控制服务器身份验证相关的规则。
If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITVIES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server.
如果响应是HelloAck消息，则楼层控制服务器可以成功处理Hello消息。SUPPORTED-PRIMITVIES和SUPPORTED-ATTRIBUTES属性分别指示服务器支持哪些原语和属性。
If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.
如果响应是错误消息，则楼层控制服务器由于某种原因无法处理Hello消息，错误消息中对此进行了描述。
This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections.
本节指定楼层控制服务器如何使用前面几节中描述的协议元素执行不同的操作，例如授予楼层。
On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive).
在接收到来自客户端的消息时，楼层控制服务器必须检查原语的值是否受支持。如果没有，地板控制服务器应发送错误消息，如第13.8节所述，错误代码为3（未知原语）。
On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist).
在接收到来自客户端的消息时，楼层控制服务器必须检查会议ID的值是否与现有会议匹配。如果没有，楼层控制服务器应发送错误消息，如第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.
在收到FloorRequest消息时，楼层控制服务器遵循第9节中与客户端身份验证和授权相关的规则。如果在处理FloorRequest消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests for this Floor) to inform the floor participant.
BFCP允许楼层参与者对同一楼层有多个正在进行的楼层请求（例如，同一楼层参与者可以同时占据队列中的多个位置）。对于每个楼层参与者（例如，一个）仅支持一定数量的持续楼层请求的楼层控制服务器，可以使用错误代码8（您已达到此楼层的最大持续楼层请求数）通知楼层参与者。
The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates.
楼层控制服务器成功处理FloorRequest消息涉及生成一个或多个FloorRequestStatus消息，其中第一个消息应尽快生成。如果楼层控制服务器无法立即接受、批准或拒绝楼层请求（例如，需要主席作出决定），则应在其生成的第一个楼层请求状态消息的“总体请求状态”属性（在“楼层请求信息分组”属性内）中使用“请求状态”值“待定”。
The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made.
楼层控制服务器授予或拒绝楼层所遵循的策略不在本文档的范围内。给定的楼层控制服务器可能会自动执行这些决策，而另一个服务器可能会在每次需要做出决策时联系担任主席的人员。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the
楼层控制服务器必须将会议ID、事务ID和用户ID从楼层请求复制到
FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
地板需求状态，如第8.2节所述。此外，楼层控制服务器必须将楼层请求信息分组属性添加到FloorRequestStatus。此分组属性中包含的属性包含有关楼层请求的信息。
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的floor-ID属性中的楼层ID复制到floor-REQUEST-INFORMATION分组属性中的floor-REQUEST-STATUS属性中。这些楼层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.
楼层控制服务器应将楼层请求中的受益人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.
楼层控制服务器可以将参与者提供的信息属性从FloorRequest复制（如果存在）到floor-REQUEST-INFORMATION分组属性中。
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.
楼层控制服务器可以将参与者提供的信息属性从FloorRequest复制（如果存在）到floor-REQUEST-INFORMATION分组属性中。
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.
发言权请求只要不在取消、释放或撤销状态，就被视为正在进行中。如果楼层控制服务器生成的first FloorRequestStatus消息的Total-REQUEST-STATUS属性（在FLOOR-REQUEST-INFORMATION Group属性内）未指示任何这些状态，则楼层控制服务器将需要发送后续FloorRequestStatus消息。
When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.)
当楼层请求的状态更改时，楼层控制服务器应发送具有适当请求状态的新FloorRequestStatus消息。楼层控制服务器必须将楼层请求ID等于第一条FloorRequestStatus消息中发送的ID的floor-REQUEST-INFORMATION属性添加到与同一楼层请求相关的任何新FloorRequestStatus。（楼层请求ID标识楼层请求状态适用的楼层请求。）
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消息的速率取决于本地策略。楼层控制服务器可以选择在每次楼层请求在楼层请求队列中移动时发送新的楼层请求状态消息，而另一个服务器可以选择仅在楼层请求被批准或拒绝时发送新的楼层请求状态消息。
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.
公共标头和其他属性与first FloorRequestStatus消息中的相同。
The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.
楼层控制服务器可以在特定楼层请求达到已取消、已释放或已撤销状态时丢弃该请求的状态信息。
On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
在接收到FloorRequestQuery消息时，楼层控制服务器遵循第9节中与客户端身份验证和授权相关的规则。如果在处理FloorRequestQuery消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
楼层控制服务器成功处理FloorRequestQuery消息涉及生成FloorRequestStatus消息，该消息应尽快生成。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.
楼层控制服务器必须将FloorRequestQuery消息中的会议ID、事务ID和用户ID复制到FloorRequestStatus消息中，如第8.2节所述。此外，楼层控制服务器必须在FloorRequestStatus的floor-request-information grouped属性中包含有关楼层请求的信息。
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属性的内容从FloorRequestQuery消息复制到floor-REQUEST-INFORMATION属性的floor-REQUEST-ID字段中。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
楼层控制服务器必须将楼层请求状态属性添加到楼层请求信息分组属性中，以标识被请求的楼层（即，与楼层请求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.
楼层控制服务器可以在参与者提供的信息中提供楼层参与者请求楼层的原因。
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.
楼层控制服务器还可以向楼层请求信息分组属性添加优先级属性，该优先级属性具有为楼层请求请求的优先级值，以及状态信息属性，该状态信息属性具有关于楼层请求的额外信息。
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.
在接收到UserQuery消息时，楼层控制服务器遵循第9节中与客户端身份验证和授权相关的规则。如果在处理UserQuery消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible.
楼层控制服务器成功处理UserQuery消息涉及生成UserStatus消息，应尽快生成该消息。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the USerStatus message, as described in Section 8.2.
楼层控制服务器必须将UserQuery消息中的会议ID、事务ID和用户ID复制到USerStatus消息中，如第8.2节所述。
The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message.
UserQuery消息的发送者正在请求与给定参与者相关联的所有发言权请求的信息（即，参与者是受益人或请求者的发言权请求）。此参与者由受益人ID属性标识，如果没有受益人ID属性，则由UserQuery消息公共标头中的用户ID标识。
The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute.
如果存在，楼层控制服务器必须将UserQuery消息中的受益人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.
楼层控制服务器应向UserStatus消息中添加楼层请求信息分组属性，用于与消息提供信息的参与者相关的每个楼层请求（即参与者为受益人或请求者的楼层请求）。对于每个FLOOR-REQUEST-INFORMATION属性，FLOOR-control服务器都遵循以下步骤。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
楼层控制服务器必须通过填写楼层请求信息属性的楼层请求ID字段来识别楼层请求信息属性适用的楼层请求。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
楼层控制服务器必须将楼层请求状态属性添加到楼层请求信息分组属性中，以标识被请求的楼层（即，与楼层请求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.
楼层控制服务器可以在参与者提供的信息中提供楼层参与者请求楼层的原因。
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.
楼层控制服务器成功处理FloorRelease消息涉及生成FloorRequestStatus消息，该消息应尽快生成。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2.
楼层控制服务器必须将FloorRelease消息中的会议ID、事务ID和用户ID复制到FloorRequestStatus消息中，如第8.2节所述。
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.
FloorRelease消息使用floor-request-ID标识其应用的楼层请求。楼层控制服务器必须将floor-request-ID属性的内容从FloorRelease消息复制到floor-request-INFORMATION属性的floor-request-ID字段中。
The floor control server MUST identify the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.
楼层控制服务器必须在floor-request-STATUS属性到floor-request-INFORMATION分组属性中标识被请求的楼层（即，与floor-request-ID属性标识的楼层请求相关联的楼层）。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
楼层控制服务器必须向“楼层请求信息分组”属性添加“总体请求状态”属性。如果先前已授予一个或多个楼层，则应释放请求状态值；如果先前未授予一个或多个楼层，则应取消请求状态值。楼层控制服务器可以添加带有楼层请求额外信息的STATUS-INFO属性。
On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
在收到FloorQuery消息时，楼层控制服务器遵循第9节中与客户端身份验证相关的规则。如果在处理FloorRelease消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages.
从客户端接收FloorQuery消息的楼层控制服务器应将由FloorQuery消息中的floor-ID属性标识的楼层状态通知此客户端。楼层控制服务器通过使用FloorStatus消息通知客户端。
An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors.
单个FloorStatus消息包含有关单个楼层的信息。因此，当FloorQuery消息请求有关多个楼层的信息时，楼层控制服务器需要为不同楼层发送单独的FloorStatus消息。
The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so.
FloorQuery消息携带的信息可能取决于请求信息的用户。例如，主席可能能够接收关于未决请求的信息，而普通用户可能无权这样做。
The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible.
楼层控制服务器成功处理FloorQuery消息涉及生成一个或多个FloorStatus消息，其中第一个消息应尽快生成。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2.
楼层控制服务器必须将FloorQuery消息中的会议ID、事务ID和用户ID复制到FloorStatus消息中，如第8.2节所述。
If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant.
如果FloorQuery消息不包含任何FLOOR-ID属性，则楼层控制服务器发送FloorStatus消息而不添加任何附加属性，并且不向楼层参与者发送任何后续FloorStatus消息。
If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
如果FloorQuery消息包含一个或多个FLOOR-ID属性，则楼层控制服务器将从其中选择一个，并将此FLOOR-ID属性添加到FloorStatus消息中。楼层控制服务器应为与楼层关联的每个楼层请求添加楼层请求信息分组属性。每个FLOOR-REQUEST-INFORMATION分组属性都包含许多属性，这些属性提供有关FLOOR-REQUEST的信息。对于每个FLOOR-REQUEST-INFORMATION属性，FLOOR-control服务器都遵循以下步骤。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
楼层控制服务器必须通过填写楼层请求信息属性的楼层请求ID字段来识别楼层请求信息属性适用的楼层请求。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
楼层控制服务器必须将楼层请求状态属性添加到楼层请求信息分组属性中，以标识被请求的楼层（即，与楼层请求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.
楼层控制服务器可以在参与者提供的信息中提供楼层参与者请求楼层的原因。
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.
如果FloorQuery消息包含多个FLOOR-ID属性，则楼层控制服务器应尽快为每个属性生成FloorStatus消息（为第一个FloorStatus消息选择的FLOOR-ID属性除外）。这些FloorStatus消息按照与第一条FloorStatus消息相同的规则生成（参见第13.5.1节），但其事务ID为0。
After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0.
生成这些消息后，楼层控制服务器发送FloorStatus消息，定期向客户端通知客户端请求信息的所有楼层。这些消息的事务ID必须为0。
The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus message every time a new floor request arrives, while another may choose to only send a new FloorStatus message when a new floor request is Granted.
楼层控制服务器发送FloorStatus消息的速率取决于本地策略。楼层控制服务器可选择在每次新楼层请求到达时发送新楼层状态消息，而另一台服务器可选择仅在新楼层请求被批准时发送新楼层状态消息。
On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
在收到ChairAction消息时，楼层控制服务器遵循第9节中与客户端身份验证和授权相关的规则。如果在处理ChairAction消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible.
楼层控制服务器成功处理ChairAction消息需要生成ChairActionAck消息，该消息应尽快生成。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2.
楼层控制服务器必须将会议ID、事务ID和用户ID从ChairAction消息复制到ChairActionAck消息中，如第8.2节所述。
The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
楼层控制服务器需要考虑主席操作消息中请求的操作（例如，授予楼层），但不一定需要根据楼层主席的请求执行操作。楼层控制服务器执行的操作取决于ChairAction消息和楼层控制服务器的内部状态。
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.
例如，一个楼层主席可能会发送一条主席行动消息，批准作为涉及多个楼层的原子楼层请求操作的一部分请求的楼层。如果负责楼层的一位服务员同意，那么在负责楼层的另一位服务员同意之前，负责楼层的另一位服务员也不会同意对楼层进行控制。
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.
在接收到Hello消息时，楼层控制服务器遵循第9节中与客户端身份验证相关的规则。如果在处理Hello消息时，楼层控制服务器遇到错误，则应按照第13.8节中描述的步骤生成错误响应。
The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2.
楼层控制服务器成功处理Hello消息需要生成HelloAck消息，该消息应尽快生成。楼层控制服务器必须将会议ID、事务ID和用户ID从Hello复制到HelloAck中，如第8.2节所述。
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.
地板控制服务器必须向HelloAck消息添加SUPPORTED-PRIMITIVES属性，该消息列出地板控制服务器支持的所有原语（即BFCP消息）。
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消息添加SUPPORTED-ATTRIBUTES属性，该消息列出楼层控制服务器支持的所有属性。
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.
楼层控制服务器必须将来自客户端的消息中的会议ID、事务ID和用户ID复制到错误消息中，如第8.2节所述。
The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.
楼层控制服务器必须向错误消息添加错误代码属性。ERROR-CODE属性包含表5中的错误代码。此外，楼层控制服务器可能会添加一个ERROR-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] |
+------+---------------------------+------------+
+------+---------------------------+------------+
| Type | Attribute | Reference |
+------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC 4582] |
| 2 | FLOOR-ID | [RFC 4582] |
| 3 | FLOOR-REQUEST-ID | [RFC 4582] |
| 4 | PRIORITY | [RFC 4582] |
| 5 | REQUEST-STATUS | [RFC 4582] |
| 6 | ERROR-CODE | [RFC 4582] |
| 7 | ERROR-INFO | [RFC 4582] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
| 9 | STATUS-INFO | [RFC 4582] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
| 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
| 12 | USER-DISPLAY-NAME | [RFC 4582] |
| 13 | USER-URI | [RFC 4582] |
| 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
| 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
| 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
| 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+------+---------------------------+------------+
Table 6: Initial values of the BFCP Attribute subregistry
表6:BFCP属性子区域的初始值
This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics.
本节在BFCP参数注册表下建立基本子区。根据RFC 2434[4]中的术语，BFCP原语的注册政策应为“要求规范”。就本次区域而言，申请IANA注册的BFCP原语必须由标准跟踪RFC定义。这样的RFC必须指定原语的值、名称、格式和语义。
For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
对于每个BFCP原语，IANA注册其值、名称和对定义原语的RFC的引用。下表包含该子区域的初始值。
+-------+--------------------+------------+
| Value | Primitive | Reference |
+-------+--------------------+------------+
| 1 | FloorRequest | [RFC 4582] |
| 2 | FloorRelease | [RFC 4582] |
| 3 | FloorRequestQuery | [RFC 4582] |
| 4 | FloorRequestStatus | [RFC 4582] |
| 5 | UserQuery | [RFC 4582] |
| 6 | UserStatus | [RFC 4582] |
| 7 | FloorQuery | [RFC 4582] |
| 8 | FloorStatus | [RFC 4582] |
| 9 | ChairAction | [RFC 4582] |
| 10 | ChairActionAck | [RFC 4582] |
| 11 | Hello | [RFC 4582] |
| 12 | HelloAck | [RFC 4582] |
| 13 | Error | [RFC 4582] |
+-------+--------------------+------------+
+-------+--------------------+------------+
| 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的引用，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] |
+-------+-----------+------------+
+-------+-----------+------------+
| 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] |
+-------+-----------------------------------------------+-----------+
+-------+-----------------------------------------------+------------+
| 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工作组主席Adam Roach和Alan Johnston为本文件提供了有用的想法。此外，吴晓涛、保罗·基齐瓦特、乔纳森·罗森博格、米格尔·加西亚·马丁、玛丽·巴恩斯、本·坎贝尔、戴夫·摩根和奥斯卡·诺沃提供了有用的评论。
[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 42342005年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，“传输层安全（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）密码套件”，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.，“二进制地板控制协议（BFCP）流的会话描述协议（SDP）格式”，RFC4583，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，“地板控制协议的要求”，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.和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
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
芬兰赫尔辛基工业大学电气与通信工程系网络实验室3000号信箱
EMail: jo@netlab.hut.fi
EMail: jo@netlab.hut.fi
Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK
基思·德拉吉·朗讯科技风车山商业园斯温顿威尔特郡SN5 6PP英国
EMail: drage@lucent.com
EMail: drage@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。