XCON Working Group                                          G. Camarillo
Internet-Draft                                                  Ericsson
Expires: July 1, November 5, 2005                                         J. Ott
                                                     Universitaet Bremen
                                       Helsinki University of Technology
                                                                K. Drage
                                                     Lucent Technologies
                                                       December 31, 2004
                                                             May 4, 2005

                The Binary Floor Control Protocol (BFCP)
                      draft-ietf-xcon-bfcp-03.txt
                      draft-ietf-xcon-bfcp-04.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she become becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 1, November 5, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).

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.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Floor Creation . . . . . . . . . . . . . . . . . . . . . .   8   7
     3.2  Obtaining Information to Contact a Floor Control Server  .   8
     3.3  Generating a Shared Secret . . . . . . . . . . . . . . . .   8
     3.4  Obtaining Floor-Resource Associations  . . . . . . . . . .   8
     3.5  Policy Enforcement . . . . .  Privileges of Floor Control  . . . . . . . . . . . . . . .   9
   4.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   9
     4.1  Floor Participant to Floor Control Server Interface  . . .  10
     4.2  Floor Chair to Floor Control Server Interface  . . . . . .  13
   5.   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .  14
     5.1  FIXED-HEADER Format  . . . . . . . . . . . . . . . . . . .  14  15
     5.2  Attribute Format . . . . . . . . . . . . . . . . . . . . .  15  16
       5.2.1  FLOOR-ID . . .  BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . .  17
       5.2.2  USER-ID  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . .  17  18
       5.2.3  BENEFICIARY-ID .  FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . .  17  18
       5.2.4  TRANSACTION-ID  NONCE  . . . . . . . . . . . . . . . . . . . .  18 . . . .  19
       5.2.5  FLOOR-REQUEST-ID  TRANSACTION-ID . . . . . . . . . . . . . . . . . . .  18 .  19
       5.2.6  HUMAN-READABLE-INFO  USER-ID  . . . . . . . . . . . . . . . . . . . .  18
       5.2.7  DIGEST . . .  19
       5.2.7  PRIORITY . . . . . . . . . . . . . . . . . . . . .  19 . .  20
       5.2.8  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . .  20
       5.2.9  ERROR-CODE  DIGEST . . . . . . . . . . . . . . . . . . . . . . . .  21
       5.2.10   USER-DISPLAY-NAME  .   ERROR-CODE . . . . . . . . . . . . . . . .  23
       5.2.11   USER-URI . . . . .  23
       5.2.11   ERROR-INFO . . . . . . . . . . . . . . . . .  23
       5.2.12   PRIORITY . . . .  25
       5.2.12   PARTICIPANT-PROVIDED-INFO  . . . . . . . . . . . . .  25
       5.2.13   STATUS-INFO  . . . . .  23
       5.2.13   NONCE . . . . . . . . . . . . . . .  26
       5.2.14   SUPPORTED-ATTRIBUTES . . . . . . . .  23
       5.2.14   SUPPORTED-TLVS . . . . . . . .  27
       5.2.15   SUPPORTED-PRIMITIVES . . . . . . . . . . .  24
     5.3  Message Format . . . . .  27
       5.2.16   USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . .  24
       5.3.1  FloorRequest  28
       5.2.17   USER-URI . . . . . . . . . . . . . . . . . . . . .  24
       5.3.2  FloorRelease .  29
       5.2.18   BENEFICIARY-INFORMATION  . . . . . . . . . . . . . .  29
       5.2.19   FLOOR-REQUEST-INFORMATION  . . . . . .  25
       5.3.3  FloorRequestInfoWanted . . . . . . .  30
       5.2.20   REQUESTED-BY-INFORMATION . . . . . . . . .  25
       5.3.4  FloorRequestInfo . . . . .  31
     5.3  Message Format . . . . . . . . . . . . . .  26
       5.3.5  FloorInfoWanted . . . . . . . .  31
       5.3.1  FloorRequest . . . . . . . . . . .  26
       5.3.6  FloorInfo . . . . . . . . . .  31
       5.3.2  FloorRelease . . . . . . . . . . . .  27
       5.3.7  ChairAction . . . . . . . . .  32
       5.3.3  FloorRequestInfoWanted . . . . . . . . . . . .  27
       5.3.8  ChairActionAck . . . .  32
       5.3.4  FloorRequestInfo . . . . . . . . . . . . . . . .  28
       5.3.9  Hello . . .  33
       5.3.5  UserInfoWanted . . . . . . . . . . . . . . . . . . . .  33
       5.3.6  UserInfo .  28
       5.3.10   HelloAck . . . . . . . . . . . . . . . . . . . . . .  28
       5.3.11   Error  34
       5.3.7  FloorInfoWanted  . . . . . . . . . . . . . . . . . . .  34
       5.3.8  FloorInfo  . . . .  29
   6.   Transport . . . . . . . . . . . . . . . . . .  34
       5.3.9  ChairAction  . . . . . . .  29
   7.   Lower-Layer Security . . . . . . . . . . . . . .  35
       5.3.10   ChairActionAck . . . . . .  30
   8.   Protocol Transactions . . . . . . . . . . . . .  35
       5.3.11   Hello  . . . . . .  30
     8.1  Client Behavior . . . . . . . . . . . . . . . . .  36
       5.3.12   HelloAck . . . .  31
     8.2  Server Behavior . . . . . . . . . . . . . . . . . .  36
       5.3.13   Error  . . .  31
   9.   Authentication and Authorization . . . . . . . . . . . . . .  31
     9.1  Client Behavior . . . . . .  36
   6.   Transport  . . . . . . . . . . . . . . .  31
     9.2  Floor Control Server Behavior . . . . . . . . . .  37
   7.   Lower-Layer Security . . . .  32
   10.  Floor Participant Operations . . . . . . . . . . . . . . . .  33
     10.1   Requesting a Floor  38
   8.   Protocol Transactions  . . . . . . . . . . . . . . . . . . .  33
       10.1.1   Sending a FloorRequest Message  38
     8.1  Client Behavior  . . . . . . . . . . .  33
       10.1.2   Receiving a Response . . . . . . . . . .  38
     8.2  Server Behavior  . . . . . .  34
     10.2   Cancelling a Floor Request and Releasing a Floor . . . .  35
       10.2.1   Sending a FloorRelease Message . . . . . . . . . . .  35
       10.2.2   Receiving a Response  38
   9.   Authentication and Authorization . . . . . . . . . . . . . .  39
     9.1  TLS-based Mutual Authentication  . .  36
   11.  Chair Operations . . . . . . . . . . .  39
     9.2  Digest-based Client Authentication . . . . . . . . . . .  36
     11.1   Sending a ChairAction Message .  39
       9.2.1  Client Behavior  . . . . . . . . . . . .  36
     11.2   Receiving a Response . . . . . . .  40
       9.2.2  Floor Control Server Behavior  . . . . . . . . . . .  37
   12.  General Client Operations .  41
   10.  Floor Participant Operations . . . . . . . . . . . . . . . .  38
     12.1  42
     10.1   Requesting Information about Floors a Floor . . . . . . . . . .  38
       12.1.1 . . . . . . . . .  42
       10.1.1   Sending a FloorInfoWanted FloorRequest Message . . . . . . . . .  38
       12.1.2 . .  43
       10.1.2   Receiving a Response . . . . . . . . . . . . . . . .  38
     12.2   Requesting Information about  43
     10.2   Cancelling a Floor Request and Releasing a Floor Requests  . . . . . .  39
       12.2.1  44
       10.2.1   Sending a FloorRequestInfoWanted FloorRelease Message . . . . . .  40
       12.2.2   Receiving a Response . . . . . .  45
       10.2.2   Receiving a Response . . . . . . . . . .  40
     12.3   Obtaining the Capabilities of a Floor Control Server . .  41
       12.3.1   Sending a Hello Message . . . .  45
   11.  Chair Operations . . . . . . . . . .  41
       12.3.2   Receiving Responses . . . . . . . . . . . .  46
     11.1   Sending a ChairAction Message  . . . .  41
   13.  Floor Control Server Operations . . . . . . . . .  46
     11.2   Receiving a Response . . . . .  41
     13.1   Reception of a FloorRequest Message . . . . . . . . . .  42
       13.1.1   Generating the First FloorRequestInfo Message . . .  42
       13.1.2   Generation of Subsequent FloorRequestInfo Messages  47
   12.  General Client Operations  .  43
     13.2   Reception of a FloorRequestInfoWanted Message . . . . .  44
       13.2.1   Information on a Single Floor Request . . . . . . .  44
       13.2.2   Information on the Floor Requests Associated to a
                Participant . . . .  47
     12.1   Requesting Information about Floors  . . . . . . . . . .  47
       12.1.1   Sending a FloorInfoWanted Message  . . . . . .  45
     13.3   Reception of a FloorRelease Message . . .  48
       12.1.2   Receiving a Response . . . . . . .  45
     13.4   Reception of a FloorInfoWanted Message . . . . . . . . .  46
       13.4.1   Generation of the First FloorInfo Message  48
     12.2   Requesting Information about Floor Requests  . . . . .  47
       13.4.2   Generation of Subsequent  FloorInfo Messages .  49
       12.2.1   Sending a FloorRequestInfoWanted Message . . . .  47
     13.5   Reception of . .  49
       12.2.2   Receiving a ChairAction Message Response . . . . . . . . . . .  48
     13.6   Reception of . . . . .  50
     12.3   Requesting Information about a Hello User  . . . . . . . . . .  50
       12.3.1   Sending a UserInfoWanted Message . . . . . . . . . .  50
       12.3.2   Receiving a Response . . . .  49
     13.7   Error . . . . . . . . . . . .  51
     12.4   Obtaining the Capabilities of a Floor Control Server . .  51
       12.4.1   Sending a Hello Message Generation  . . . . . . . . . . . . . .  51
       12.4.2   Receiving Responses  . .  49
   14.  Security Considerations . . . . . . . . . . . . . .  51
   13.  Floor Control Server Operations  . . . .  49
   15.  IANA Considerations . . . . . . . . . .  52
     13.1   Reception of a FloorRequest Message  . . . . . . . . . .  51
     15.1   Attribute Subregistry  52
       13.1.1   Generating the First FloorRequestInfo Message  . . .  53
       13.1.2   Generation of Subsequent FloorRequestInfo Messages .  54
     13.2   Reception of a FloorRequestInfoWanted Message  . . . . .  55
     13.3   Reception of a UserInfoWanted Message  . . . . . . . .  51
     15.2   Primitive Subregistry .  56
     13.4   Reception of a FloorRelease Message  . . . . . . . . . .  57
     13.5   Reception of a FloorInfoWanted Message . . . . . .  51
     15.3   Request Status Subregistry . . .  59
       13.5.1   Generation of the First FloorInfo Message  . . . . .  59
       13.5.2   Generation of Subsequent  FloorInfo Messages . . . .  60
     13.6   Reception of a ChairAction Message . . .  52
     15.4   Error Code Subregistry . . . . . . . .  61
     13.7   Reception of a Hello Message . . . . . . . . .  53
   16.  Acknowledgments . . . . .  62
     13.8   Error Message Generation . . . . . . . . . . . . . . . .  62
   14.  Security Considerations  .  54
   17.  References . . . . . . . . . . . . . . . . .  62
   15.  IANA Considerations  . . . . . . . .  54
   17.1   Normative References . . . . . . . . . . . .  64
     15.1   Attribute Subregistry  . . . . . . .  54
   17.2   Informational References . . . . . . . . . .  64
     15.2   Primitive Subregistry  . . . . . . .  55
        Authors' Addresses . . . . . . . . . .  65
     15.3   Request Status Subregistry . . . . . . . . . . .  56
        Intellectual Property and Copyright Statements . . . .  65
     15.4   Error Code Subregistry . . .  57

1. . . . . . . . . . . . . . .  66
     15.5   Digest Algorithm Subregistry . . . . . . . . . . . . . .  67
   16.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  67
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . .  68
     17.1   Normative References . . . . . . . . . . . . . . . . . .  68
     17.2   Informational References . . . . . . . . . . . . . . . .  68
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  69
        Intellectual Property and Copyright Statements . . . . . . .  70

1.  Introduction

   Within a conference, some applications need to manage the access to a
   set of shared resources, such as the right to send media over a
   particular media stream.  Floor control enables such applications to
   provide users with coordinated (shared or exclusive) access to these
   resources.

   The Requirements for Floor Control Protocol [11] [10] 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.

   In addition, BFCP has been designed so that it can be used in
   low-bandwidth 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 at
   minimum.  Delay-sensitive BFCP messages include FloorRequest,
   FloorRelease, FloorRequestInfo, and ChairAction.  It is expected that
   future extensions to these messages do not increase the size of these
   messages in a significant way.

   The remainder of this document is organized as follows. follows: Section 2
   defines the terminology used throughout this document and 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). mechanisms),
   Section 4 provides a non-normative overview of BFCP operation operation, and
   subsequent sections provide the normative specification of BFCP.

2.  Terminology

   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 [2] and indicate requirement levels for
   compliant implementations.

   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 floor-
   controlled conferences, a given media participant is typically
   co-located co-
   located with a floor participant, but does not need to.  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 communicate with a
   floor control server using BFCP.

   Conference Policy: The complete set of rules for a particular
   conference.  It includes the membership policy, the media policy, and
   policies related to floors and the use of floor control protocols.
   There is an instance of conference policy for each conference.

   Floor: A permission to temporarily 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 transaction-by-
   transaction basis.  BFCP transactions are defined in Section 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 co-located with a
   media participant, but does not need to.  Third-party floor requests
   consist of having a floor participant request a floor for a media
   participant when they are not co-located.

   Participant: An entity that acts as a floor participant, as a media
   participant, or as both.

3.  Scope

   As stated earlier, BFCP is a protocol to coordinate access to shared
   resources in a conference following the requirements defined in [11]. [10].
   Floor control complements other functions defined in the XCON
   conferencing framework [12].  In particular, it is the conference policy that
   defines which media streams and applications are floor-controlled,
   who is/are the respective floor chair(s), [12] and how access to the floor
   is managed.  Furthermore, it is up to compatible with the media policy to define
   which (if any) impact on media stream handling (e.g.  switching or
   mixing) assignment of a floor to a media participant has. SIPPING
   conferencing framework [11].  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 defined by other protocols [13]. [12].

   Figure 1 shows the tasks that BFCP can perform.

                              +---------+
                              |  Floor  |
                              |  Chair  |
                              |         |
                              +---------+
                                 ^   |
                                 |   |
                    Notification |   | Decision
                                 |   |
                                 |   |
                      Floor      |   v
   +-------------+   Request  +---------+              +-------------+
   |    Floor    |----------->|  Floor  | Notification |    Floor    |
   | Participant |            | Control |------------->| Participant |
   |             |<-----------|  Server |              |             |
   +-------------+ Granted or +---------+              +-------------+
                     Denied

                 Figure 1: Functionality provided by BFCP

   BFCP provides a means:

   o  for floor participants to send floor requests to floor control
      servers.
   o  for floor control servers to grant or deny requests to access a
      given resource from floor participants.
   o  for floor chairs to send floor control servers decisions regarding
      floor requests.
   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.

   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 to create floors and to establish BFCP
   connections between different entities.  In the following
   subsections, we discuss some of these tasks and mechanisms to perform
   them.

3.1  Floor Creation

   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 [13].  The conference policy for a particular conference
   contains the floors of the conference and the resource or resources
   associated with each floor.  For example, a conference may have two
   floors: one controlling who can talk at a particular time and another
   controlling who can write on a shared whiteboard. [12].  Floor creation and termination are also outside
   the scope of BFCP and
   are BFCP; these aspects of are handled using the conference policy as well.
   control protocol for manipulating the conference object.
   Consequently, the floor control server needs to stay up to date on
   changes on to the conference policy object (e.g., when a new floor is created).

3.2  Obtaining Information to Contact a Floor Control Server

   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 the user identifier.

   Clients can obtain this information in different ways.  One is to use
   an offer/answer [10] exchange.  How to use an SDP [8] offer/answer
   [10] exchange to obtain this information [9] exchange, which is described in [14]. [13].  Other
   mechanisms are also described in the XCON framework (and other
   related documents).

3.3  Generating a Shared Secret

   Authentication in BFCP is based on a shared secret between the client
   and the floor control server.  So, there is a need for a mechanism to
   generate such a shared secret.  However, such mechanism is outside
   the scope of BFCP.

   Shared secrets can also be generated and exchanged using out-of-band
   means.  For example, when the floor participant or the floor chair
   obtains the information needed to contact the BFCP floor control
   server over a secure channel (e.g., an offer/answer [10] [9] exchange
   using SIP [9] [8] protected using S/MIME), they can get the shared secret
   using the same channel.

3.4  Obtaining Floor-Resource Associations

   Floors are associated with resources.  For example, a floor that
   controls who talks at a given time has a particular audio stream as
   its associated resource.  Associations between floors and resources
   are part of the conference policy. object.

   Floor participants and floor chairs need to know which resources are
   associated with which floors.  They can obtain this information using
   different mechanisms, such as an offer/answer [10] [9] exchange.  How to
   use an offer/answer exchange to obtain these associations is
   described in [14]. [13].

      Note that floor participants perform offer/answer exchanges with
      the SIP focus Focus of the conference.  So, the SIP focus 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 offer/answer exchange.

   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 (and other related documents).

3.5  Policy Enforcement  Privileges of Floor Control

   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.  According to the definition in
   Section 2, the conference policy determines  Determination of which media
   participants can actually use the resources in the conference.

   So, if the policy of a conference is to enforce floor control
   decisions, every change in the status of any floor needs to be
   reflected
   discussed in the conference policy of the conference.  For example,
   the mixer only accepts media from the user who holds the floor. XCON Framework.

4.  Overview of Operation

   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 messages, which use a TLV (Type-Length-Value) binary encoding,
   consist of a common header followed by a set of TLVs. attributes.  The
   common header contains, among other information, a 32-bit conference
   identifier.  Floor participants, media participants, and floor chairs
   are identified by a 16-bit user identifier, which is carried in an
   attribute.

   Participant authentication in BFCP is based on shared secrets.  The
   floor control server of a conference shares a
   TLV. secret with each of the
   participants in the conference and can request them to sign their
   messages using that shared secret.

   BFCP supports nested attributes (i.e., attributes that contain
   attributes).  These are referred to as grouped attributes.

   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 TLV. attribute.  Server-initiated transactions consist of a
   single message, which has no TRANSACTION-ID TLV, attribute, from the floor
   control server to a client.

4.1  Floor Participant to Floor Control Server Interface

   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 co-located with the media participant that will get the
   floor once the floor request is granted.  FloorRequest messages carry
   the identity of the requester in a USER-ID TLV, attribute, and the
   identity of the beneficiary of the floor, in third party floor
   requests, in a BENEFICIARY-ID TLV. attribute.

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

   FloorRequest messages identify the floor or floors being requested by
   carrying their 16-bit floor identifiers in FLOOR-ID TLVs. 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.

   Floor control servers respond to FloorRequest messages with
   FloorRequestInfo messages, which provide information about the status
   of the floor request.  The first FloorRequestInfo message is the
   response to the FloorRequest message from the client, and therefore
   carries the same TRANSACTION-ID TLV attribute as the FloorRequest.

   Additionally, the first FloorRequestInfo message carries the Floor
   Request ID in a
   FLOOR-REQUEST-ID TLV. FLOOR-REQUEST-INFORMATION attribute.  Subsequent
   FloorRequestInfo messages related to the same floor request will
   carry the same FLOOR-REQUEST-ID TLV. Floor Request ID.  This way, the floor participant can
   associate them with the appropriate floor request.

   Messages from the floor participant related to a particular floor
   request also use the same FLOOR-REQUEST-ID TLV Floor Request ID as the first
   FloorRequestInfo Message from the floor control server.

   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 TLVs, attributes, of the TRANSACTION-ID and the
   FLOOR-REQUEST-ID
   TLVs. attributes.

     Floor Participant                                 Floor Control
                                                          Server
             |(1) FloorRequest                               |
             |TRANSACTION-ID: 123                            |
             |USER-ID: 234                                   |
             |TRANSACTION-ID: 123                            |
             |FLOOR-ID: 543                                  |
             |---------------------------------------------->|
             |                                               |
             |(2) FloorRequestInfo                           |
             |TRANSACTION-ID: 123                            |
             |USER-ID: 234                                   |
             |FLOOR-REQUEST-ID:
             |TRANSACTION-ID: 123                            |
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Pending                  |
             |<----------------------------------------------|
             |                                               |
             |(3) FloorRequestInfo                           |
             |USER-ID: 234                                   |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Accepted (1st in Queue)  |
             |<----------------------------------------------|
             |                                               |
             |(4) FloorRequestInfo                           |
             |USER-ID: 234                                   |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Granted                  |
             |<----------------------------------------------|
             |                                               |
             |(5) FloorRelease                               |
             |TRANSACTION-ID: 154                            |
             |USER-ID: 234                                   |
             |TRANSACTION-ID: 154                            |
             |FLOOR-REQUEST-ID: 789                          |
             |---------------------------------------------->|
             |                                               |
             |(6) FloorRequestInfo                           |
             |USER-ID: 234                                   |
             |TRANSACTION-ID: 154                            |
             |USER-ID: 234
             |FLOOR-REQUEST-INFORMATION                      |
             |FLOOR-REQUEST-ID:
             |      Floor Request ID: 789                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Released                 |
             |<----------------------------------------------|
                Figure 2: Requesting and releasing a floor

   Figure 2 3 shows how a floor participant requests to be informed on the
   status of a floor.  The first FloorInfo message from the floor
   control server is the response to the FloorInfoWanted message, and as
   such, carries the same TRANSACTION-ID TLV attribute as the
   FloorInfoWanted message.

   Subsequent FloorInfo messages consist of server-initiated
   transactions, and therefore carry no TRANSACTION-ID TLV. attribute.
   FloorInfo message (2) indicates that there are currently two floor
   requests for the floor whose Floor ID is 543.  FloorInfo message (3)
   indicates that the floor requests with Floor Request ID 764 has been
   granted, while the floor request with Floor Request ID 635 is the
   first in the queue.  FloorInfo message (4) indicates that the floor
   request with Floor Request ID 635 has been granted.

     Floor Participant                                 Floor Control
                                                          Server
             |(1) FloorInfoWanted                            |
             |TRANSACTION-ID: 257                            |
             |USER-ID: 234                                   |
             |TRANSACTION-ID: 257                            |
             |FLOOR-ID: 543                                  |
             |---------------------------------------------->|
             |                                               |
             |(2) FloorInfo                                  |
             |TRANSACTION-ID: 257                            |
             |USER-ID: 234                                   |
             |TRANSACTION-ID: 257                            |
             |FLOOR-ID:543                                   |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 764                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |BENEFICIARY-ID:
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 124          |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Accepted (1st in Queue)  |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 635                    |
             |BENEFICIARY-ID: 154
             |
             |FLOOR-ID:      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 154          |
             |      REQUEST-STATUS: Accepted (2nd in Queue)  |
             |<----------------------------------------------|
             |                                               |
             |(3) FloorInfo                                  |
             |USER-ID: 234                                   |
             |FLOOR-ID:543                                   |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 764                    |
             |FLOOR-ID:
             |      FLOOR-ID: 543                            |
             |BENEFICIARY-ID:
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 124          |
             |REQUEST-STATUS:
             |      REQUEST-STATUS: Granted                  |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 635                    |
             |BENEFICIARY-ID: 154
             |
             |FLOOR-ID:      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 154          |
             |      REQUEST-STATUS: Accepted (1st in Queue)  |
             |<----------------------------------------------|
             |                                               |
             |(4) FloorInfo                                  |
             |USER-ID: 234                                   |
             |FLOOR-ID:543                                   |
             |FLOOR-REQUEST-ID:
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 635                    |
             |BENEFICIARY-ID: 154
             |
             |FLOOR-ID:      FLOOR-ID: 543                            |
             |REQUEST-STATUS:
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 154          |
             |      REQUEST-STATUS: Granted                  |
             |<----------------------------------------------|

           Figure 3: Obtaining status information about a floor

   FloorInfo messages contain information about the floor requests they
   carry.  For example, FloorInfo 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.

      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 the floors.

4.2  Floor Chair to Floor Control Server Interface

   Figure 4 shows a floor chair instructing a floor control server to
   grant a floor.  Note, however, that although the floor control server
   needs to take into consideration the instructions received in
   ChairAction messages (e.g., granting a floor), it does not
   necessarily need to perform them exactly as requested by the floor
   chair.  The operation that the floor control server performs depends
   on the ChairAction message and on the internal state of the floor
   control server.

   For example, a floor chair may send a ChairAction message granting a
   floor which 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 to keep 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                                   |
             |TRANSACTION-ID: 769                            |
             |FLOOR-ID: 543                                  |
             |FLOOR-REQUEST-ID: 635                          |
             |REQUEST-STATUS: Granted                        |
             |---------------------------------------------->|
             |                                               |
             |(2) ChairActionAck                             |
             |TRANSACTION-ID: 769                            |
             |USER-ID: 357                                   |
             |TRANSACTION-ID: 769                            |
             |<----------------------------------------------|

           Figure 4: Chair instructing the floor control server

5.  Packet Format

   BFCP packets consist of an 8-byte fixed header followed by
   attributes.  All the protocol values MUST be sent in network byte
   order.

5.1  FIXED-HEADER Format

   The following is the FIXED-HEADER format.

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

                       Figure 5: FIXED-HEADER format

   Ver: the 3-bit version field MUST be set to 1 to indicate this
   version of 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.

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

       +-------+------------------------+-----------------------+
       | Value | Primitive              | Direction             |
       +-------+------------------------+-----------------------+
       |   0   1   | FloorRequest           | P -> S                |
       |   1   2   | FloorRelease           | P -> S                |
       |   2   3   | FloorRequestInfoWanted | P -> S ; Ch -> S      |
       |   3   4   | FloorRequestInfo       | P <- S ; Ch <- S      |
       |   4   5   | FloorInfoWanted UserInfoWanted         | P -> S ; Ch -> S      |
       |   5   6   | FloorInfo UserInfo               | P <- S ; Ch <- S      |
       |   6   7   | ChairAction FloorInfoWanted        | P -> S ; Ch -> S      |
       |   7   8   | FloorInfo              | P <- S ; Ch <- S      |
       |   9   | ChairAction            | Ch -> S               |
       |   10  | ChairActionAck         | Ch <- S               |
       |   8   11  | Hello                  | P -> S ; Ch -> S      |
       |   9   12  | HelloAck               | P <- S ; Ch <- S      |
       |   10   13  | Error                  | P <- S ; Ch <- S      |
       +-------+------------------------+-----------------------+

         S:  Floor Control Server
         P:  Floor Participant
         Ch: Floor Chair
                         Table 1: BFCP primitives

   Payload Length: this 16-bit field contains length of the message in
   4-byte units excluding the fixed header.

   Conference ID: this 32-bit field identifies the conference the
   message belongs to.

5.2  Attribute Format

   BFCP attributes are encoded in TLV (Type-Length-Value) format.  TLVs
   Attributes are 32-bit aligned.

      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: TLV Attribute format

   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:

      Unsigned16: the contents of the attribute consist of a 16-bit
      unsigned integer.

      OctetString16: the contents of the attribute consist of 16 bits of
      arbitrary data.

      OctetString: the contents of the attribute consist of arbitrary
      data of variable length.

      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                 |
                     +------+---------------------+
                     |   0  | FLOOR-ID Format        |
          +------+---------------------------+---------------+
          |   1  | USER-ID BENEFICIARY-ID            | Unsigned16    |
          |   2  | BENEFICIARY-ID FLOOR-ID                  | Unsigned16    |
          |   3  | TRANSACTION-ID FLOOR-REQUEST-ID          | Unsigned16    |
          |   4  | FLOOR-REQUEST-ID NONCE                     | Unsigned16    |
          |   5  | HUMAN-READABLE-INFO TRANSACTION-ID            | Unsigned16    |
          |   6  | DIGEST USER-ID                   | Unsigned16    |
          |   7  | REQUEST-STATUS PRIORITY                  | OctetString16 |
          |   8  | ERROR-CODE REQUEST-STATUS            | OctetString16 |
          |   9  | USER-DISPLAY-NAME DIGEST                    | OctetString   |
          |  10  | USER-URI ERROR-CODE                | OctetString   |
          |  11  | PRIORITY ERROR-INFO                | OctetString   |
          |  12  | NONCE PARTICIPANT-PROVIDED-INFO | OctetString   |
          |  13  | SUPPORTED-TLVS STATUS-INFO               | OctetString   |
          |  14  | SUPPORTED-ATTRIBUTES      | OctetString   |
          |  15  | SUPPORTED-PRIMITIVES      | OctetString   |
          |  16  | USER-DISPLAY-NAME         | OctetString   |
          |  17  | USER-URI                  | OctetString   |
          |  18  | BENEFICIARY-INFORMATION   | Grouped       |
          |  19  | FLOOR-REQUEST-INFORMATION | Grouped       |
                     +------+---------------------+
          |  20  | REQUESTED-BY-INFORMATION  | Grouped       |
          +------+---------------------------+---------------+

                         Table 2: BFCP attributes

   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.

   Length: this 8-bit field contains the length of the attribute in
   bytes, excluding any padding defined for specific attributes.  The
   Type, 'M' bit, and Length fields are included.  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.

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

5.2.1  FLOOR-ID  BENEFICIARY-ID

   The following is the format of the FLOOR-ID BENEFICIARY-ID 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 0 0 0|M|0 1|M|0 0 0 0 0 1 0 0|           Floor        Beneficiary ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7: FLOOR-ID BENEFICIARY-ID format

   Floor

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

5.2.2

   Note that although the formats of the BENEFICIARY-ID attribute and of
   the USER-ID attribute (see Figure 12) are similar, their semantics
   are different.  The BENEFICIARY-ID attribute is used in third-party
   floor requests and to request information about a particular
   participant.

5.2.2  FLOOR-ID

   The following is the format of the USER-ID FLOOR-ID 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 0 0 1|M|0 1 0|M|0 0 0 0 0 1 0 0|            User           Floor ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 8: USER-ID FLOOR-ID format

   User

   Floor ID: this field contains a 16-bit value that uniquely identifies
   a user floor within a conference.

5.2.3  BENEFICIARY-ID  FLOOR-REQUEST-ID

   The following is the format of the BENEFICIARY-ID FLOOR-REQUEST-ID 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 0 1 0|M|0 1|M|0 0 0 0 0 1 0 0|        Beneficiary       Floor Request ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: BENEFICIARY-ID FLOOR-REQUEST-ID format

   Beneficiary

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

5.2.4  TRANSACTION-ID  NONCE

   The following is the format of the TRANSACTION-ID NONCE 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 0 1 1|M|0 0 0|M|0 0 0 0 0 1 0 0|        Transaction ID          Nonce Value          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 10: TRANSACTION-ID NONCE format

   Transaction ID:

   Nonce Value: this 16-bit field contains a 16-bit value that allows users
   to match a given message with its response. nonce.

5.2.5  FLOOR-REQUEST-ID  TRANSACTION-ID

   The following is the format of the FLOOR-REQUEST-ID TRANSACTION-ID 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 1|M|0 0 0 0 0 1 0 0|       Floor Request        Transaction ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 11: FLOOR-REQUEST-ID TRANSACTION-ID format

   Floor Request

   Transaction ID: this field contains a 16-bit value that indentifies allows users
   to match a floor request at the floor control server. given message with its response.

5.2.6  HUMAN-READABLE-INFO  USER-ID

   The following is the format of the HUMAN-READABLE-INFO USER-ID 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|0 0 1|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding 0 0 0 1 0 0|            User ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 12: HUMAN-READABLE-INFO USER-ID format

   Text:

   User ID: this field contains UTF-8 [7] encoded text.

   In some situations, the contents of the Text field may be generated
   by an automaton.  If such automaton has information about the
   preferred language of the receiver of a particular
   HUMAN-READABLE-INFO TLV, it MAY use this language to generate the
   Text field.

   Padding: one, two, or three bytes of padding added so 16-bit value that uniquely identifies
   a participant within a conference.

   The identify used by a participant in BFCP, which is carried in the
   contents of the HUMAN-READABLE-INFO TLV
   User ID field, is 32-bit aligned.  The
   Padding bits SHOULD be set generally mapped to zero by the sender and MUST be ignored identity used by the receiver.  If same
   participant in the TLV session establishment protocol (e.g., in SIP).
   The way this mapping is already 32-bit aligned, no padding performed is
   needed. outside the scope of this
   specification.

5.2.7  DIGEST  PRIORITY

   The following is the format of the DIGEST 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 1 0|M|0 1|M|0 0 0 0 0 1 1 0 0|Prio |         Reserved        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 13: PRIORITY format

   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 had been 4
   (Highest).  The default priority value when the PRIORITY attribute is
   missing is 2 (Normal).

                          +-------+----------+
                          | Value | Priority |
                          +-------+----------+
                          |   0 0|   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + Lowest   |
                          |
     +                                                               +   1   | Low      |
     +                          HMAC-SHA1                            +
                          |   2   |
     +                                                               + Normal   |
                          |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   3   | High     |             Padding
                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 13: DIGEST format

   HMAC-SHA1:   4   | Highest  |
                          +-------+----------+

                         Table 3: Priority values

   Reserved: at this 20-byte field contains an HMAC-SHA1 [1] of point, the BFCP
   message.  Its calculation is described 13 bits in Section 9.

   Padding: two bytes of padding added so that the contents of the
   HMAC-SHA1 TLV is 32-bit aligned.  The Padding bits reserved field SHOULD be
   set to zero by the sender of the message and MUST be ignored by the
   receiver.

5.2.8  REQUEST-STATUS

   The following is the format of the REQUEST-STATUS 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 1|M|0 0 0 0|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 14: REQUEST-STATUS format

   Request Status: this 8-bit field contains the status of the request,
   as described in the following table.

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

                      Table 3: 4: Request Status values

   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, the
   floor control server does not implement a floor request queue, or 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.

   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.

5.2.9  ERROR-CODE  DIGEST

   The following is the format of the ERROR-CODE DIGEST 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 1|M|0 0 0 1 1 0 0 0|   Algorithm   |          Error Code               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
     |                                                               |
     +                                                               +
     |                     Error Specific Details                                                               |
     /                                                               /
     /
     +                           Digest                              +
     |                                                               |
     +                                                               +
     |                                                               |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 15: ERROR-CODE DIGEST format

   Error Code:

   Algorithm: this 16-bit 8-bit field contains an error code from the identifier of the algorithm
   used to calculate the keyed digest.  The following table.

   +---------------------------------+---------------------------------+
   |              Value              | Meaning                         |
   +---------------------------------+---------------------------------+
   |                0                | Conference does not Exist       |
   |                1                | Authentication Failed are the algorithm
   identifiers defined:

       +------------+-----------+---------------+--------------+
       | Identifier |                2 Algorithm | Unknown Mandatory TLV Digest Length | Reference    |                3
       +------------+-----------+---------------+--------------+
       | Floor Request ID Does Not Exist      0     | HMAC-SHA1 |                4    20 bytes   | Unauthorized Operation          |
   |                5                | User does not Exist             |
   |                6                | Invalid Nonce                   |
   |                7 RFC 2104 [1] |
       +------------+-----------+---------------+--------------+

                        Table 5: Digest algorithms

      The text used as input to the digest algorithm is the BFCP
      message, including the FIXED-HEADER, up to and including the
      attribute preceding the DIGEST TLV Required             |
   |                8                | Invalid Floor ID                |
   |                9                | You have Already Reached attribute.  Depending on the    |
   |                                 | Maximum Number of Ongoing Floor |
   |                                 | Requests for this Floor         |
   +---------------------------------+---------------------------------+

                      Table 4: Error Code meaning

   Error Specific Details: Present only for certain Error Codes.  In
      algorithm, this document, only for Error Code 2 (Unknown Mandatory TLV).  For
   Error Code 2, text may need to be padded with zeroes.  When
      HMAC-SHA1 is used, the input text needs to be padded so as to be a
      multiple of 64 bytes.
      The key used as input to the keyed digest is the secret shared
      between the server and the user identified by the USER-ID
      attribute in the message.

   Digest: this field contains the Types a keyed digest of the TLVs (which were
   present BFCP message.  Its
   calculation is described in the message Section 9.

   Padding: padding added so that triggered the Error message) that were
   unknown contents of the DIGEST attribute
   is 32-bit aligned.  The Padding bits SHOULD be set to zero by the receiver, encoded as follows.
   sender and MUST be ignored by the receiver.

5.2.10  ERROR-CODE

   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 1 0 1 0|M|    Length     |      Unknown TLV Type  Error Code   |      Unknown TLV Type               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                     Error Specific Details                    |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      Unknown TLV Type            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 16: Unknown TLVs ERROR-CODE format

   Padding:

   Error Code: this 8-bit field contains an error code from the
   following table.

   +---------------------------------+---------------------------------+
   |              Value              | Meaning                         |
   +---------------------------------+---------------------------------+
   |                1                | Conference does not Exist       |
   |                2                | User does not Exist             |
   |                3                | DIGEST Attribute Required       |
   |                4                | Invalid Nonce                   |
   |                5                | Authentication Failed           |
   |                6                | Unknown Primitive               |
   |                7                | Unknown Mandatory Attribute     |
   |                8                | Unauthorized Operation          |
   |                9                | Invalid Floor ID                |
   |                10               | Floor Request ID Does Not Exist |
   |                11               | You have Already Reached the    |
   |                                 | Maximum Number of Ongoing Floor |
   |                                 | Requests for this Floor         |
   +---------------------------------+---------------------------------+

                        Table 6: Error Code meaning

   Error Specific Details: Present only for certain Error Codes.  In
   this document, only for Error Code 3 (DIGEST Attribute Needed) and
   Error Code 7 (Unknown Mandatory Attribute).  See Section 5.2.10.1 and
   Section 5.2.10.2 for their respective definitions.

   Padding: one, two, or three bytes of padding added so that the
   contents of the ERROR-CODE TLV attribute is 32-bit aligned.  If the TLV
   attribute is already 32-bit aligned, no padding is needed.

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

5.2.10.1  Error Codes defined in this
   document but Error Code 2, result in a TLV which is already 32-bit
   aligned (i.e., no need of padding). Specific Details for Error Code 2 results in a TLV
   that may need 2 bytes of padding.

5.2.10  USER-DISPLAY-NAME 3

   The format of the USER-DISPLAY-NAME attribute following is the same as the
   HUMAN-READABLE-INFO attribute (still, they have different attribute
   types).  The Text field in the USER-DISPLAY-NAME attribute contains
   the name of the user.

5.2.11  USER-URI

   The format of the USER-URI attribute is the same as the
   HUMAN-READABLE-INFO attribute (still, they have different attribute
   types).  The Text Error Specific Details field in the USER-URI attribute contains the URI of
   the user.

5.2.12  PRIORITY

   The following is the format of the PRIORITY attribute. for
   Error Code 3.

      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|0 0 0 0 0 1 0 0|   Priority
     |   Reserved Algorithm ID  | Algorithm ID  | Algorithm ID  | Algorithm ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               | Algorithm ID  | Algorithm ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Algorithm ID  | Algorithm ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 17: PRIORITY Digest algorithms format

   Priority: the higher the

   Algorithm ID: these 8-bit value, the more priority is requested
   for a given floor request.

   Reserved: at this point, fields contain the 8 bits in identifiers of the reserved field SHOULD be
   set to zero
   digest algorithms supported by the sender floor control server in order of
   preference (i.e., the message and MUST be ignored by first algorithm is the
   receiver.

5.2.13  NONCE most preferred).

5.2.10.2  Error Specific Details for Error Code 7

   The following is the format of the NONCE attribute. Error Specific Details field for
   Error Code 7.

      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
     |          Nonce Value 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 18: NONCE Unknown attributes format

   Nonce Value:

   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

   R: at this 16-bit field contains a nonce.

5.2.14  SUPPORTED-TLVS point, this bit is reserved.  It SHOULD be set to zero by
   the sender of the message and MUST be ignored by the receiver.

5.2.11  ERROR-INFO

   The following is the format of the SUPPORTED-TLVS ERROR-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 1 0 1 1|M|    Length     |         Supported TLV         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Supported TLV                               |         Supported TLV
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                             Text                              /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 19: SUPPORTED-TLVS ERROR-INFO format

   Supported TLV: these fields contain

   Text: this field contains UTF-8 [7] encoded text.

   In some situations, the Types contents of the TLVs that are
   supported Text field may be generated
   by the floor control server. an automaton.  If such 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: two one, two, or three bytes of padding added so that the
   contents of the
   SUPPORTED-TLVS TLV ERROR-INFO attribute is 32-bit aligned.  If the TLV is already 32-bit
   aligned, no padding is needed.  The Padding
   bits SHOULD be set to zero by the sender and MUST be ignored by the
   receiver.

5.3  Message Format

   This section contains the normative ABNF [3] of the BFCP messages.

5.3.1  FloorRequest

   Floor participants request a floor by sending a FloorRequest message
   to  If the floor control server. attribute is already 32-bit aligned, no padding is
   needed.

5.2.12  PARTICIPANT-PROVIDED-INFO

   The following is the format of the
   FloorRequest message:

   FloorRequest =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [BENEFICIARY-ID]
                   *(FLOOR-ID)
                    [HUMAN-READABLE-INFO]
                    [PRIORITY]
                    [NONCE]
                    [DIGEST] 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 1 0 0|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 20: FloorRequest PARTICIPANT-PROVIDED-INFO format

5.3.2  FloorRelease

   Floor participants release a floor by sending a FloorRelease message
   to

   Text: this field contains UTF-8 [7] encoded text.

   Padding: one, two, or three bytes of padding added so that the floor control server.  Floor participants also use
   contents of the
   FloorRelease message PARTICIPANT-PROVIDED-INFO attribute is 32-bit
   aligned.  The Padding bits SHOULD be set to cancel pending floor requests. zero by the sender and
   MUST be ignored by the receiver.  If the attribute is already 32-bit
   aligned, no padding is needed.

5.2.13  STATUS-INFO

   The following is the format of the FloorRelease message:

   FloorRelease =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    (FLOOR-REQUEST-ID)
                    [NONCE]
                    [DIGEST]

                     Figure 21: FloorRelease STATUS-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 1 0 1|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 21: STATUS-INFO format

5.3.3  FloorRequestInfoWanted

   Floor participants and floor chairs request

   Text: this field contains UTF-8 [7] encoded text.

   In some situations, the contents of the Text field may be generated
   by an automaton.  If such automaton has information about the
   preferred language of the receiver of a floor
   request by sending a FloorRequestInfoWanted message particular STATUS-INFO
   attribute, it MAY use this language to generate the floor
   control server.  The following is Text field.

   Padding: one, two, or three bytes of padding added so that the format
   contents of the
   FloorRequestInfoWanted message:

   FloorRequestInfoWanted =   (FIXED-HEADER)
                              (TRANSACTION-ID)
                              (USER-ID)
                              [BENEFICIARY-ID]
                              [FLOOR-REQUEST-ID]
                              [NONCE]
                              [DIGEST]

                Figure 22: FloorRequestInfoWanted format

5.3.4  FloorRequestInfo STATUS-INFO attribute is 32-bit aligned.  The floor control server informs floor participants and floor chairs
   about the status of their floor requests Padding
   bits SHOULD be set to zero by sending them
   FloorRequestInfo messages.  The following is the format of the
   FloorRequestInfo message:

   FloorRequestInfo =     (FIXED-HEADER)
                          (TRANSACTION-ID)
                          (USER-ID)
                          [BENEFICIARY-ID]
                          [USER-DISPLAY-NAME]
                          [USER-URI]
                     1*(  (FLOOR-REQUEST-ID)
                        1*(FLOOR-ID)
                          [HUMAN-READABLE-INFO]
                          [PRIORITY]
                          (REQUEST-STATUS)     )
                          [NONCE]

                   Figure 23: FloorRequestInfo format

5.3.5  FloorInfoWanted

   Floor participants sender and floor chairs request information about a floor
   or floors MUST be ignored by sending a FloorInfoWanted message to the floor control
   server.
   receiver.  If the attribute is already 32-bit aligned, no padding is
   needed.

5.2.14  SUPPORTED-ATTRIBUTES

   The following is the format of the FloorRequest message:

   FloorInfoWanted =   (FIXED-HEADER)
                       (TRANSACTION-ID)
                       (USER-ID)
                      *(FLOOR-ID)
                       [NONCE]
                       [DIGEST] SUPPORTED-ATTRIBUTES attribute.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 1 1 0|M|    Length     |      Supported Attribute      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Supported Attribute      |      Supported Attribute      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 24: FloorInfoWanted 22: SUPPORTED-ATTRIBUTES format

5.3.6  FloorInfo

   Supported Attribute: these fields contain the Types of the attributes
   that are supported by the floor control server.

   Padding: two bytes 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.

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

5.2.15  SUPPORTED-PRIMITIVES

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 1 1 1|M|    Length     |   Primitive   |   Primitive   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Primitive   |   Primitive   |   Primitive   |   Primitive   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 23: SUPPORTED-PRIMITIVES format

   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.

   Padding: one, two, or three bytes 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.

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

5.2.16  USER-DISPLAY-NAME

   The following is the format of the USER-DISPLAY-NAME 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 1 0 0 0 0|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 24: USER-DISPLAY-NAME format

   Text: this field contains the UTF-8 encoded name of the user.

   Padding: one, two, or three bytes 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.

5.2.17  USER-URI

   The following is the format of the USER-URI 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 1 0 0 0 1|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 25: USER-URI format

   Text: this field contains the UTF-8 encoded URI of the user.

   Padding: one, two, or three bytes 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.

5.2.18  BENEFICIARY-INFORMATION

   The BENEFICIARY-INFORMATION attribute is a grouped attribute that
   consists of a header, which is referred to as BENEFICIARY-
   INFORMATION-HEADER, followed by a sequence of attributes.  The
   following is the format of the BENEFICIARY-INFORMATION-HEADER:

      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     |        Beneficiary ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 26: BENEFICIARY-INFORMATION-HEADER format

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

   The following is the ABNF (Augmented Backus-Naur Form) [3] of the
   BENEFICIARY-INFORMATION grouped attribute.  (EXTENSION-ATTRIBUTE
   refers to extension attributes that may be defined in the future.)

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

                 Figure 27: BENEFICIARY-INFORMATION format

5.2.19  FLOOR-REQUEST-INFORMATION

   The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
   consists of a header, which is referred to as FLOOR-REQUEST-
   INFORMATION-HEADER, followed by a sequence of attributes.  The
   following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:

      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 1|M|    Length     |       Floor Request ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 28: FLOOR-REQUEST-INFORMATION-HEADER format

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

   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 =   (FLOOR-REQUEST-INFORMATION-HEADER)
                                 (REQUEST-STATUS)
                               1*(FLOOR-ID)
                                 [BENEFICIARY-INFORMATION]
                                 [REQUESTED-BY-INFORMATION]
                                 [PRIORITY]
                                 [PARTICIPANT-PROVIDED-INFO]
                                 [STATUS-INFO]
                                *[EXTENSION-ATTRIBUTE]

                Figure 29: FLOOR-REQUEST-INFORMATION format

5.2.20  REQUESTED-BY-INFORMATION

   The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
   consists of a header, which is referred to as REQUESTED-BY-
   INFORMATION-HEADER, followed by a sequence of attributes.  The
   following is the format of the REQUESTED-BY-INFORMATION-HEADER:

      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 1 0 0|M|    Length     |       Requested-by ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 30: REQUESTED-BY-INFORMATION-HEADER format

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

   The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
   attribute.  (EXTENSION-ATTRIBUTE refers to extension attributes that
   may be defined in the future.)

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

                Figure 31: REQUESTED-BY-INFORMATION format

5.3  Message Format

   This section contains the normative ABNF (Augmented Backus-Naur Form)
   [3] of the BFCP messages.  Extension attributes that may be defined
   in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.

5.3.1  FloorRequest

   Floor participants request a floor by sending a FloorRequest message
   to the floor control server.  The following is the format of the
   FloorRequest message:

   FloorRequest =   (FIXED-HEADER)
                    (USER-ID)
                    (TRANSACTION-ID)
                   *(FLOOR-ID)
                    [BENEFICIARY-ID]
                    [PARTICIPANT-PROVIDED-INFO]
                    [PRIORITY]
                   *[EXTENSION-ATTRIBUTE]
                    [NONCE]
                    [DIGEST]

                      Figure 32: FloorRequest format

5.3.2  FloorRelease

   Floor participants release a floor by sending a FloorRelease message
   to the floor control server.  Floor participants also use the
   FloorRelease message to cancel pending floor requests.  The following
   is the format of the FloorRelease message:

   FloorRelease =   (FIXED-HEADER)
                    (USER-ID)
                    (TRANSACTION-ID)
                    (FLOOR-REQUEST-ID)
                   *[EXTENSION-ATTRIBUTE]
                    [NONCE]
                    [DIGEST]

                      Figure 33: FloorRelease format

5.3.3  FloorRequestInfoWanted

   Floor participants and floor chairs request information about a floor
   request by sending a FloorRequestInfoWanted message to the floor
   control server.  The following is the format of the
   FloorRequestInfoWanted message:

   FloorRequestInfoWanted =   (FIXED-HEADER)
                              (USER-ID)
                              (TRANSACTION-ID)
                              (FLOOR-REQUEST-ID)
                             *[EXTENSION-ATTRIBUTE]
                              [NONCE]
                              [DIGEST]

                 Figure 34: FloorRequestInfoWanted format

5.3.4  FloorRequestInfo

   The floor control server informs floor participants and floor chairs
   about the status of their floor requests by sending them
   FloorRequestInfo messages.  The following is the format of the
   FloorRequestInfo message:

   FloorRequestInfo =     (FIXED-HEADER)
                          (USER-ID)
                          [TRANSACTION-ID]
                          (FLOOR-REQUEST-INFORMATION)
                          [NONCE]
                         *[EXTENSION-ATTRIBUTE]

                    Figure 35: FloorRequestInfo format

5.3.5  UserInfoWanted

   Floor participants and floor chairs request information about a
   participant and the floor requests related to this participant by
   sending a UserInfoWanted message to the floor control server.  The
   following is the format of the UserInfoWanted message:

   UserInfoWanted =   (FIXED-HEADER)
                      (TRANSACTION-ID)
                      (USER-ID)
                      [BENEFICIARY-ID]
                     *[EXTENSION-ATTRIBUTE]
                      [NONCE]
                      [DIGEST]

                     Figure 36: UserInfoWanted format

5.3.6  UserInfo

   The floor control server provide information about participants and
   their related floor requests to floor participants and floor chairs
   by sending them UserInfo messages.  The following is the format of
   the UserInfo message:

   UserInfo =     (FIXED-HEADER)
                  (TRANSACTION-ID)
                  (USER-ID)
                  [BENEFICIARY-INFORMATION]
                1*(FLOOR-REQUEST-INFORMATION)
                  [NONCE]
                 *[EXTENSION-ATTRIBUTE]

                        Figure 37: UserInfo format

5.3.7  FloorInfoWanted

   Floor participants and floor chairs request information about a floor
   or floors by sending a FloorInfoWanted message to the floor control
   server.  The following is the format of the FloorRequest message:

   FloorInfoWanted =   (FIXED-HEADER)
                       (USER-ID)
                       (TRANSACTION-ID)
                      *(FLOOR-ID)
                      *[EXTENSION-ATTRIBUTE]
                       [NONCE]
                       [DIGEST]

                     Figure 38: FloorInfoWanted format

5.3.8  FloorInfo

   The floor control server informs floor participants and floor chairs
   about the status (e.g., the current holder) of a floor by sending
   them FloorInfo messages.  The following is the format of the
   FloorInfo message:

   FloorInfo        =       (FIXED-HEADER)
                            (USER-ID)
                            [TRANSACTION-ID]
                            (FLOOR-ID)
                           *[FLOOR-REQUEST-INFORMATION]
                            [NONCE]
                           *[EXTENSION-ATTRIBUTE]

                        Figure 39: FloorInfo format

5.3.9  ChairAction

   Floor chairs send instructions to floor control servers by sending
   ChairAction messages.  The following is the format of the ChairAction
   message:

   ChairAction  =   (FIXED-HEADER)
                    (USER-ID)
                    (TRANSACTION-ID)
                  1*(FLOOR-ID)
                    (FLOOR-REQUEST-ID)
                    (REQUEST-STATUS)
                    [STATUS-INFO]
                   *[EXTENSION-ATTRIBUTE]
                    [NONCE]
                    [DIGEST]

                       Figure 40: ChairAction format

5.3.10  ChairActionAck

   Floor control servers confirm that they have accepted a ChairAction
   message by sending a ChairActionAck message.  The following is the
   format of the ChairActionAck message:

   ChairActionAck  =   (FIXED-HEADER)
                       (USER-ID)
                       (TRANSACTION-ID)
                       [NONCE]
                      *[EXTENSION-ATTRIBUTE]

                     Figure 41: ChairActionAck format

5.3.11  Hello

   Floor participants and floor chairs check the liveness of floor
   control servers by sending a Hello message.  The following is the
   format of the Hello message:

   Hello         =  (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                   *[EXTENSION-ATTRIBUTE]
                    [NONCE]
                    [DIGEST]

                          Figure 42: Hello format

5.3.12  HelloAck

   Floor control servers confirm that they are alive on reception of a
   Hello message by sending a HelloAck message.  The following is the
   format of the HelloAck message:

   HelloAck      =  (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    (SUPPORTED-PRIMITIVES)
                    (SUPPORTED-ATTRIBUTES)
                    [NONCE]
                   *[EXTENSION-ATTRIBUTE]

                        Figure 43: HelloAck format

5.3.13  Error

   Floor control servers inform floor participants and floor chairs
   about errors processing requests by sending them Error messages.  The
   following is the format of the Error message:

   Error              =   (FIXED-HEADER)
                          (TRANSACTION-ID)
                          (USER-ID)
                          (ERROR-CODE)
                          [NONCE]
                          [ERROR-INFO]
                         *[EXTENSION-ATTRIBUTE]

                          Figure 44: Error format

6.  Transport

   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.

   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.

   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 using a RESET call (send a TCP RST bit) 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.

   The way connection reestablishment is handled depends on how the
   client obtains information to contact the floor control server (e.g.,
   using an offer/answer exchange [13]).  Once the TCP connection is
   reestablished, the client MAY resend those message it did not get a
   response for from the floor control server.

   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 keeps the floor requests (i.e., does not cancel
   them) while the TCP connection is reestablished.

   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.

7.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms to provide replay and
   integrity protection, and confidentiality.  BFCP floor control
   servers MUST support TLS [4], and BFCP clients (which include both
   floor participants and floor chairs) SHOULD support TLS.  Any BFCP
   entity MAY support other security mechanisms.

   BFCP entities that implement TLS MUST support, at a minimum, the TLS
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].

8.  Protocol Transactions

   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 attribute which the
   floor control server copies into the response.  Clients use
   Transaction ID values to match responses with previously-issued
   requests.

   Server-initiated transactions consist of a single message from a
   floor control server to a client.  Since they do not trigger any
   response, server-initiated transactions do not have Transaction IDs
   associated with them.

8.1  Client Behavior

   A client starting a client-initiated transaction MUST set the
   Conference ID in the FIXED-HEADER of the message to the Conference ID
   for the conference that the client obtained previously.

   The client MUST set the Transaction ID value in the TRANSACTION-ID
   attribute to a number which 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 informs server.

8.2  Server Behavior

   A floor participants control server sending a response within a client-initiated
   transaction MUST copy the Conference ID, the TRANSACTION-ID
   attribute, and floor chairs
   about the status (e.g., USER-ID attribute from the current holder) of request received from
   the client into the response.  Server-initiated transactions MUST NOT
   contain a TRANSACTION-ID attribute.

9.  Authentication and Authorization

   BFCP clients SHOULD authenticate the floor by control server before
   sending
   them FloorInfo messages.  The following is the format of the
   FloorInfo message:

   FloorInfo        =       (FIXED-HEADER)
                            [TRANSACTION-ID]
                            (USER-ID)
                            [FLOOR-ID]
                         *( (FLOOR-REQUEST-ID)
                            [BENEFICIARY-ID]
                            [USER-DISPLAY-NAME]
                            [USER-URI]
                           *(FLOOR-ID)
                            [HUMAN-READABLE-INFO]
                            [PRIORITY]
                            (REQUEST-STATUS)      )
                            [NONCE]

                      Figure 25: FloorInfo format

5.3.7  ChairAction

   Floor chairs send instructions any BFCP message to it.  Similarly, floor control servers by sending
   ChairAction messages.  The following
   SHOULD authenticate a client before accepting any BFCP message from
   it.

   BFCP supports TLS-based mutual authentication between clients and
   floor control servers, as specified in Section 9.1.  This is the format of the ChairAction
   message:

   ChairAction  =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                  1*(FLOOR-ID)
                    (FLOOR-REQUEST-ID)
                    (REQUEST-STATUS)
                    [HUMAN-READABLE-INFO]
                    [NONCE]
                    [DIGEST]

                     Figure 26: ChairAction format

5.3.8  ChairActionAck

   Floor control servers confirm that they have accepted
   RECOMMENDED authentication mechanism in BFCP.

   Additionally, BFCP also provides a ChairAction
   message by sending digest mechanism based on a ChairActionAck message.  The following shared
   secret to provide client authentication in situations where TLS is the
   format of the ChairActionAck message:

   ChairActionAck  =   (FIXED-HEADER)
                       (TRANSACTION-ID)
                       (USER-ID)
                       [NONCE]

                    Figure 27: ChairActionAck format

5.3.9  Hello

   Floor participants
   not used for some reason.  This mechanism is described in
   Section 9.2.

9.1  TLS-based Mutual Authentication

   BFCP supports TLS-based mutual authentication between clients and
   floor chairs check the liveness of control servers.  Authentication based on both, certificates
   signed by a certificate authority and self-signed certificates is
   supported.

   If a client and a floor control servers server have certificates signed by sending a Hello message.  The following
   certificate authority known to both, they can use these certificates
   to authenticate each other at TLS establishment time.  Otherwise,
   BFCP assumes that there is an integrity-protected channel between the
   format of
   client and the Hello message:

   Hello         =  (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [NONCE]
                    [DIGEST]

                        Figure 28: Hello format

5.3.10  HelloAck

   Floor floor control servers confirm server that they can be used to exchange
   their self-signed certificates or, more commonly, the fingerprints of
   these certificates.  These certificates are alive on reception used at TLS establishment
   time.

      The implementation of such an integrity-protected channel using
      SIP and the offer/answer model is described in [13].

9.2  Digest-based Client Authentication

   BFCP supports digest-based client authentication based on a
   Hello message by sending shared
   secret between a HelloAck message.  The following is the
   format of client and the HelloAck message:

   HelloAck      =  (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    (SUPPORTED-TLVS)
                    [NONCE]

                       Figure 29: HelloAck format

5.3.11  Error

   Floor control servers inform floor participants control server.  It is assumed
   that an encrypted and integrity-protected channel exists between the
   client and the floor chairs
   about errors processing requests by sending them Error messages.  The
   following control server.  This channel is the format used to
   generate a shared secret between them.

      The implementation of such an encrypted and integrity-protected
      channel using SIP and the Error message:

   Error              =   (FIXED-HEADER)
                          (TRANSACTION-ID)
                          (USER-ID)
                          (ERROR-CODE)
                          [NONCE]
                          [HUMAN-READABLE-INFO]

                        Figure 30: Error format

6.  Transport

   BFCP entities exchange offer/answer model is described in [13].

   Digest-based client authentication in BFCP messages using TCP connections.  TCP
   provides is based on the DIGEST
   attribute.  This attribute contains an in-order reliable delivery of algorithm identifier and a stream
   keyed digest of bytes.
   Consequently, the of the BFCP message framing using that algorithm.  The
   text used as input to the digest algorithm is implemented in the application
   layer. BFCP implements application-layer framing using TLVs.

   A client MUST NOT use more than one TCP connection message,
   including the FIXED-HEADER, up to communicate and including the attribute
   preceding the DIGEST attribute.  Depending on the algorithm, this
   text may need to be padded with a given floor control server within a conference.  Nevertheless,
   if zeroes.  Section 5.2.9 lists the same physical box handles different clients (e.g., a floor
   chair
   algorithms specified in BFCP.

   The key used as input to the keyed digest is the secret shared
   between the server and a floor participant), which are the user identified by different
   User IDs, a separate connection per the USER-ID attribute
   in the message.

   Section 9.2.1 and Section 9.2.2 discuss how to achieve client is allowed.

   If a BFCP entity (a
   authentication using the DIGEST attribute.

9.2.1  Client Behavior

   To achieve client or authentication, a client needs to prove to the
   floor control server) receives data
   from TCP server that cannot be parsed the entity MUST close the TCP
   connection using client can produce a RESET call (send DIGEST attribute
   for a TCP RST bit) message using their shared secret and that the connection
   SHOULD be reestablished.  Similarly, if a TCP connection cannot
   deliver message is fresh
   (to avoid replay attacks).  Clients prove the freshness of a BFCP message and times out,
   by including a NONCE attribute in the TCP connection SHOULD be
   reestablished. message.  The way connection reestablishment NONCE attribute
   is handled depends on how the
   client obtains information to contact second to last attribute in the message (the last one is the
   DIGEST attribute).

   Clients can obtain the digest algorithms supported by the floor
   control server in an Error response from the floor control server
   with Error Code 3 (DIGEST Attribute Required).  A client SHOULD use
   the first digest algorithm in the list that it supports.

   Additionally, as an optimization, the floor control server and the
   client can agree on the algorithm to be used using an out-of-band
   mechanism (e.g., using an offer/answer exchange [14]).  Once the TCP connection is
   reestablished, as described in
   [13]).  This way, the client MAY resend those does not need to generate an initial
   BFCP message only to have it did not get a
   response for from rejected by the floor control server. server
   with an Error response containing a list with its supported
   algorithms.

   If after sending a floor control server detects that the TCP connection towards one message with a DIGEST attribute, a client receives
   an Error response with Error Code 3 (DIGEST Attribute Required) with
   a list of digest algorithms, the floor participants is lost, client SHOULD re-send the message
   using the first digest algorithm in the list that it is up supports.

   The nonce to be placed in the local policy of NONCE attribute by the client is
   typically provided by the floor control server what to do in an Error response
   -- typically with the pending floor requests
   of the floor participant.  In any case, it is RECOMMENDED that Error Code 3 (DIGEST Attribute Required) or 6
   (Invalid Nonce).  Additionally, as an optimization, the floor control
   server keeps can provide a client with a NONCE to be used in the floor requests (i.e., first
   message generated by the client using an out-of-band mechanism (e.g.,
   using an offer/answer exchange as described in [13]).  This way, the
   client does not cancel
   them) while need to generate an initial BFCP message only to have
   it rejected by the TCP connection is reestablished.

   If floor control server with an Error response
   containing a nonce.

   A client that obtains a nonce out-of-band SHOULD add a NONCE
   attribute and a client wishes DIGEST attribute to end its BFCP connection with a the first message it sends to the
   floor control
   server, server.  Furthermore, if any client generates a message
   without a DIGEST attribute and receives an Error response with Error
   Code 3 (DIGEST Attribute Required), the client closes (i.e., SHOULD re-send the
   message with a graceful close) DIGEST attribute and a NONCE attribute with the TCP connection
   towards nonce
   received in the floor control server. Error response.

   If after sending a floor control server wishes
   to end its BFCP connection message with a DIGEST attribute, a client (e.g., receives
   an Error response with Error Code 4 (Invalid Nonce), the focus of client
   SHOULD re-send the
   conference informs message using the floor control server that new nonce received in the client has been
   kicked out from Error
   response.  If the conference), Error Code is 5 (Authentication Failed) instead,
   the client MUST NOT send further messages to the floor control server closes
   (i.e.,
   until it has obtained a graceful close) different (hopefully valid) shared secret
   than the TCP connection towards one used in the original message.

   If a client receives a nonce in a message from the client.

7.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms to provide replay and
   integrity protection, and confidentiality.  BFCP floor control
   servers MUST support TLS [4], and BFCP clients (which include both
   floor participants and floor chairs) SHOULD support TLS.  Any BFCP
   entity MAY support other security mechanisms.

   BFCP entities that implement TLS MUST support, at a minimum,
   server, the TLS
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].

8.  Protocol Transactions

   In BFCP, there are two types of transactions: client-initiated
   transactions and server-initiated transactions (notifications).
   Client-initiated transactions consist of client SHOULD add a request from NONCE attribute with this nonce and a client
   DIGEST attribute to a its next message to the floor control server.

9.2.2  Floor Control Server Behavior

   If the floor control server and receives a response message without DIGEST
   attribute from an unauthenticated client, the floor control server to
   the client.
   responds with an Error message with Error Code 3 (DIGEST Attribute
   Required).  The request carries floor control message MUST include a TRANSACTION-ID TLV which list with the
   digest algorithms supported by the floor control server copies into in order of
   preference (i.e., the response.  Clients use Transaction ID
   values to match responses first algorithm is the most preferred) and a
   NONCE attribute with previously-issued requests.

   Server-initiated transactions consist of a single message from nonce value that is unguessable by attackers.

   When a floor control server to receives a client.  Since they do not trigger any
   response, server-initiated transactions do not have Transaction IDs
   associated BFCP message with them.

8.1  Client Behavior

   A client starting a client-initiated transaction MUST set DIGEST
   attribute, it checks whether the
   Conference ID Algorithm identifier in the FIXED-HEADER of the message DIGEST
   attribute corresponds to the Conference ID
   for the conference an algorithm that the client obtained previously.

   The client MUST set the Transaction ID value in the TRANSACTION-ID
   TLV to a number which 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 supported by the floor
   control server.

8.2  Server Behavior

   A  If it does not, the floor control server sending a response within SHOULD
   return an Error message with Error Code 3 (DIGEST Attribute Required)
   with a client-initiated
   transaction MUST copy the Conference ID, list with the TRANSACTION-ID TLV, and digest algorithms supported by the USER-ID TLV from floor control
   server.

   If the request received from algorithm identifier is valid, the client into floor control server checks
   whether the
   response.  Server-initiated transactions MUST NOT contain NONCE attribute carries a
   TRANSACTION-ID TLV.

9.  Authentication and Authorization

   BFCP uses nonce which was generated by
   the DIGEST TLV to provide floor control server for this client authentication.  The
   DIGEST TLV contains an HMAC-SHA1 [1] of the BFCP message.  The use of
   SHA1 implies that the length of and which still has not
   expired.  If the HMAC nonce is 20 bytes.  The text used
   as input to HMAC not valid, authentication is the BFCP message, including the FIXED-HEADER, up considered to and including the TLV preceding
   have failed, in which case the DIGEST TLV.  This text is then
   padded floor control server SHOULD return an
   Error message with Error Code 4 (Invalid Nonce) with zeroes so as to be a multiple of 64 bytes.  As new nonce in a result,
   NONCE attribute.

   If the DIGEST TLV MUST be nonce is valid, the last attribute in any BFCP message. floor control server calculates the keyed
   digest of the message using the algorithm identified by the DIGEST
   attribute.  The key used as input to HMAC the keyed digest is the secret
   shared between the server and the user identified by the USER-ID TLV
   attribute in the message.

9.1  Client Behavior

   Clients can authenticate floor  If the resulting value is the same as the
   one in the DIGEST attribute, authentication is considered successful.

   If the resulting value is different than the one in the DIGEST
   attribute, authentication is considered to have failed, in which case
   the server SHOULD return an Error message, as described in
   Section 13.8, with Error Code 5 (Authentication Failed).  Messages
   from a client that cannot be authenticated MUST NOT be processed
   further.

   Floor control servers MAY include a NONCE attribute in their
   responses to provide the nonce to be used in the next message by checking the
   client.  However, when TLS is used, floor control server's certificate when servers typically
   authenticate only the first message sent over the TLS connection is established
   between them.

   To achieve client authentication, connection.

   After authenticating a client needs to prove to BFCP message, the floor control server that checks
   whether or not the client can produce a DIGEST TLV for a
   message using their shared secret and that the message is fresh (to
   avoid replay attacks).  Clients prove the freshness of a message by
   including a NONCE TLV in the message.  The NONCE TLV is the second authorized to
   last TLV in perform the message (the last one operation it
   is the DIGEST TLV).

   The nonce to be places in the NONCE TLV by requesting.  If the client is typically
   provided by not authorized to perform the
   operation being requested, the floor control server in generates an
   Error response --
   typically with Error Code 7 (DIGEST TLV Required) or 6 (Invalid
   Nonce).  Additionally, message, as described in Section 13.8, with an optimization, the floor control server
   can provide a client Error code with
   a NONCE to be used in the first message
   generated by the value of 8 (Unauthorized Operation).  Messages from a client using an out-of-band mechanism (e.g., using
   an offer/answer exchange that
   cannot be authorized MUST NOT be processed further.

10.  Floor Participant Operations

   This section specifies how floor participants can perform different
   operations, such as requesting a floor, using the protocol elements
   described in [14]).  This way, the client
   does not need earlier sections.  Section 11 specifies operations that
   are specific to generate an initial BFCP message only floor chairs, such as instructing the floor control
   server to have it
   rejected grant or revoke a floor, and Section 12 specifies
   operations that can be performed by the any client (i.e., both floor control server with an Error response
   containing
   participants and floor chairs).

10.1  Requesting a nonce. Floor

   A client floor participant that obtains a nonce out-of-band SHOULD add a NONCE TLV and
   a DIGEST TLV wishes to the first request one or more floors does so
   by sending a FloorRequest message it sends to the floor control server.  Furthermore, if any client generates a message without

10.1.1  Sending a
   DIGEST TLV and receives an Error response with Error Code 7 (DIGEST
   TLV Required), the client SHOULD re-send FloorRequest Message

   The ABNF in Section 5.3.1 describes the message with attributes that a DIGEST
   TLV
   FloorRequest message can contain.  In addition, the ABNF specifies
   normatively which of these attributes are mandatory, and a NONCE TLV with which ones
   are optional.

   The floor participant sets the nonce received Conference ID in the Error response.

   If after sending a message with a DIGEST TLV, a client receives an
   Error response with Error Code 6 (Invalid Nonce), the client SHOULD
   re-send FIXED-HEADER and
   the message using TRANSACTION-ID attribute following the new nonce received rules given in
   Section 8.1.  Additionally, the Error
   response.  If the Error Code is 1 (Authentication Failed) instead, floor participant follows the client MUST NOT send further messages rules
   in Section 9 which relate to the authentication of the message.

   The floor participant must insert a USER-ID attribute, which will be
   used by the floor control server
   until it has obtained a different (hopefully valid) shared secret
   than to authenticate and authorize the one used in
   request.  If the sender of the FloorRequest message (identified by
   the USER-ID attribute) is not the participant that would eventually
   get the original message.

   If a client receives a nonce in floor (i.e., a message from the third party floor control
   server, request), the client sender SHOULD
   add a NONCE TLV with this nonce and a
   DIGEST TLV BENEFICIARY-ID attribute to its next the message to identifying the floor control server.

9.2  Floor Control Server Behavior

   Before accepting any BFCP message,
   beneficiary of the floor.

      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 several attributes:
      USER-ID, BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-
      BY-INFORMATION.

   The floor control server SHOULD
   authenticate participant must insert at least one FLOOR-ID attribute in
   the client. FloorRequest message.  If the client inserts more than one
   FLOOR-ID attributes, the floor control server receives a
   message without DIGEST TLV from will treat all the
   floor requests as an unauthenticated client, atomic package.  That is, the floor control
   server responds with an Error message with Error Code 7
   (DIGEST TLV Required). will either grant or deny all the floors in the FloorRequest
   message.

   The floor control message MUST include a
   NONCE TLV with participant may use a nonce value that 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 unguessable by attackers.

   When a intended for
   human consumption.

   The floor control participant may request the server receives a BFCP message to handle the floor
   request with a DIGEST
   TLV, it checks whether the NONCE TLV carries certain priority using a nonce which was
   generated by PRIORITY attribute.

10.1.2  Receiving a Response

   A message from the floor control server for this client and which still
   has not expired.  If the nonce is not valid, authentication is considered to have failed, in which case be a
   response to the FloorRequest message if the message from the floor
   control server
   SHOULD return an Error message with Error Code 6 (Invalid Nonce) with
   a new nonce has the same Conference ID, Transaction ID, and User
   ID as the FloorRequest message, as described in Section 8.1.

   The successful processing of a NONCE TLV.

   If the nonce is valid, FloorRequest message at the floor
   control server calculates involves generating one or several FloorRequestInfo
   messages.  The floor participant obtains a Floor Request ID in the
   HMAC-SHA1 [1]
   Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
   the first FloorRequestInfo message excluding the DIGEST TLV.  The key used
   as input to HMAC is from the secret shared between floor control server.
   Subsequent FloorRequestInfo messages from the floor control server and
   regarding the user
   identified by same floor request will carry the USER-ID TLV same Floor Request ID
   in a FLOOR-REQUEST-INFORMATION attribute as the initial
   FloorRequestInfo message.  If  This way, the resulting value
   is floor participant can
   associate subsequent incoming FloorRequestInfo messages with the same as
   ongoing floor request.

   The floor participant obtains information about the one in status of the DIGEST TLV, authentication is
   considered successful.

   If
   floor request in the resulting value is different than FLOOR-REQUEST-INFORMATION attribute of each of
   the one in FloorRequestInfo messages received from the DIGEST TLV,
   authentication floor control server.
   This attribute is considered to have failed, in which case the server
   SHOULD return an Error message, a grouped attribute and, as described in Section 13.7, with
   Error Code 1 (Authentication Failed).  Messages from such, it includes a client
   number of attributes that
   cannot be authenticated MUST NOT be processed further.

   Floor control servers may include a NONCE TLV in their responses to provide information about the floor
   request.

   The REQUEST-STATUS attribute.  If the nonce to be used Request Status value is
   Granted, all the floors that were requested in the next FloorRequest
   message by have been granted.  If the client.
   However, when TLS Request Status value is used, floor control servers typically
   authenticate only the first message sent over Denied,
   all the TLS connection.

   After authenticating a BCFP message, floors that were requested in the FloorRequest message have
   been denied.  A floor control server checks
   whether or not the client request is authorized considered to perform the operation be ongoing while it is requesting.  If
   in the client is not authorized Pending, Accepted, or Granted states.

   The STATUS-INFO attribute, if present, provides extra information
   which the floor participant MAY display to perform the
   operation being requested, user.

   The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
   the floor control server generates an
   Error message, as described request in Section 13.7, with an Error code with
   a value of 4 (Unauthorized Operation).  Messages from a client that
   cannot third-party floor requests.  The REQUESTED-BY-
   INFORMATION attribute may be authorized MUST NOT not be processed further.

10.  Floor Participant Operations

   This section specifies how floor participants can perform different
   operations, such as requesting a floor, using the protocol elements
   described present in earlier sections.  Section 11 specifies operations that
   are specific to FloorRequestInfo
   messages received by the floor chairs, such as instructing participant that requested the floor control
   server to grant or revoke a floor, and Section 12 specifies
   operations
   because this floor participant is already identified by the USER-ID
   attribute.

   The PRIORITY attribute, when present, contains the priority that can be performed was
   requested by any client (i.e., both the generator of the FloorRequest message.

   If the response is an Error message, the floor
   participants control server could
   not process the FloorRequest message for some reason, which is
   described in the Error message.

10.2  Cancelling a Floor Request and floor chairs).

10.1  Requesting Releasing a Floor

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

10.1.1  The FloorRelease message is also used by floor participants
   that hold a floor and would like to release it.

10.2.1  Sending a FloorRequest FloorRelease Message

   The ABNF in Section 5.3.1 5.3.2 describes the TLVs attributes that a FloorRequest
   FloorRelease message can contain.  In addition, the ABNF specifies
   normatively which of these TLVs attributes are mandatory, and which ones
   are optional.

   The floor participant sets the Conference ID in the FIXED-HEADER and
   the TRANSACTION-ID TLV attribute following the rules given in
   Section 8.1.  Additionally, the floor participant follows the rules
   in Section 9.1 9 which relate to the authentication of the message (i.e., to the
   DIGEST TLV). message.  The
   floor participant must insert a USER-ID TLV, attribute, which 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 TLV) is not the participant that would eventually get the
   floor (i.e., a third party floor request), the sender SHOULD add a
   BENEFICIARY-ID TLV to the message identifying the beneficiary of the
   floor.

      Note that the name space for both the User ID and the Beneficiary
      ID is the same.  That is, a given participant FloorRelease message is identified by used to release a
      single 16-bit value floor or
      floors that can be used in USER-ID were granted and in
      BENEFICIARY-ID TLVs.

   The floor participant must insert at least one FLOOR-ID TLV in the
   FloorRequest message.  If the client inserts more than one FLOOR-ID
   TLVs, the floor control server will treat all the to cancel ongoing floor requests as
   an atomic package.  That is,
      (from the protocol perspective both are ongoing floor control server will either
   grant or deny all requests).
      Using the floors same message in both situations helps resolve the FloorRequest message.

   The floor participant may use a HUMAN-READABLE-INFO TLV to state the
   reason why race
      condition that occurs when the floor or floors are being requested.  The Text field
   in FloorRelease message and the HUMAN-READABLE-INFO TLV is intended for human consumption.
      FloorGrant message cross each other on the wire.

   The floor participant may request uses the server FLOOR-REQUEST-ID that was received in
   the response to handle the FloorRequest message that the FloorRelease
   message is cancelling.

      Note that if the floor
   request with a certain priority using participant requested several floors as an
      atomic operation (i.e., in a PRIORITY TLV.

10.1.2 single FloorRequest message), all the
      floors are released as an atomic operation as well (i.e., all are
      released at the same time).

10.2.2  Receiving a Response

   A message from the floor control server is considered to be a
   response to the FloorRequest 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.

   The successful processing of a FloorRequest message at the floor
   control server involves generating one or several FloorRequestInfo
   messages.  The floor participant obtains a Floor Request ID in a
   FLOOR-REQUEST-ID TLV in the first FloorRequestInfo message from the
   floor control server.  Subsequent FloorRequestInfo messages from the
   floor control server regarding the same floor request will carry the
   same Floor Request ID as the initial FloorRequestInfo message.  This
   way, the floor participant can associate subsequent incoming
   FloorRequestInfo messages with the ongoing floor request.

   The floor participant obtains information about the status of the
   floor request in the REQUEST-STATUS TLV of each of the
   FloorRequestInfo messages received from the floor control server.

   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.  The HUMAN-READABLE-INFO
   TLV, if present, provides extra information which the floor
   participant MAY display to the user.

   A floor request is considered to be ongoing while it response is a FloorRequestInfo message, the Request Status
   value in the
   Pending, Accepted, REQUEST-STATUS attribute (within the FLOOR-REQUEST-
   INFORMATION grouped attribute) will be Cancelled or Granted states. Released.

   If the response is an Error message, the floor control server could
   not process the FloorRequest message for some reason, which is
   described in the Error message.

10.2  Cancelling

   It is possible that the FloorRelease message crosses on the wire with
   a Floor Request and Releasing FloorRequestInfo message from the server with a Floor

   A floor participant that wishes to cancel an ongoing floor request
   does so by sending Request Status
   different from Cancelled or Released.  In any case, such a FloorRelease
   FloorRequestInfo message will not be a response to the FloorRelease
   message, because its Transaction ID will not match that of the
   FloorRelease.

11.  Chair Operations

   This section specifies how floor chairs can instruct the floor
   control
   server.  The FloorRelease message is also used by server to grant or revoke a floor participants using the protocol elements
   described in earlier sections.

   Floor chairs that hold wish to send instructions to a floor and would like to release it.

10.2.1 control server
   do so by sending a ChairAction message.

11.1  Sending a FloorRelease ChairAction Message

   The ABNF in Section 5.3.2 5.3.9 describes the TLVs attributes that a FloorRelease ChairAction
   message can contain.  In addition, the ABNF specifies normatively
   which of these TLVs attributes are mandatory, and which ones are optional.

   The floor participant chair sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV attribute following the rules given in Section 8.1.
   Additionally, the floor participant chair follows the rules in Section 9.1 9 which
   relate to the authentication of the message (i.e., to the
   DIGEST TLV). message.  The floor participant chair must
   insert a USER-ID TLV, attribute, which will be used by the floor control
   server to authenticate and
   authorize the request.

      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.

   The floor participant uses the FLOOR-REQUEST-ID that was received in
   the response to the FloorRequest message that authenticate and authorize the FloorRelease request.

   The ChairAction message is cancelling.

      Note contains instructions that if the floor participant requested several apply to one or
   more floors as an
      atomic operation (i.e., in within a single FloorRequest message), all the particular floor request.  The floor or floors
   are released as an atomic operation as well (i.e., all identified by FLOOR-ID attributes and the floor request is
   identified by a FLOOR-REQUEST-ID attribute, which are
      released at carried in the same time).

10.2.2  Receiving
   ChairAction message.

      For example, if a Response

   A message from 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 is considered to be will grant the floor request as a
   response to
      whole.  On the FloorRelease message other hand, if one of the message from floor chairs denies its
      floor, the floor control server has the same Conference ID, Transaction ID, and User
   ID as will deny the FloorRequest message, floor request as described in Section 8.1.

   If the response is a FloorRequestInfo message,
      whole, regardless of the Request Status
   value in other floor chair's decision.

   The floor chair provides the REQUEST-STATUS-TLV will be Cancelled new status for one or Released.

   If the response is an Error message, more floors within
   the floor control server could
   not process request using a REQUEST-STATUS attribute.  If the FloorRequest message for some reason, which is
   described in new
   status of the Error message.

   It floor request is possible that the FloorRelease message crosses on the wire with
   a FloorRequestInfo message from Accepted, the server with a Request Status
   different from Cancelled or Released.  In any case, such floor chair MAY use the
   Queue Position field to provide a
   FloorRequestInfo message will queue position for the floor
   request.  If the floor chair does not be a response wish to provide a queue
   position, all the FloorRelease
   message, because its Transaction ID will not match that bits of the
   FloorRelease.

11.  Chair Operations

   This section specifies how Queue Position field SHOULD be set to
   zero.  The floor chairs can instruct chair SHOULD use the floor
   control server Status Revoked to grant or revoke a
   floor using that was granted (i.e., Granted status) and the protocol elements
   described Status Denied
   to reject floor requests in earlier sections.

   Floor chairs any other status (e.g., Pending and
   Accepted).

      Note that wish to send instructions to a floor control server
   do so by sending a ChairAction message.

11.1  Sending a ChairAction Message

   The ABNF in Section 5.3.7 describes the TLVs request may involve several floors and that a
      ChairAction message can contain.  In addition, the ABNF specifies normatively
   which may only deal with a subset of these TLVs are mandatory, and which ones are optional.

   The floors
      (e.g., if a single floor chair sets the Conference ID in the FIXED-HEADER and is not authorized to manage all the
   TRANSACTION-ID TLV following
      floors).  In this case, the rules given in Section 8.1.
   Additionally, REQUEST-STATUS that the floor chair follows the rules
      provides in Section 9.1 which
   relate to the authentication of the ChairAction message (i.e., to might not be the actual status
      that the DIGEST
   TLV).  The floor chair must insert a USER-ID TLV, which will be used
   by request gets at the server.  The floor control
      server to authenticate and authorize will combine the
   request.

   The ChairAction message contains instructions that apply to one or
   more floors within a particular received from the different
      floor chairs to come up with the actual status of the floor
      request.

   The floor chair may use a STATUS-INFO attribute to state the reason
   why the floor or floors are identified by FLOOR-ID TLVs and being accepted, granted, or revoked.  The
   Text in the STATUS-INFO attribute is intended for human consumption.

11.2  Receiving a Response

   A message from the floor request control server is identified
   by considered to be a FLOOR-REQUEST-ID TLV, which are carried in
   response to the ChairAction
   message.

      For example, message 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, message from the floor control server will grant
   has the floor request same Conference ID, Transaction ID, and User ID as a
      whole.  On the other hand, if one of
   ChairAction message, as described in Section 8.1.

   A ChairActionAck message from the floor chairs denies its
      floor, control server confirms that
   the floor control server will deny has accepted the ChairAction message.  An
   Error message indicates that the floor request as a
      whole, regardless of control server could not
   process the other ChairAction message for some reason, which is described
   in the Error message.

12.  General Client Operations

   This section specifies operations that can be performed by any
   client.  That is, they are not specific to floor chair's decision.

   The participants or
   floor chair provides chairs.  They can be performed by both.

12.1  Requesting Information about Floors

   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.

   Clients request information about the new status for of one or more several floors within
   by sending a FloorInfoWanted message to the floor request using control server.

12.1.1  Sending a REQUEST-STATUS TLV.  If FloorInfoWanted Message

   The ABNF in Section 5.3.7 describes the new status of attributes that a
   FloorInfoWanted message can contain.  In addition, the floor request is Accepted, ABNF specifies
   normatively which of these attributes are mandatory, and which ones
   are optional.

   The client sets the floor chair MAY use Conference ID in the Queue
   Position field to provide a queue position for FIXED-HEADER and the floor request.  If
   TRANSACTION-ID attribute following the floor chair does not wish to provide a queue position, all rules given in Section 8.1.
   Additionally, the
   bits of client follows the Queue Position field SHOULD be set rules in Section 9 which relate
   to zero.  The floor
   chair SHOULD use the Status Revoked to revoke a floor that was
   granted (i.e., Granted status) authentication and the Status Denied to reject floor
   requests in any other status (e.g., Pending and Accepted).

      Note that a floor request may involve several floors and that a
      ChairAction message may only deal with a subset protection of these floors
      (e.g., if a single floor chair is not authorized to manage all the
      floors).  In this case, integrity of the REQUEST-STATUS that
   message.  The client must insert a USER-ID attribute, which will be
   used by the floor chair
      provides control server to authenticate and authorize the
   request.

   The client inserts in the ChairAction message might not be the actual status
      that the floor request gets at all the server. Floor IDs it wants to
   receive information about.  The floor control server will combine the instructions received from send
   periodic information about all these floors.  If the different
      floor chairs client does not
   want to come up with the actual status of the floor
      request.

   The receive information about a particular floor chair may use any longer, it
   sends a HUMAN-READABLE-INFO TLV to state new FloorInfoWanted message removing the reason
   why FLOOR-ID of this
   floor.  If the client does not want to receive information about any
   floor or floors are being accepted, granted, or revoked.  The
   Text in the HUMAN-READABLE-INFO TLV is intended for human
   consumption.

11.2 any longer, it sends a FloorInfoWanted message with no FLOOR-ID
   attribute.

12.1.2  Receiving a Response

   A message from the floor control server is considered to be a
   response to the ChairAction FloorInfoWanted message if the message from the floor
   control server has the same Conference ID, Transaction ID, and User
   ID as the
   ChairAction FloorRequest message, as described in Section 8.1.

   A ChairActionAck

   On reception of the FloorInfoWanted message, the floor control server
   will respond with a FloorInfo message or with an Error message.  If
   the response is a FloorInfo 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
   FloorInfoWanted message (i.e., the client does not want to receive
   information about any floor any longer), the FloorInfo message from
   the floor control server confirms will not include any FLOOR-ID attribute
   either.

   FloorInfo messages which carry information about a floor contain a
   FLOOR-ID attribute that identifies the floor.  After this attribute,
   FloorInfo messages contain information about existing (one or more)
   floor control server has accepted request 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 ChairAction message.  An
   Error message indicates floor request followed by a set of attributes that
   provide information about the floor request.

   After the first FloorInfo, the floor control server could not
   process will continue
   sending FloorInfo messages periodically informing the ChairAction message for some reason, which is described
   in client about
   changes on the Error message.

12.  General Client Operations

   This section specifies operations that can be performed by any
   client.  That is, they are not specific to floor participants or
   floor chairs.  They can be performed by both.

12.1 floors the client requested information about.

12.2  Requesting Information about Floors Floor Requests

   A client can obtain information about the status of a floor one or floors 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.

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

12.1.1  Sending a FloorInfoWanted Message

   The ABNF in Section 5.3.5 describes the TLVs that a FloorInfoWanted
   message can contain.  In addition, the ABNF specifies normatively
   which of these TLVs are mandatory, and which ones are optional.

   The client sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV following the rules given in Section 8.1.
   Additionally, the client follows the rules in Section 9.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the DIGEST TLV).  The client must insert a
   USER-ID TLV, which will be used by the floor control server to
   authenticate and authorize the request.

   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 these floors.  If the client does not
   want to receive information about a particular floor any longer, it
   sends a new FloorInfoWanted message removing the FLOOR-ID of this
   floor.  If the client does not want current status of a floor
   requests by sending a FloorRequestInfoWanted message to receive the floor
   control server.

   Requesting information about any a particular floor any longer, it sends request is useful in
   a FloorInfoWanted message with no FLOOR-ID
   TLV.

12.1.2  Receiving number of situations.  For example, on reception of a FloorRequest
   message, a Response

   A message from the floor control server is considered may choose to be a
   response return FloorRequestInfo
   messages only when the floor request changes its state (e.g., from
   Accepted to Granted), but not when the FloorInfoWanted message floor request advances in its
   queue.  In this situation, if the user requests it, the floor
   participant can use a FloorRequestInfoWanted message from to poll the
   floor control server has for the same Conference ID, Transaction ID, and User
   ID as status of the FloorRequest message, as described floor request.

12.2.1  Sending a FloorRequestInfoWanted Message

   The ABNF in Section 8.1.

   On reception of the FloorInfoWanted message, 5.3.3 describes the floor control server
   will respond with attributes that a FloorInfo
   FloorRequestInfoWanted message or with an Error message.  If can contain.  In addition, the response is a FloorInfo message, it will contain information
   about one ABNF
   specifies normatively which of the floors the these attributes are mandatory, and
   which ones are optional.

   The client requested information about.  If sets the client did not include any FLOOR-ID TLV Conference ID in its FloorInfoWanted
   message, the FloorInfo message from FIXED-HEADER and the floor control server will not
   include any either.

   FloorInfo messages which carry information about a floor contain a
   FLOOR-ID TLV that identifies
   TRANSACTION-ID attribute following the floor.  After this TLV, FloorInfo
   messages contain information about existing (one or more) floor
   request that rules given in Section 8.1.
   Additionally, the client follows the rules in Section 9 which relate
   to that floor. the authentication of the message.  The information about each
   particular client must insert a
   USER-ID attribute, which will be used by the floor request consist of control server to
   authenticate and authorize the request.

   The client must insert a FLOOR-REQUEST-ID TLV attribute that identifies
   the floor request followed by a set of TLVs that provide
   information about at the floor request.

   After the first FloorInfo, control server.

12.2.2  Receiving a Response

   A message from the floor control server will continue
   sending FloorInfo messages periodically informing the client about
   changes on is considered to be a
   response to the floors FloorRequestInfoWanted message if the client requested information about.

12.2  Requesting Information about Floor Requests

   A client can obtain information about message from
   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 control server has the procedures same Conference ID, Transaction ID,a
   nd User ID as the FloorRequestInfoWanted message, as described in this section.

   Clients request
   Section 8.1.

   If the response is a FloorRequestInfo message, the client obtains
   information about the current status of one or
   several floor requests by sending a FloorRequestInfoWanted message to the floor control server.

      Requesting FloorRequest the client requested
   information about a particular floor request is useful in a number of situations.  For example, on reception of a
      FloorRequest FLOOR-REQUEST-INFORMATION attribute.

   If the response is an Error message, a the floor control server may choose to return
      FloorRequestInfo messages only when the floor request changes its
      state (e.g., from Accepted to Granted), but could
   not when process the FloorRequestInfoWanted message for some reason, which
   is described in the Error message.

12.3  Requesting Information about a User

   A client can obtain information about a participant and the floor
      request advances in its queue.  In
   requests related to this situation, if participant in different ways, which include
   using BFCP and using out-of-band mechanisms.  Clients using BFCP to
   obtain such information use the user
      requests it, procedures described in this section.

   Clients request information about a participant and the floor
   requests related to this participant can use by sending a
      FloorRequestInfoWanted UserInfoWanted
   message to poll the floor control server server.

   This functionality may be useful for floor chairs or floor
   participants interested in the status of display name and the URI of a
   particular floor request.
      FloorRequestInfoWanted messages can also be used participant.  In addition, a floor participant may
   find it useful to request information on all the floor requests associated with a floor
      participant. about itself.  For example, a
   floor participant, after experiencing connectivity problems (e.g.,
   its TCP connection with the floor control server was down for a while
   and eventually was re-established), may need to request information
   about all the still existing floor requests associated to the floor participant.

12.2.1 itself.

12.3.1  Sending a FloorRequestInfoWanted UserInfoWanted Message

   The ABNF in Section 5.3.3 5.3.5 describes the TLVs attributes that a
   FloorRequestInfoWanted
   UserInfoWanted message can contain.  In addition, the ABNF specifies
   normatively which of these TLVs attributes are mandatory, and which ones
   are optional.

   The client sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV attribute following the rules given in Section 8.1.
   Additionally, the client follows the rules in Section 9.1 9 which relate
   to the authentication of the message (i.e., to the DIGEST
   TLV). message.  The client must insert a
   USER-ID TLV, attribute, which will be used by the floor control server to
   authenticate and authorize the request.

   If the client wants to request the status of a single floor request,
   it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor
   request at the floor control server.

   The client can also request information about all the ongoing floor
   requests associated with a particular participant.  In this case, the
   client MUST NOT insert a FLOOR-REQUEST-ID TLV.  If the beneficiary of
   the floor requests participant the client is requesting information about
   is not the client issuing the FloorRequestInfoWanted UserInfoWanted message (which is
   identified by the USER-ID TLV attribute in the message) the client MUST
   insert a BENEFICIARY-ID TLV.

12.2.2 attribute.

12.3.2  Receiving a Response

   A message from the floor control server is considered to be a
   response to the FloorRequestInfoWanted UserInfoWanted message if the message from the floor
   control server has the same Conference ID, Transaction ID,a
   nd ID, and User
   ID as the FloorRequestInfoWanted UserInfoWanted message, as described in Section 8.1.

   If the response is a FloorRequestInfo UserInfo message, the client obtains information
   about the status of the FloorRequest the client requested
   information about floor participant in a REQUEST-STATUS TLVs.  If the client requested
   information BENEFICIARY-INFORMATION grouped
   attribute and about several floor requests, the FloorRequestInfo
   message will carry several FLOOR-REQUEST-ID TLVs.  Each
   FLOOR-REQUEST-ID TLV will be followed by TLVs (which will include a
   REQUEST-STATUS TLV) providing information about status of the floor request
   identified by requests associated with
   the FLOOR-REQUEST-ID TLV. floor participant in FLOOR-REQUEST-INFORMATION attributes.

   If the response is an Error message, the floor control server could
   not process the FloorRequestInfoWanted UserInfoWanted message for some reason, which is
   described in the Error message.

12.3

12.4  Obtaining the Capabilities of a Floor Control Server

   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.

12.3.1

12.4.1  Sending a Hello Message

   The ABNF in Section 5.3.9 5.3.11 describes the TLVs attributes that a Hello
   message can contain.  In addition, the ABNF specifies normatively
   which of these
   TLVs attributes are mandatory, and which ones are optional.

   The client sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV attribute following the rules given in Section 8.1.
   Additionally, the client follows the rules in Section 9.1 9 which relate
   to the authentication and the protection of the integrity of the message (i.e., to the DIGEST TLV).
   message.  The client must insert a USER-ID TLV, attribute, which will be
   used by the floor control server to authenticate and authorize the
   request.

12.3.2

12.4.2  Receiving Responses

   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.

   If the response is a HelloAck message, the floor control server could
   process successfully the Hello message.  The SUPPORTED-TLVS TLV SUPPORTED-ATTRIBUTES
   attribute indicates which TLVs attributes are supported by the server.

   If the response is an Error message, the floor control server could
   not process the Hello message for some reason, which is described in
   the Error message.

13.  Floor Control Server Operations

   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 or not 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.7, 13.8, with Error code
   0
   1 (Conference does not Exist).

   On reception of a message from a client, the floor control server
   follows the rules in Section 9.2, 9, which relate to the authentication of
   the message.

   On reception of a message from a client, the floor control server
   MUST check whether or not it understands all the mandatory ( 'M' bit
   set) TLVs 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.7, 13.8, with Error code 2
   (Authentication Failed).  The Error message SHOULD list the TLVs
   attributes that were not understood.

13.1  Reception of a FloorRequest Message

   On reception of a FloorRequest message, the floor control server
   follows the rules in Section 9.2 9 which 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.7 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 9 11 (You have Already Reached the Maximum Number of
      Ongoing Floor Requests for this Floor) to inform the floor
      participant.

13.1.1  Generating the First FloorRequestInfo Message

   The successful processing of a FloorRequest message by a floor
   control server involves generating one or several FloorRequestInfo
   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 REQUEST-STATUS
   TLV
   attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of
   the first FloorRequestInfo message it generates.

      The policy 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 everytime a decision needs to be
      made.

   The floor control server copies MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs attributes from the FloorRequest into
   the FloorRequestInfo, as described in Section 8.2.  Additionally, the
   floor control server copies (if present) the BENEFICIARY-ID TLV from
   the FloorRequest into MUST add a FLOOR-REQUEST-INFORMATION grouped
   attribute to the FloorRequestInfo.  The attributes contained in this
   grouped attribute carry information about the floor request.

   The floor control server MUST assign an identitifier that is unique
   within the conference to this floor request, and MUST insert it in a
   FLOOR-REQUEST-ID TLV into
   the FloorRequestInfo message. Floor Request ID field of the FLOOR-REQUEST-INFORMATION
   attribute.  This indentifier will be used by the floor participant
   (or by a chair or chairs) to refer to this specific floor request in
   the future.

   The future.

   The floor control server MUST copy the FLOOR-ID attributes from the
   FloorRequest into the FLOOR-REQUEST-INFORMATION attribute.  These
   FLOOR-ID attributes identify the floors being requested (i.e., the
   floors associated with this particular floor request).

   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.

   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 PRIORITY attribute
   from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped
   attribute.  Note that this attribute carries the priority requested
   by the participant.  The priority 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 copies the FLOOR-ID TLVs from the
   FloorRequest into the FloorRequestInfo.  These FLOOR-ID TLVs identify would ignore
   the floors being priority requested (i.e., by the floors associated with this
   particular floor request). participant.

   The floor control server also copies MAY copy (if present) the PRIORITY TLV PARTICIPANT-
   PROVIDED-INFO attribute from the FloorRequest into the FloorRequestInfo.  The Priority value
   requested by the floor participant is only a hint, and does not
   necessarily need to be taken into consideration to decide whether to
   grant or not the floor request. FLOOR-REQUEST-
   INFO grouped attribute.

13.1.2  Generation of Subsequent FloorRequestInfo Messages

   A floor request is considered to be ongoing as long as it is not in
   the Cancelled, Released, or Revoked states.  If the REQUEST-STATUS
   TLV
   attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of
   the first FloorRequestInfo message generated by the floor control
   server did not indicate any of these states, the floor control server
   will need to send subsequent FloorRequestInfo messages.

   When the status of the floor request changes, the floor control floor
   control
   server SHOULD send new FloorRequestInfo messages with the appropriate
   Request Status.  These FloorRequestInfo messages  The floor control server MUST
   contain add a FLOOR-REQUEST-ID TLV FLOOR-REQUEST-
   INFORMATION attribute with a Floor Request ID equal to the one sent
   in the first FloorRequestInfo message, but MUST NOT contain message to any TRANSACTION-ID
   TLV. new FloorRequestInfo
   related to the same floor request.  (The Floor Request ID identifies
   the floor request the
   FloorRequestInfo applies to.) FloorRequestInfo applies to.)

   The floor control server MUST NOT add any TRANSACTION-ID attribute to
   subsequent FloorRequestInfo messages.

      The rate at which the floor control server sends FloorRequestInfo
      messages is a matter of local policy.  A floor control server may
      choose to send a new FloorRequestInfo message every time the floor
      request moves in the floor request queue while another may choose
      to only send a new FloorRequestInfo message when the floor request
      is Granted or Denied.

   The floor control server may add a STATUS-INFO attribute to any of
   the FloorRequestInfo messages it generates to provide extra
   information about its decisions regarding the floor request (e.g.,
   why it was denied).

      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

   The FIXED-HEADER and the rest of the TLVs (except for the
   HUMAN-READABLE-INFO TLV) attributes are the same as in
   the first FloorRequestInfo message.

   The rate at which the floor control server sends FloorRequestInfo
      messages is can discard the state information about a matter
   particular floor request when this reaches a status of local policy.  A Cancelled,
   Released, or Revoked.

13.2  Reception of a FloorRequestInfoWanted Message

   On reception of a FloorRequestInfoWanted message, the floor control
   server may
      choose follows the rules in Section 9 which relate to send client
   authentication and authorization.  If while processing the
   FloorRequestInfoWanted message, the floor control server encounters
   an error, it SHOULD generate an Error response following the
   procedures described in Section 13.8

   The successful processing of a FloorRequestInfoWanted message by a
   floor control server involves generating a new FloorRequestInfo 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 attributes from the
   FloorRequestInfoWanted message every time into the floor
      request moves FloorRequestInfo message, as
   described in Section 8.2.  Additionally, the floor request queue while another may choose
      to only send control server
   MUST add a new FloorRequestInfo FLOOR-REQUEST-INFORMATION grouped attribute to the
   FloorRequestInfo.  The attributes contained in this grouped attribute
   carry information about the floor request.

   The floor control server MUST copy the contents of the
   FLOOR-REQUEST-ID attribute from the FloorRequestInfoWanted message when
   into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
   attribute.

   The floor control server MUST add FLOOR-ID attributes to the FLOOR-
   REQUEST-INFORMATION grouped attribute identifying the floors being
   requested (i.e., the floors associated with the floor request
      is Granted or Denied.
   identified by the FLOOR-REQUEST-ID attribute).

   The floor control server may SHOULD add a HUMAN-READABLE-INFO TLV BENEFICIARY-ID attribute to any the
   FLOOR-REQUEST-INFORMATION grouped attribute identifying the
   beneficiary of the FloorRequestInfo messages it generates to provide extra
   information about its decisions regarding floor request.  Additionally, the floor request (e.g.,
   why it was denied).

      Floor participants control
   server MAY provide the display name and floor chairs may request to be informed
      about the status URI of a floor following the procedures beneficiary in Section
      12.1.  If the processing of a
   this BENEFICIARY-INFORMATION attribute.

   The floor request changes control server MAY provide information about the status requester
   of the floor in a REQUESTED-BY-INFORMATION attribute inside the
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor (e.g., control server MAY provide the reason why the floor request is granted and consequently
   participant requested the floor has in a new holder), the PARTICIPANT-PROVIDED-INFO.

   The floor control server needs MAY also add to follow the procedures in Section 13.4 to inform FLOOR-REQUEST-
   INFORMATION grouped attribute a PRIORITY attribute with the clients that have Priority
   value requested that for the floor request and a STATUS-INFO attribute
   with extra information about the floor request.

   The floor control server can discard the state information about a
   particular floor request when this reaches adds a REQUEST-STATUS attribute to the
   FLOOR-REQUEST-INFORMATION grouped attribute with the current status
   of Cancelled,
   Released, or Revoked.

13.2 the floor request.

13.3  Reception of a FloorRequestInfoWanted UserInfoWanted Message

   On reception of a FloorRequestInfoWanted UserInfoWanted message, the floor control server
   follows the rules in Section 9.2 9 which relate to client authentication
   and authorization.  If while processing the
   FloorRequestInfoWanted UserInfoWanted message,
   the floor control server encounters an error, it SHOULD generate an
   Error response following the procedures described in Section 13.7 13.8

   The successful processing of a FloorRequestInfoWanted UserInfoWanted message by a floor
   control server involves generating a FloorRequestInfo UserInfo message, which SHOULD
   be generated as soon as possible.

   The floor control server copies the Conference ID, MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID attributes from the UserInfoWanted
   message into the USerInfo message, as described in Section 8.2.

   The sender of the UserInfoWanted message is requesting information
   about all the floor requests associated to 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
   USER-ID attribute in the UserInfoWanted message.

   The floor control server MUST copy, if present, the
   TRANSACTION-ID, and contents of the USER-ID TLVs
   BENEFICIARY-ID attribute from the FloorRequestInfoWanted UserInfoWanted message into the FloorRequestInfo message, as described a
   BENEFICIARY-INFORMATION attribute in Section
   8.2.

13.2.1  Information the UserInfo message.
   Additionally, the floor control server MAY provide the display name
   and the URI of the participant the UserInfo message provides
   information on a Single Floor Request

   If in this BENEFICIARY-INFORMATION attribute.

   The floor control server SHOULD add to the FloorRequestInfoWanted UserInfo message carries a FLOOR-REQUEST-ID, FLOOR-
   REQUEST-INFORMATION grouped attribute for each floor request related
   to the
   sender of participant the message is requesting provides information about on (i.e., the
   floor
   request identified by requests where the FLOOR-REQUEST-ID TLV. participant is either the beneficiary or the
   requester).  For each FLOOR-REQUEST-INFORMATION attribute, the floor
   control server follows the following steps.

   The floor control server copies MUST identity the FLOOR-REQUEST-ID TLV from floor request the
   FloorRequestInfoWanted message into FLOOR-
   REQUEST-INFORMATION attribute applies to by filling the FloorRequestInfo message. Floor Request
   ID field of the FLOOR-REQUEST-INFORMATION attribute.

   The floor control server adds MUST add FLOOR-ID TLVs attributes to the FloorRequestInfo
   message 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
   TLV). attribute).

   The floor control server may also SHOULD add a PRIORITY TLV with BENEFICIARY-ID attribute to the
   Priority value requested for
   FLOOR-REQUEST-INFORMATION grouped attribute identifying the floor request and a
   HUMAN-READABLE-INFO TLV with extra information about
   beneficiary of the floor request.

   The  Additionally, the floor control
   server adds a REQUEST-STATUS TLV with the current
   status of the floor request.

13.2.2  Information on the Floor Requests Associated to a Participant

   If MAY provide the FloorRequestInfoWanted message does not carry a
   FLOOR-REQUEST-ID TLV, display name and the sender URI of the message is requesting
   information about all the floor requests from a given participant.
   This participant is identified by a BENEFICIARY-ID TLV or, beneficiary in the
   absence of a BENEFICIARY-ID TLV, by a USER-ID TLV.
   this BENEFICIARY-INFORMATION attribute.

   The floor control server copies (if present) the BENEFICIARY-ID TLV
   from MAY provide information about the FloorRequestInfoWanted message into requester
   of the FloorRequestInfo
   message.  Additionally, floor in a REQUESTED-BY-INFORMATION attribute inside the
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor control server may MAY provide extra
   information about the reason why the floor
   participant by adding a USER-DISPLAY-NAME TLV,
   a USER-URI TLV, or both to requested the FloorRequestInfo message. floor in a PARTICIPANT-PROVIDED-INFO.

   The floor control server adds MAY also add to the FLOOR-REQUEST-
   INFORMATION grouped attribute a FLOOR-REQUEST-ID TLV PRIORITY attribute with the Priority
   value requested for each the floor request associated to the participant.  Each FLOOR-REQUEST-ID TLV is
   followed by and a number of TLVs which provide STATUS-INFO attribute
   with extra information about the floor request.

   The floor control server generates MUST add a REQUEST-STATUS attribute to the TLVs that
   follow each FLOOR-REQUEST-ID following
   FLOOR-REQUEST-INFORMATION grouped attribute with the rules in Section 13.2.1

13.3 current status
   of the floor request.

13.4  Reception of a FloorRelease Message

   On reception of a FloorRelease message, the floor control server
   follows the rules in Section 9.2 9 which 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.7 13.8
   The successful processing of a FloorRelease message by a floor
   control server involves generating a FloorRequestInfo message, which
   SHOULD be generated as soon as possible.

   The floor control server copies MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs attributes from the FloorRelease
   message into the FloorRequestInfo message, as described in
   Section 8.2.

   The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
   attribute to the FloorRequestInfo.  The attributes contained in this
   grouped attribute carry information about the floor request.

   The FloorRelease message identifies the floor request it applies to
   using a FLOOR-REQUEST-ID.  If  The floor control server MUST copy the beneficiary
   contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
   message into the Floor Request ID field of the FLOOR-REQUEST-
   INFORMATION attribute.

   The floor request is
   not control server MUST add FLOOR-ID attributes to the participant identified by FLOOR-
   REQUEST-INFORMATION grouped attribute identifying the USER-ID TLV in floors being
   requested (i.e., the FloorRelease
   message, floors associated with the floor request
   identified by the FLOOR-REQUEST-ID attribute).

   The floor control server adds SHOULD add a BENEFICIARY-ID TLV attribute to the
   FloorRequestInfo message
   FLOOR-REQUEST-INFORMATION grouped attribute identifying the
   beneficiary of the floor request.  Additionally, the floor control
   server may MAY provide extra
   information about the beneficiary of display name and the floor request by adding a
   USER-DISPLAY-NAME TLV, a USER-URI TLV, or both to URI of the
   FloorRequestInfo message. beneficiary in
   this BENEFICIARY-INFORMATION attribute.

   The floor control server copies MAY provide information about the FLOOR-REQUEST-ID TLV from requester
   of the
   FloorRelease message into floor in a REQUESTED-BY-INFORMATION attribute inside the FloorRequestInfo message.
   FLOOR-REQUEST-INFORMATION grouped attribute.

   The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo
   message identifying the floors being requested (i.e., MAY provide the floors
   associated with reason why the floor request identified by
   participant requested the FLOOR-REQUEST-ID
   TLV). floor in a PARTICIPANT-PROVIDED-INFO.

   The floor control server may MAY also add to the FLOOR-REQUEST-
   INFORMATION grouped attribute a PRIORITY TLV attribute with the Priority
   value requested for the floor request and a
   HUMAN-READABLE-INFO TLV STATUS-INFO attribute
   with extra information about the floor request.

   The floor control server adds MUST add a REQUEST-STATUS TLV attribute to the
   FloorRequestInfo message.
   FLOOR-REQUEST-INFORMATION grouped attribute.  The Request Status
   value SHOULD be Released, if the floor (or floors) had been
   previously granted, or of Cancelled, if the floor (or floors) had not
   been previously granted.

13.4

13.5  Reception of a FloorInfoWanted Message

   On reception of a FloorInfoWanted message, the floor control server
   follows the rules in Section 9.2 9 which 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.7 13.8

   A floor control server receiving a FloorInfoWanted message from a
   client SHOULD keep this client informed about the status of the
   floors identified by FLOOR-ID TLVs attributes in the FloorInfoWanted
   message.  Floor Control Servers keep clients informed by using
   FloorInfo messages.

   An individual FloorInfo message carries information about a single
   floor.  So, when a FloorInfoWanted message requests information about
   more than one floor, the floor control server needs to send separate
   FloorInfo messages for different floors.

   The information FloorInfoWanted 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.

13.4.1

13.5.1  Generation of the First FloorInfo Message

   The successful processing of a FloorInfoWanted message by a floor
   control server involves generating one or several FloorInfo messages,
   the first of which SHOULD be generated as soon as possible.

   The floor control server copies MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs attributes from the FloorInfoWanted
   message into the FloorInfo message, as described in Section 8.2.

   If the FloorInfoWanted message did not contain any FLOOR-ID TLV,
   attribute, the floor control server sends the FloorInfo message
   without adding any additional TLV attribute and does not send any
   subsequent FloorInfo message to the floor participant.

   If the FloorInfoWanted message contained one or more FLOOR-ID TLVs,
   attributes, the floor control server chooses one among them and adds
   this FLOOR-ID TLV attribute to the FloorInfo message.  The floor control
   server adds SHOULD add a FLOOR-REQUEST-ID TLV FLOOR-REQUEST-INFORMATION grouped attribute for
   each floor request associated to the floor.  Each FLOOR-REQUEST-ID TLV is followed by FLOOR-REQUEST-
   INFORMATION grouped attribute contains a number of TLVs attributes which
   provide information about the floor request.  For each FLOOR-REQUEST-ID TLV, FLOOR-REQUEST-
   INFORMATION attribute, the floor control server may add a
   BENEFICIARY-ID TLV identifying follows the requester of following
   steps.

   The floor control server MUST identity the floor and a
   USER-DISPLAY-NAME TLV, a USER-URI TLV, or both providing information
   about request the requester.  Additionally, FLOOR-
   REQUEST-INFORMATION attribute applies to by filling the Floor Request
   ID field of the FLOOR-REQUEST-INFORMATION attribute.

   The floor control server adds MUST add FLOOR-ID TLVs attributes to the FloorInfo message 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 TLV). attribute).

   The floor control server may 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.

   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 TLV attribute with the Priority
   value requested for the floor request and a
   HUMAN-READABLE-INFO TLV STATUS-INFO attribute
   with extra information about the floor request.

   The floor control server adds MUST add a REQUEST-STATUS TLV attribute to the
   FLOOR-REQUEST-INFORMATION grouped attribute with the current status
   of the floor request.

13.4.2

13.5.2  Generation of Subsequent  FloorInfo Messages

   If the FloorInfoWanted message carried more than one FLOOR-ID TLV,
   attribute, the floor control server SHOULD generate a FloorInfo
   message for each of them (except for the FLOOR-ID TLV attribute chosen
   for the first FloorInfo message) as soon as possible.  These
   FloorInfo messages are generated following the same rules as for the
   first FloorInfo message (see Section 13.4.1, 13.5.1, but without adding a
   TRANSACTION TLV. attribute.

   After generating these messages, the floor control server sends
   FloorInfo messages periodically keeping the client informed about all
   the floors the client requested information about.  These messages
   MUST NOT carry a TRANSACTION-ID TLV. attribute.

      The rate at which the floor control server sends FloorInfo
      messages is a matter of local policy.  A floor control server may
      choose to send a new FloorInfo message every time a new floor
      request arrives while another may choose to only send a new
      FloorInfo message when a new floor request is Granted.

13.5

13.6  Reception of a ChairAction Message

   On reception of a ChairAction message, the floor control server
   follows the rules in Section 9.2 9 which 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.7 13.8

   The successful processing of a ChairAction message by a floor control
   server involves generating a ChairActionAck message, which SHOULD be
   generated as soon as possible.

   The floor control server copies MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs attributes from the ChairAction
   message into the ChairActionAck message, as described in Section 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.

   For example, a floor chair may send a ChairAction message granting a
   floor which 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 to keep 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 the floor control server to 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
   in case the floor control server implements a queue.)

13.6

13.7  Reception of a Hello Message

   On reception of a Hello message, the floor control server follows the
   rules in Section 9.2 9 which 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.7 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 copies MUST copy
   the Conference ID, the TRANSACTION-ID, and the USER-ID TLVs attributes
   from the Hello into the HelloAck, as described in Section 8.2.

   The floor control server adds MUST add a SUPPORTED-TLVS TLV SUPPORTED-PRIMITIVES attribute to
   the HelloAck message listing all the TLVs primitives (i.e., BFCP messages)
   supported by the floor control server.

13.7

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

13.8  Error Message Generation

   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.11 5.3.13 describes the TLVs attributes that an Error message can
   contain.  In addition, the ABNF specifies normatively which of these TLVs
   attributes are mandatory, and which ones are optional.

   The floor control server copies MUST copy the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs attributes from the message from the
   client into the Error message, as described in Section 8.2.

   The floor control server adds MUST add an ERROR-CODE TLV attribute to the
   Error message.  The ERROR-CODE TLV attribute contains an Error Code from
   Table 4. 6.  Additionally, the floor control server may add a HUMAN-READABLE-INFO
   TLV ERROR-INFO
   attribute with extra information about the error.

14.  Security Considerations

   BFCP uses can use TLS or message signatures to provide client authentication and TLS
   to provide floor
   authentication.  Floor control server authentication, authentication is based on TLS,
   which also provides replay and integrity protection, and
   confidentiality.  It is RECOMMENDED that TLS with non-null encryption
   is always used and that the first message from a an unauthenticated
   client over a given TLS connection is signed using the DIGEST TLV.
   In any case, clients
   attribute.  Clients and floor control servers MAY use other security
   mechanisms as long as they provide similar security properties.

   The remainder of this Section analyzes some of the threats against
   BFCP and how they are addressed.

   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 clients sign their messages.  A nonce is included
   in the signature to ensure the freshness of the message.  If the
   client is using a TLS connection to communicate with the floor
   control server, it is enough that the client signs its first message
   over the TLS connection.  The floor control server assumes that
   attackers cannot hickjack the TLS connection and, therefore, that
   subsequent messages over the TLS connection come from the client that
   was initially authenticated.  If TLS-based client authentication is
   used, there is not need for the client to sign BFCP messages over the
   connection.

   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 floor control
   servers present their server certificates or prove that they have a
   shared secret with the client at TLS connection establishment time.

   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.

   An attacker may attempt to fetch a valid message sent by a client to
   a floor control server and replay it at a later point.  If the
   attacker attempts to replay it over the TLS connection between the
   client and the floor control server, TLS mechanisms discard it at the
   receiver side.  Still, if the
   message was signed, the attacker may attempt to establish a new TLS
   connection with the floor control server and replay the message over
   the new connection.  Using TLS confidentiality prevents this attack
   because the attacker cannot access the contents of the message in the
   first place.  Additionally,
   if the attacker attempts to replay the encrypted message over the new
   connection, TLS mechanisms would discard it at the receiver side. provides replay protection for a
   given connection.  Therefore, it is strongly RECOMMENDED that TLS is
   used with a non-null encryption algorithm.

   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.

15.  IANA Considerations

   This document instructs the IANA to create 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

15.1  Attribute Subregistry

   This Section establishes the Attribute subregistry under the BFCP
   Parameters registry.  As per the terminology in RFC 2434 [5], 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 RFC MUST specify the attribute's type,
   name, format, and semantics.

   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.

              +------+---------------------+------------+

           +------+---------------------------+------------+
           | Type | Attribute                 | Reference  |
              +------+---------------------+------------+
              |   0  | FLOOR-ID            | [RFC XXXX] |
           +------+---------------------------+------------+
           |   1  | USER-ID BENEFICIARY-ID            | [RFC XXXX] |
           |   2  | BENEFICIARY-ID FLOOR-ID                  | [RFC XXXX] |
           |   3  | TRANSACTION-ID FLOOR-REQUEST-ID          | [RFC XXXX] |
           |   4  | FLOOR-REQUEST-ID NONCE                     | [RFC XXXX] |
           |   5  | HUMAN-READABLE-INFO TRANSACTION-ID            | [RFC XXXX] |
           |   6  | DIGEST USER-ID                   | [RFC XXXX] |
           |   7  | REQUEST-STATUS PRIORITY                  | [RFC XXXX] |
           |   8  | ERROR-CODE REQUEST-STATUS            | [RFC XXXX] |
           |   9  | USER-DISPLAY-NAME DIGEST                    | [RFC XXXX] |
           |  10  | USER-URI ERROR-CODE                | [RFC XXXX] |
           |  11  | PRIORITY ERROR-INFO                | [RFC XXXX] |
           |  12  | NONCE PARTICIPANT-PROVIDED-INFO | [RFC XXXX] |
           |  13  | SUPPORTED-TLVS STATUS-INFO               | [RFC XXXX] |
           |  14  | SUPPORTED-ATTRIBUTES      | [RFC XXXX] |
           |  15  | SUPPORTED-PRIMITIVES      | [RFC XXXX] |
           |  16  | USER-DISPLAY-NAME         | [RFC XXXX] |
           |  17  | USER-URI                  | [RFC XXXX] |
           |  18  | BENEFICIARY-INFORMATION   | [RFC XXXX] |
           |  19  | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
           |  20  | REQUESTED-BY-INFORMATION  | [RFC XXXX] |
              +------+---------------------+------------+
           +------+---------------------------+------------+

         Table 5: 7: Initial values of the BFCP Attribute subregistry

15.2  Primitive Subregistry

   This Section establishes the Primitive subregistry under the BFCP
   Parameters registry.  As per the terminology in RFC 2434 [5], 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 RFC MUST specify the primitive's value,
   name, format, and semantics.

   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.

            +-------+------------------------+------------+
            | Value | Primitive              | Reference  |
            +-------+------------------------+------------+
            |   0   1   | FloorRequest           | [RFC XXXX] |
            |   1   2   | FloorRelease           | [RFC XXXX] |
            |   2   3   | FloorRequestInfoWanted | [RFC XXXX] |
            |   3   4   | FloorRequestInfo       | [RFC XXXX] |
            |   4   5   | UserInfoWanted         | [RFC XXXX] |
            |   6   | UserInfo               | [RFC XXXX] |
            |   7   | FloorInfoWanted        | [RFC XXXX] |
            |   5   8   | FloorInfo              | [RFC XXXX] |
            |   6   9   | ChairAction            | [RFC XXXX] |
            |   7   10  | ChairActionAck         | [RFC XXXX] |
            |   8   11  | Hello                  | [RFC XXXX] |
            |   9   12  | HelloAck               | [RFC XXXX] |
            |   10   13  | Error                  | [RFC XXXX] |
            +-------+------------------------+------------+

         Table 6: 8: Initial values of the BFCP primitive subregistry

15.3  Request Status Subregistry

   This Section establishes the Request Status subregistry under the
   BFCP Parameters registry.  As per the terminology in RFC 2434 [5],
   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 RFC MUST specify the value
   and the semantics of the request status.

   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.

                   +-------+-----------+------------+
                   | Value | Status    | Reference  |
                   +-------+-----------+------------+
                   |   0   1   | Pending   | [RFC XXXX] |
                   |   1   2   | Accepted  | [RFC XXXX] |
                   |   2   3   | Granted   | [RFC XXXX] |
                   |   3   4   | Denied    | [RFC XXXX] |
                   |   4   5   | Cancelled | [RFC XXXX] |
                   |   5   6   | Released  | [RFC XXXX] |
                   |   6   7   | Revoked   | [RFC XXXX] |
                   +-------+-----------+------------+

         Table 7: 9: Initial values of the Request Status subregistry

15.4  Error Code Subregistry

   This Section establishes the Error Code subregistry under the BFCP
   Parameters registry.  As per the terminology in RFC 2434 [5], 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 RFC MUST specify the value and the
   semantics of the error code, and any Error Specific Details that
   apply to it.

   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.

   +----------------------+----------------------+---------------------+
   |         Value        | Meaning              | Reference           |
   +----------------------+----------------------+---------------------+
   |           0           1          | Conference does not  | [RFC XXXX]          |
   |                      | Exist                |                     |
   |           1           2          | Authentication User does not Exist  | [RFC XXXX]          |
   |           3          | Failed DIGEST Attribute     | [RFC XXXX]          |
   |           2                      | Unknown Mandatory Required             | [RFC XXXX]                     |
   |           4          | TLV Invalid Nonce        | [RFC XXXX]          |
   |           3           5          | Floor Request ID Authentication       | [RFC XXXX]          |
   |                      | Does Not Exist Failed               |                     |
   |           4           6          | Unauthorized Unknown Primitive    | [RFC XXXX]          |
   |           7          | Operation Unknown Mandatory    | [RFC XXXX]          |
   |           5                      | User does not Exist Attribute            | [RFC XXXX]                     |
   |           6           8          | Invalid Nonce Unauthorized         | [RFC XXXX]          |
   |           7                      | DIGEST TLV Required Operation            |                     |
   |           9          | Invalid Floor ID     | [RFC XXXX]          |
   |           8          10          | Invalid Floor Request ID     | [RFC XXXX]          |
   |           9                      | Does Not Exist       |                     |
   |          11          | You have Already     | [RFC XXXX]          |
   |                      | Reached the Maximum  |                     |
   |                      | Number of Ongoing    |                     |
   |                      | Floor Requests for   |                     |
   |                      | this Floor           |                     |
   +----------------------+----------------------+---------------------+

          Table 8: 10: Initial Values of the Error Code subregistry

15.5  Digest Algorithm Subregistry

   This Section establishes the Digest Algorithm subregistry under the
   BFCP Parameters registry.  As per the terminology in RFC 2434 [5],
   the registration policy for BFCP digest algorithms 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 RFC MUST specify the value
   and the semantics of the error code, and any Error Specific Details
   that apply to it.

   For each BFCP digest algorithm, the IANA registers its numeric
   identifier, its name, and the reference to the RFC where the
   algorithm is defined.  The following table contains the initial
   values of this subregistry.

                 +------------+-----------+-----------+
                 | Identifier | Algorithm | Reference |
                 +------------+-----------+-----------+
                 |      0     | HMAC-SHA1 | RFC 2104  |
                 +------------+-----------+-----------+

       Table 11: Initial values of the Digest Algorithms subregistry

16.  Acknowledgments

   The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
   ideas for this document.  Additionally, Xiaotao Wu, Paul Kyzivat,
   Jonathan Rosenberg, and Miguel A.  Garcia-Martin Garcia-Martin, Mary Barnes, Ben
   Campbell, and Dave Morgan provided useful comments.

17.  References

17.1  Normative References

   [1]  Krawczyk, H., Bellare, M. M., and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

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

   [3]  Crocker, D. D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

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

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

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

17.2  Informational References

   [8]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [9]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [10]

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

   [11]

   [10]  Schulzrinne, H., "Requirements for Floor Control Protocol",
         draft-ietf-xcon-floor-control-req-02
         draft-ietf-xcon-floor-control-req-03 (work in progress),
         October 2004.

   [12]
         January 2005.

   [11]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-03
         draft-ietf-sipping-conferencing-framework-04 (work in
         progress), October 2004.

   [13] February 2005.

   [12]  Barnes, M. and C. Boulton, "A Framework and Data Model for
         Centralized Conferencing", draft-barnes-xcon-framework-00 draft-barnes-xcon-framework-02 (work
         in progress), October 2004.

   [14] February 2005.

   [13]  Camarillo, G., "Session Description Protocol (SDP) Format for
         Binary Floor Control Protocol  (BFCP) Streams",
         draft-camarillo-mmusic-sdp-bfcp-00
         draft-ietf-mmusic-sdp-bfcp-00 (work in progress), April January 2005.

Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail:

   Email: Gonzalo.Camarillo@ericsson.com

   Joerg Ott
   Universitaet Bremen
   MZH 5180
   Bibliothekstr. 1
   Bremen  D-28359
   Germany

   EMail: jo@tzi.org
   Helsinki University of Technology
   Department for Electrical and Communications Engineering
   Networking Laboratory
   Helsinki
   Finland

   Email: jo@netlab.hut.fi

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

   EMail:

   Email: drage@lucent.com

Intellectual Property Statement

   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.

   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.

   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.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.